Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
move_var should be configurable #69
Or really, the check should be that variables are declared with var before they're referenced, as violating that principle seems to be the only situation that has the potential to cause problems in this area (and only to programmers who just can't seem to wrap their head around the idea that if a var is declared in a function, it's a local var everywhere in that function... seems a sad set to cater to...).
Much code readability and maintainability research has shown that declaring variables as close as possible to where they are used, contrary to being lazy or stupid, makes code more maintainable by making it easeir for maintainers to find the declarations. Grouping variable definitions with their references essentially works on the same principle as grouping functions with data as methods in object-oriented programming, keeping related information together.
Given that the bulk of maintainability research favors declarations close to references, it would seem that JSLint is actually trying to ENFORCE a weakness in my code rather than INFORM me of one with this test...
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
Your comment makes sense if my argument was based on machine-memory optimization or some other machine-controlled factor, as scope (whether block or function) determines the locality and relationship of variables to machines.
But for humans who are reading and writing the listing (and who are the source of all of the confusion and errors to which you refer btw), maintainability is strongly correlated with optimization against human memory, which keys locality and relationships of variables based on position and proximity in the listing, with scope being a secondary key (e.g. it's generally easy for a machine to remember the latitude/longitude of Paris and referencing the city on a map would certainly make use of that latitude and longitude, but while a human CAN remember it, we're much more likely to be able to point to central-ish France on a map before providing the exact latitude and longitude).
And even apart from the human tendency to relate things by proximity, surely being able to actually read the variable declaration while referencing it would lead to less confusion about whether or not a variable is in local scope (a.k.a. function scope in js) and errors that result from that confusion than if the declaration occurs outside the viewport while the reference is within it, which is much more likely if the declaration must come at the beginning of the function.
And indeed, these same exact issues actually apply in block-scoped languages, but are at the block-level rather than the function-level (i.e. should all variables be declared at the beginning of the block, or as late as possible before their first reference). C-style purists maintain that variables should always be declared at the beginning of the scope to which they belong, but human-factors advocates often disagree, encouraging the declaration of variables as close as possible before their first reference.
Certainly you're free to continue to class out such users from your tool, maybe you're trying to reduce your server bandwidth, I don't know. But the status-quo will definitely result in users who actually research what they do moving on to other tools, even though they're usually your biggest advocates.