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

Re: [jslint] Re: one line if statements

Expand Messages
  • Mark Volkmann
    If I understand correctly, in order to get your code to pass JSLint, you have to turn off strict whitespace checking. If you do that then the following will
    Message 1 of 9 , Aug 23, 2010
    • 0 Attachment
      If I understand correctly, in order to get your code to pass JSLint, you
      have to turn off strict whitespace checking.
      If you do that then the following will also be allowed (I hope the extra
      whitespace in my code sample gets retained in the email):

      if (a < 0)
      {
      return -1;
      }

      I don't want that to be allowed. I want a single-line if statement to be
      treated as an exception to the strict whitespace rule.

      What do you mean by "syntactically correct". My suggested code is
      syntactically correct, just not JSLint correct.

      On Mon, Aug 23, 2010 at 5:57 PM, Michael Mikowski <z_mikowski@...>wrote:

      > Hi Mark:
      >
      > And what is wrong with the following?
      >
      > ------------
      >
      > function foo(a, b) {
      > if (a < 0){ return -1;}
      > if (a*2 > b){ return 1;}
      >
      > // Now have several lines of code (say less than 10) that do something
      > // complicated with a and b and set the local variable "result".
      >
      > return result;
      > }
      > ---------------
      >
      > It provides all the benefits you mentioned, with the benefit of being
      > syntatically correct.
      >
      > Cheers, Mike
      >
      >
      > ----- Forwarded Message ----
      > From: Mark Volkmann <r.mark.volkmann@...<r.mark.volkmann%40gmail.com>
      > >
      > To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
      > Sent: Mon, August 23, 2010 1:10:57 PM
      > Subject: Re: [jslint] Re: one line if statements
      >
      > The benefit I see is conciseness of functions without loss of readability.
      > It is fairly common for me to write functions that test parameters and make
      > a determination about whether the rest of the code needs to be executed or
      > whether the result is already known. Here's a simple, contrived example:
      >
      > function foo(a, b) {
      > if (a < 0) return -1;
      > if (a*2 > b) return 1;
      >
      > // Now have several lines of code (say less than 10) that do something
      > // complicated with a and b and set the local variable "result".
      >
      > return result;
      > }
      >
      > This is visually appealing to me. It makes it easy to take in the entire
      > function at a glance and doesn't require scrolling in an editor to see all
      > the code.
      >
      > --
      > R. Mark Volkmann
      > Object Computing, Inc.
      >
      > [Non-text portions of this message have been removed]
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >



      --
      R. Mark Volkmann
      Object Computing, Inc.


      [Non-text portions of this message have been removed]
    • Cheney, Edward A SSG RES USAR
      Mark, My two cents is that considerations for presentation to humans are becoming more and more irrelevant in enterprise settings. A good example of why is
      Message 2 of 9 , Aug 25, 2010
      • 0 Attachment
        Mark,

        My two cents is that considerations for presentation to humans are becoming more and more irrelevant in enterprise settings. A good example of why is the YUI Compressor that is so popular and widely deployed. The big trend of the moment among enthusiasts and enterprise settings is performance, and a corner stone of performance is compression. Unfortunately, with compression, as with anything else, there is a trade off. When code is compressed it is unreadable and if it is not written to be as syntactically solid as possible then it may also be faulty.

        My organization, thank goodness, turns the obfuscation portion of the YUI Compressor off. It is great to reduce costs by increasing performance, but it is better to reduce costs by decreasing maintenance time. Humans time is significantly more valuable and incalculable than performance costs. We balance the trade of compression by being able to automatically inflate code back out at a manual request in order to perform diffs when necessary.

        This means code must be able to not only withstand compression, but also be able to withstand decompression without loss of fidelity. The current rules of JSLint enforce practices that raise the bar to such an extent that integrity of the logic is certainly preserved if the code passes the rules imposed by JSLint. If you are compressing your code then is issue is no brainer. Change how you write your code to prevent failure in production. If you don't compress your code, but work in an enterprise setting then presume somebody else is compressing your code or will do so in the near future. If such plans for syntactical rigidity not considered in advance then you will have to account for re-factoring time down the road, which can become extremely expensive given the complexity of pages that receive multiple script files that share variable and function names unintentionally.

        Austin
        http://prettydiff.com/
      • Michael S. Mikowski
        Hi Mark: ... I agree. That s a cure almost worse than the disease. So I do turn off strict white space, as implied in an unrelated jslint response I just
        Message 3 of 9 , Sep 14, 2010
        • 0 Attachment
          Hi Mark:

          On Monday, August 23, 2010 07:27:35 pm you wrote:
          > If I understand correctly, in order to get your code to pass JSLint, you
          > have to turn off strict whitespace checking.
          > If you do that then the following will also be allowed (I hope the extra
          > whitespace in my code sample gets retained in the email):
          > if (a < 0)
          > {
          > return -1;
          > }
          >
          > I don't want that to be allowed. I want a single-line if statement to be
          > treated as an exception to the strict whitespace rule.

          I agree. That's a cure almost worse than the disease. So I do turn off strict
          white space, as implied in an unrelated jslint response I just posted.

          > What do you mean by "syntactically correct". My suggested code is
          > syntactically correct, just not JSLint correct.

          I had assumed the single-line form is deprecated; one finds no mention of it
          in the w3schools guide: http://www.w3schools.com/js/js_if_else.asp. But I'm
          willing to admit that might not be the case.

          My solution is to turn off white space checking in jslint (which is highly
          subjective anyway), and use the single line form as presented below.

          As always, YMMV.

          Cheers, Mike


          > On Mon, Aug 23, 2010 at 5:57 PM, Michael Mikowski
          <z_mikowski@...>wrote:
          > > Hi Mark:
          > > And what is wrong with the following?
          > >
          > > ------------
          > >
          > > function foo(a, b) {
          > > if (a < 0){ return -1;}
          > > if (a*2 > b){ return 1;}
          > >
          > > // Now have several lines of code (say less than 10) that do something
          > > // complicated with a and b and set the local variable "result".
          > >
          > > return result;
          > > }
          > > ---------------
          > >
          > > It provides all the benefits you mentioned, with the benefit of being
          > > syntatically correct.
          > >
          > > Cheers, Mike
          > >
          > >
          > > ----- Forwarded Message ----
          > > From: Mark Volkmann
          > > <r.mark.volkmann@...<r.mark.volkmann%40gmail.com>
          > >
          > > To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
          > > Sent: Mon, August 23, 2010 1:10:57 PM
          > > Subject: Re: [jslint] Re: one line if statements
          > >
          > > The benefit I see is conciseness of functions without loss of
          > > readability. It is fairly common for me to write functions that test
          > > parameters and make a determination about whether the rest of the code
          > > needs to be executed or whether the result is already known. Here's a
          > > simple, contrived example:
          > >
          > > function foo(a, b) {
          > > if (a < 0) return -1;
          > > if (a*2 > b) return 1;
          > >
          > > // Now have several lines of code (say less than 10) that do something
          > > // complicated with a and b and set the local variable "result".
          > >
          > > return result;
          > > }
          > >
          > > This is visually appealing to me. It makes it easy to take in the entire
          > > function at a glance and doesn't require scrolling in an editor to see
          > > all the code.
          > >
          > > --
          > > R. Mark Volkmann
          > > Object Computing, Inc.
          > >
          > > [Non-text portions of this message have been removed]
          > >
          > > [Non-text portions of this message have been removed]


          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.