Out of Hanwell

August 30, 2005

JavaScript Lint Beta 2

Filed under: Uncategorized — Matthias Miller @ 6:28 am

This last two weeks have been quite busy. I thank everybody who took time to send me their bug reports and feature requests. JavaScript Lint Beta 2 is finally available. Here is a summary of the changes:

  • Feature – JavaScript Lint is now available as a Linux binary.

  • Feature – The format of the lint errors can now be customized for better integration with different IDEs.

  • Feature – Portions of a script can notated to be ignored by JavaScript Lint.

  • Bug – Resolved an incorrect warning against missing curly braces for an "else if".

  • Bug – Resolved an incorrect warning regarding ambiguous line breaks.

  • Bug – Resolved a circumstance in which JavaScript Lint treated a JavaScript file as an HTML file.

The most significant feature, however, is JavaScript Lint’s ability to check for undeclared identifiers. Failing to use the var keyword before assigning a value to a variable causes it to have global scope. An undefined variable will evaluate to false in an if statement. This makes it difficult to catch mistyped variable names, which is a common source of bugs.

JavaScript Lint has relocated to JavaScriptLint.com. The new betas, as well as documentation on these features, are available on that site. In addition, JavaScript Lint is now available as an online service.

Feedback relating to JavaScript Lint can be sent to Info<at>JavaScriptLint.com.


August 24, 2005

Through the Looking Glass

Filed under: Uncategorized — Matthias Miller @ 5:16 pm

Eric Lippert has an interesting explanation of mirrors and symmetry for people who enjoy messing with their minds:

Through the Looking Glass

August 16, 2005

JavaScript Lint Beta Released

Filed under: Uncategorized — Matthias Miller @ 2:58 pm

OutOfHanwell.com has released a beta JavaScript Lint based on SpiderMonkey, the JavaScript engine in Firefox.

Update: Some of you have reported that jsl.zip does not contain the default configuration file. This problem has been corrected.

August 10, 2005

Drip 0.2 Back Online

Filed under: Uncategorized — Matthias Miller @ 1:22 am

For those web developers who have been wanting to find memory leaks in Internet Explorer, Drip 0.2 is back online.

August 9, 2005


Filed under: Uncategorized — Matthias Miller @ 1:30 pm

There are many sophisticated Lints available for C/C++ (CodeWizard, PC-lint/FlexeLint, Splint), but the only such tool available for JavaScipt is JSLint.

JSLint is written entirely in JavaScript, using an algorithm based on Vaughan Pratt’s “Top Down Operator Precedence”. JSLint’s parser is quite comparable to the jsparse module in Mozilla’s SpiderMonkey, except it does not store the tokens in data structures because it never executes the script. This makes the parsing much simpler, but less powerful.

JSLint does an excellent job of catching some common mistakes:

  • Missing semicolons. Although the use of semicolons is optional in JavaScript, they help to resolve ambiguity with the use of parentheses and of the ++ and — operators. JSLint warns if semicolons are missing.

  • Missing curly braces. Nested block statements can be quite confusing even to the experienced developer. JSLint requires that all if, for, and while statements use curly braces.

  • Extraneous curly braces. Unlike C and C++, JavaScript curly braces do not introduce a new scope. JSLint recognizes these curly braces and warns against them.

  • Useless code. JSLint warns against expressions that do nothing or are unreachable.

  • Minimal flow control. JSLint makes sure that each case statement ends with a break, return, or throw.

  • Typed comparisons. JSLint ensures that comparisons against 0, a blank string, undefined, null, false, or true use the "===" or "!==" operators, which disallow implicit type conversions.

There are several weaknesses in JSLint, however:

  1. Errors are fatal. The purpose of a lint is not to find errors but to warn against questionable practices. If JSLint encounters a lint warning, it does not continue parsing the script. If there are multiple mistakes in your code, you have to run JSLint multiple times.

  2. Errors cannot be suppressed. The proficiency of JavaScript programmers varies greatly among web developers. Some developers learn JavaScript only after having mastered C/C++. Others begin programming with the copy-and-paste method (having no prior experience in programming), and slowly start tweaking the scripts until they accomplish their goals. Advanced coders will find certain errors to be annoying; novice coders will find them to be priceless. Such errors should be optional.

  3. Parsing information is not retained. JSLint stores limited information; particularly, it does not save a stack of switch, if, for, and while statements. If the script would maintain a stack of block statements. it could determine the block at the top stack when parsing a statement. It would be quite simple to give the Required Blocks warning if the first token of the statement is not a left-curly but there is an if, for, or while statement at the top of the stack. The Forbidden Blocks warning could be given when the first token is a left-curly even though there is no block on the top of the stack. This would be much more robust solution and would even allow these errors (especially the former) to be disabled cleanly.

Although JSLint provides a good starting point in JavaScript linting, you may end up hacking the script to work around these limitations if you lint more than just a couple of lines.

Are you a web developer? Send your thoughts to Blog<at>OutOfHanwell.com.

August 3, 2005

The Browser War

Filed under: Uncategorized — Matthias Miller @ 3:44 am

As last week’s release of the Internet Explorer 7 beta 1 has shown, the browser war is more complicated than it may seem. Each browser has its own share of bugs and unimplemented features that inhibit web development.

According the IE Blog, Microsoft has been focusing on fixing security problems and major CSS bugs in the new version of Internet Explorer. (As an example limitation in Internet Explorer’s CSS implementation, the size of absolutely-positioned elements must be specified as height and width. The element cannot be positioned by setting both the left and right positions.) By addressing these problems, Microsoft is making it easier for web developers to create cross-browser websites that don’t depend on difficult-to-maintain hacks.

Other bugs and limitations may not be immediately evident. Internet Explorer’s comboboxes and listboxes have a propensity toward popping up above other page elements (documented in Q177378), and Firefox sometimes fails to display the text cursor in its edit boxes (documented in bug 167801). Problems like these may only be encountered by advanced web developers.

This battle will not be won by emotional journalists calling Firefox their "beloved" or their "lover". It will only be won by the group who manages to develop an Internet platform on which developers can easily build. It may be that Microsoft will win, or it may be that the Mozilla Foundation will take over. But it could also be that this browser war will be won by creative web developers such as Dean Edwards who decide to take the matter into their own hands.

If that’s what it takes, let the war rage on:

Get Firefox!

What do you think? Send your thoughts about the browser war to Blog<at>OutOfHanwell.com.

Blog at WordPress.com.