Loading ...
Sorry, an error occurred while loading the content.

Re: /*global */

Expand Messages
  • Douglas Crockford
    My first concern with JSLint is correctness. Because I am a deeply flawed human being, and because JavaScript is a deeply flawed programming language, I depend
    Message 1 of 34 , Jun 1, 2009
    View Source
    • 0 Attachment
      My first concern with JSLint is correctness. Because I am a deeply flawed human being, and because JavaScript is a deeply flawed programming language, I depend on JSLint to provide the necessary discipline to program with confidence.

      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.

      I don't like global variables. Global variables contribute to unreliability and insecurity. JavaScript demands the use of global variables, which is sort of terrifying. I have spent a lot of time trying to figure out how to mitigate these globals. I came up with the /*global */ comment because I thought it was important to indicate when the use of globals was intentional.

      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*/

      with

      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.
    • Douglas Crockford
      ... 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
      Message 34 of 34 , Jun 12, 2009
      View Source
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
        > "name" needs to be writable. It has no value by default,
        > but you can assign a string to it, indicating the name of
        > the window/tab.

        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.
      Your message has been successfully submitted and would be delivered to recipients shortly.