Re: /*global */
So when I discover errors in my programs, I think about ways that I can improve JSLint to avoid similar errors in the future. This sometimes demands that I change my programming style because my previous style tended to hide defects or even encourage defects. Evolving my style is sometimes difficult and occasionally embarrassing, but it is a necessary part of the process of becoming a better programmer.
But working with ES5/strict, the JSLINT program itself passed JSLint but failed to run. The failure due to my using a /*global */ comment instead of a var statement. So now it turns out that /*global */ can mask errors from JSLint. That forces me to abandon /*global */ and look for a more reliable approach.
That approach is to use top level var statements to declare global variables. It is the most portable and most reliable approach. It required that I go through all of my programs and replace
/*global x, y, z*/
var x, y, z;
It was not a difficult change to make. I tend to use very few global variables, so there isn't much of an impact. When concatenating multiple script files, that may result in redundant var statements. That is annoying, but it is not a hazard, and it is not significant, particularly after gzip.
This language continues to surprise me. I thought I had figured out a good pattern for handling global variables. It turned out I was wrong. I think this new pattern is better.
- View Source--- In email@example.com, "pauanyu" <pcxunlimited@...> wrote:
> "name" needs to be writable. It has no value by default,Which do you think is more likely, that a program wants to change the global name, or that a var name declaration in a function was forgotten? We won't get an implied global warning, but at least we can get a read only warning. I think that is the more useful default.
> but you can assign a string to it, indicating the name of
> the window/tab.