There's a few features in the pipeline for JavaBat. Prompted by a suggestion from a loyal reader, I tried putting a copy of the GO button up at the top, so writing code is less constrained by the availability of vertical space, like on a netbook. I'm hoping we all get used to it, since it seems useful, but it does look a little funny after all this time with the button at the bottom.
Also, for people using the authoring feature, the tag parsing was so primitive, it could not tolerate any spaces like in "section : Logic-1" ... anyway I fixed that bit of lameness.
A teacher suggested that it would be nice if a teacher could see all the problems a student has attempted, rather than just the ones completed. That would be easy enough to do. One disadvantage would be that currently students can attempt but not solve a problem privately, and I like it that way. I don't want anyone to feel inhibited about thrashing around trying to solve things, since that practice will lead to excellence, but it won't look excellent at the start! Anyway, it's maybe worth trying as a feature.
Sunday, January 17, 2010
Wednesday, August 26, 2009
What's wrong with this code?
Here's some student code for JavaBat caughtSpeeding that shows a tricky coding bug, can you spot it? This student ran the code again and again, and I'm sure they were very frustrated that the code would not do what it should, but I'm hoping we can all learn a little from it.
The problem is the single "=" inside "if (isBirthday=false)" -- they meant to write a "==" to compare isBirthday to false. Instead the "=" assigns false to isBirthday and then uses false in the comparison. So that first if-statement is never true, regardless of what value was in isBirthday before. For many errors in Java code, you get a compiler error so you know right where you have something to fix. Compile errors are annoying at the time, but they are actually doing you a big favor, making it easy to find and fix simple problems. The tragic and very difficult to debug aspect of this bug is that it gets no compile error and it looks so similar to what the author intended ... it's hard for the eye to notice the little discrepancy. (Java, C, and C++ all treat = vs. == this way, so it's worth learning.)
How to fix 1: it's better to avoid the forms "if (isBirthday==true)" and "if (isBirthday==false)", instead writing them as "if (isBirthday)" or "if (!isBirthday)". This is shorter and more direct, and it happens to avoid this =/== trap which is so hard to debug.
How to fix 2: With the above fix, the code looks like...
That can work, but it could be improved a little. Notice that the 2 if-statements are exact opposites -- exactly one will run and the other will not. That's a common case, and for it you should just use a single if with a single else which looks like...
Incidentally, the technique here of having 2 big cases depending on isBirthday is a fine approach. Another approach which is shorter but trickier is to modify the "speed" variable if isBirthday is true, and then have a series of if/else to figure out the answer -- avoiding having one copy of the code for isBirthday and a second copy for !isBirthday.
public int caughtSpeeding(int speed, boolean isBirthday) {
if (isBirthday=false) {
...snip...
}
else if (isBirthday=true) {
...snip...
}
else return 0;
}
The problem is the single "=" inside "if (isBirthday=false)" -- they meant to write a "==" to compare isBirthday to false. Instead the "=" assigns false to isBirthday and then uses false in the comparison. So that first if-statement is never true, regardless of what value was in isBirthday before. For many errors in Java code, you get a compiler error so you know right where you have something to fix. Compile errors are annoying at the time, but they are actually doing you a big favor, making it easy to find and fix simple problems. The tragic and very difficult to debug aspect of this bug is that it gets no compile error and it looks so similar to what the author intended ... it's hard for the eye to notice the little discrepancy. (Java, C, and C++ all treat = vs. == this way, so it's worth learning.)
How to fix 1: it's better to avoid the forms "if (isBirthday==true)" and "if (isBirthday==false)", instead writing them as "if (isBirthday)" or "if (!isBirthday)". This is shorter and more direct, and it happens to avoid this =/== trap which is so hard to debug.
How to fix 2: With the above fix, the code looks like...
public int caughtSpeeding(int speed, boolean isBirthday) {
if (!isBirthday) {
...snip...
}
else if (isBirthday) {
...snip...
}
else return 0;
}
That can work, but it could be improved a little. Notice that the 2 if-statements are exact opposites -- exactly one will run and the other will not. That's a common case, and for it you should just use a single if with a single else which looks like...
public int caughtSpeeding(int speed, boolean isBirthday) {
if (!isBirthday) {
...snip...
}
else {
...snip...
}
}
Incidentally, the technique here of having 2 big cases depending on isBirthday is a fine approach. Another approach which is shorter but trickier is to modify the "speed" variable if isBirthday is true, and then have a series of if/else to figure out the answer -- avoiding having one copy of the code for isBirthday and a second copy for !isBirthday.
Friday, August 14, 2009
JavaBat authoring feature go!
This is something I wanted to try to enable announcements and discussion for things going on at javabat.com.
So after just tons of coding, the often requested feature of editing your own problems now works, see the authoring docs and the javabat authoring page (you need to be logged in to do anything).
You can create little pages of favorite problems, and with more effort you can create your own custom problems. I'm still working out how to integrate the custom problems with the main site content. Anyway, I'm quite curious to see how it works and what direction to take it.
So after just tons of coding, the often requested feature of editing your own problems now works, see the authoring docs and the javabat authoring page (you need to be logged in to do anything).
You can create little pages of favorite problems, and with more effort you can create your own custom problems. I'm still working out how to integrate the custom problems with the main site content. Anyway, I'm quite curious to see how it works and what direction to take it.
Subscribe to:
Posts (Atom)