Pythoneer

Tomorrow there will be a django sprint, we are meeting at Tobi’s place in Augsburg (Germany). If you are interested in joining just drop him at tobias at klpstn punkt com or me wolfram at kriesing punkt de an email. It would be great to see some more django people.
Please bring coke and chips, we are providing wide-band-high-speed-fully-privileged access to the entire world wide web!

Happy sprinting …

There is not much to say, it is a saving! The screenshot below is a diff of a JavaScript file, that used to use dojo 0.4 and now uses the latest (0.9).

Just click it to see in full size.

The code on the left used dojo 0.4 on the right it’s dojo 0.9. You can see undoubtably that dojo 0.9 makes you write less code. Let’s pick out some things.

dojo.html.toCoordinateObject() has become dojo.coords() great, this always took a lot of time to write, but even better it needs to reference one object less and it has a much shorter name!
The scroll is included, if you set the second parameter (includeScroll) to true you get the scroll already included, you can see in the old code I still did it by hand (though I think it existed there too).
And the padding is included too, you can see that I don’t do any padding calculation anymore additionally.

Kepp going dojo …

JSLint throws some very interesting errors. If your code is working and a bit mature you might not find many things that look very wrong at first sight. But after working a bit with JSLint and questioning some of the results it throws I can understand it more and more. Here are some explanations for what JSLint says and why.
All possible JSLint message can be found here.

‘{a}’ is undefined.
One that everyone will agree needs to be taken care of are the use of undefined variables. Sometimes it’s just a matter of case, i.e. I found some variable mailPart and mailpart where the later was found undefined and this might really bite you in the butt. So imho those are the first errors one needs to look out for and fix, they are serious.

Use ‘{a}’ to compare with ‘{b}’.
Use ‘===’ to compare with ‘null’.
Use ‘===’ to compare with ‘0′.
Use ‘===’ to compare with ”.
Use ‘===’ to compare with ‘true’.
Use ‘===’ to compare with ‘false’.
At first sight you might say “Why?”. But after playing a bit with Firebug and trying some things I found out why this makes sense. The values that you get the warnings for are not save to compare with ==. Just take out Firebug and try out some stuff:

>>> "" == 0
true
>>> "" === 0
false
>>> null == undefined
true
>>> null === undefined
false
>>> true == 1
true
>>> true === 1
false

You can see that there are some values that equal though they are not the same.
There is too much room for errors! Just imagine expecting a parameter in a function and you want to check it for being null, but the input actually (caused by some previous error) is undefined, if you compared using == then you if-statement would evaluate to true, which is not what you wanted here. And this might start the chain of errors that cost time to debug.
So make sure you really get what you expect and use === for comparing the values: 0, null, undefined, "", true and false!

Missing radix parameter.
This message is given when you are using parseInt() without the second parameter radix. This might cause a problem when the variable passed to parseInt() starts with a 0, which makes JavaScript interpret the value as an octal number. Or if the string even starts with “0x” parseInt() might come up with the idea to see a hexadecimal number.

>>> parseInt("8")
8
>>> parseInt("08")
0
>>> parseInt("010") // A juicy mistake, octal numbers.
8
>>> parseInt("0x10") // Probably rare, but possible, hexadecimals.
16
>>> parseInt("08", 10) // Prevent problems, use the radix.
8
>>> parseInt("010", 10)
10

And if the paramter passed to parseInt() is a variable that comes from some other place you can not be sure that the string does not start with a “0″. So using the radix might save a lot of headache.

Expected { and instead saw ‘{b}’.
This is not really a big thing, but it helps keeping clean code and prevents from future errors. Mostly this warning just occurs when you are writing a one-line-if-statement without the curly braces, i.e.

if (i===true)
    callThis();

There is no potential error in running this code, but the optimizers, packers and the next developers touching the code will have a much easier time when you surround the function call with curly braces.

if (i===true) {
    callThis();
}

You just don’t want the next developer who is correcting the statement and adding something to the execution block to undeliberatly forget the curly braces and wonder why his code doesn’t work as expected.

if (i===true)
    callThis();
    andCallThis();

That piece of code looks good from far, but look close (not always you have the time to do so) and you see that the indentions makes you think there are two function calls inside the if-block, but in reality there aren’t since the curly braces had been forgotten. Avoid those problems by putting them, right from the start.
This seems like a no-brainer of for dummies, but I have seen error arising from that!

Actually I wanted to list a couple more warnings and explain them, but the time … you know. I hope to get around to do some more soon. Meanwhile have fun getting your source code cleaner …