New (secret) Warnings in svn trunk

inghamc
2009-10-02
2013-05-28
  • inghamc
    inghamc
    2009-10-02

    Again, I was excited to see new development in the svn repo, especially from the original artist, but why the secrecy?  Things look pretty quiet from  (last News entry is dated Sep 2007).  **Shouldn't everyone know JavaScript Lint development is active and ongoing, and how to take advantage of it?**

    Anyway, the built-from-svn jsl.py gave me warnings that the 0.3.0 Windows jsl.exe didn't.  To figure out what flags were associated with these warnings, I parsed the output of "jsl.py -test" for strings that weren't present in the 0.3.0 jsl.default.conf:

        $ for test in $(jsl.py -test); do warning=$(basename $test .js); grep -q $warning jsl.conf || echo $warning; done

    , and then finally discarded the ones that made jsl.py barf.

    **Could the -verbose or some other flag print the warning flag associated with each output warning so we could know where to toggle the +/- in the config file?**

    Also, Matthias, you recently posted that jsl **-help:conf** generates a default config file, but this **doesn't work on jsl.py:**

        $ jsl -help:conf
        Usage: jsl.py 
       
        jsl.py: error: no such option: -help:conf

    So here's what I determined to be new config warning flags since the 0.3.0 release:

        +invalid_fallthru             # ? we already have missing_break
        +invalid_pass                 # ?
        +missing_semicolon_for_lambda # how's this different from +lambda_assign_requires_semicolon?
        -unreferenced_identifier      # would like to just catch unused vars
        +useless_quotes               # examples?
        -want_assign_or_call          # complains about: possiblyNull && possiblyNull.memberAccess, but caught a function call missing ()!

    Two of these new flags were generating the new warnings in my code:

    **+unreferenced_identifier**

    Unfortunately, this one flag catches both unused function parameters and unused var declarations.  I'm trying to write JavaScript in an object-oriented style where I declare "abstract" methods in a "base class" that throw an exception if not overridden in "subclasses" (sorry for all the air quotes), so I get some unwanted warnings here.  But I still want to catch unused vars; so **could this warning be split into +unreferenced_function_param (with the ability to prepend /*jsl:ignore*/ to individual formal arguments that terminates at the next ',' or ')' rather than requiring a /*jsl:end*/) and +unreferenced_var?**

    **-want_assign_or_call**

    This caught a real problem: a statement

        object.functionName;

    that was missing the parentheses to invoke the function!  In this case the function was "refresh()", which wasn't always necessary, so this might never have been found - yay JavaScript Lint!

    However, it also flags another usage I thought was really cool, but don't remember where I first encountered it, and had in fact forgotten it entirely until jsl.py warned me about it:

        possiblyNull && possiblyNull.memberAccess
       
    as a shell/perl-like, more compact replacement for
       
        if (possiblyNull) { possiblyNull.memberAccess }

    Matthias, have you or any other JS experts out there seen this usage and condone it?  It's one of those things that might be a little off-putting the first time you encounter it but grows on you and avoids the whole "curly braces around a single statement and how to format them" issue.  **If this is a non-dangerous and useful idiom, could the presence of '&&' or '||' avoid the warning in order to catch more serious problems?**

    Anyway, I hope the above ramblings are taken for the constructive criticism intended, and I'd be happy to log defect / enhancement requests for the above - just let me know.

    Chris

      : http://www.javascriptlint.com

     
  • The reason this has been so quiet is simply because it's a one-man show that happens on random weekends. I knew the danger of a full rewrite (which is essentially what happened), so I wasn't anxious to attract a whole lot of attention until I was done. You're probably right, however, that I've waited too long.

    I've implemented -help:conf, which you can pipe to a text file to get started. This solves a number of problems:

    1. You can see a full list of warnings.
    2. You can see the warning text beside the warning. (I think this is sufficient for most people to find the proper warning.)
    3. It shows how to change the output message to include the warning name. (I think display it adds a bit of clutter, so if #2 does the trick, I'm inclined not to show warning names by default.)

    Also, I've broken up the unreferenced_identifier warning for you.

    I'll respond separately to your last question.

     
  • First of all, there's a *lot* of controversy surrounding  this, so please understand that this is my opinion, I think I'm right, but others disagree. Lints are extremely subjective, which is why jsl is built completely around customizability. Everything's an option.

    First of all, I wouldn't allow anyone to use this coding style on my code base. However, that's not because I think it's inherently evil. It's just that it's not a familiar metaphor, and as such, I'd think it better not to use it. I think the argument for not using it is that it reduces your "horizontal complexity". Each line is a simple, discrete piece. (Admittedly, that argument breaks down if you're just doing a null check, because you're adding very little complexity.)

    I propose that we add an option to allow this syntax as long as we recursively check that an ||'s left, an ||'s right, and an &&'s right side all lead to a function call. The way that jsl is implemented, it would be nice to have separate warnings.

    Also, I suspect people will also want to be able to do this:

    `new function() {

    }`

    So you have:

    `expected_statement_not_new …`
    `expected_statement_not_boolean_logic …`
    `expected_statement_not_expression …`

    Suggestions for warning names (clearer and more precise) are welcome! I tried using a common prefix to group them together.

     
  • Bob Denny
    Bob Denny
    2009-10-03

    Matthias - Let me add my voice to those who thank you for your work on this, and welcome the new activity. I have been using JSL for 3 years, and I can't live without it (or at least my development times would triple!). I'll start monitoring things here and if there's anything I can do I'll jump in.

    Thanks again!!!!

     
  • petergrabs
    petergrabs
    2010-06-13

    i was just asking for that unreferences variable thing in an email before i  found this forum. it would be nice to create a windows version that includes it (or point me to it if i just didnt see it).

    thanks.

    ps: i really enjoy this tool, i juse it with notepad++, saves a lot of debugging.

     
  • petergrabs
    petergrabs
    2010-06-21

    is anyone working on this anymore? just to not lose my idea: make a control comment /*jsl:define …*/ to make defines per file and not in the global config. for me this is THE essential control comment, all the other stuff i have no problem to configure globally.