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

Re: one line if statements

Expand Messages
  • Marc Draco
    Although I can see the OP s sentiment, the code enforcement that JSLint employs tends to make us into better programmers. The idea of dropping superfluous
    Message 1 of 9 , Aug 22, 2010
    • 0 Attachment
      Although I can see the OP's sentiment, the code enforcement that
      JSLint employs tends to make us into better programmers. The idea of
      dropping "superfluous" braces seems obvious at first, but it frequently
      leads to tricky little errors. This shortcut is a legacy of C, IIRC, and
      really should be consigned to the past.

      Putting every block into braces (even if it's only 1 line) makes the
      meaning obvious - and avoids those confusing "did he mean?" bugs.

      Grab a copy of Code Complete by Steve McConnell
      (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670)
      and you'll see this howler explained along with many more.

      It's a great read.
    • Douglas Crockford
      ... Programming is all about making good trade offs. The better we are at making trade offs, the better our programs get. So let me suggest two rules from a
      Message 2 of 9 , Aug 23, 2010
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
        > I'm sure many people that use JSLint have some things they wish could
        > be changed about it. I understand that there is no way to make
        > everyone happen and opinions differ on what is good practice in
        > writing JavaScript code. I have been able to bend my preferences to
        > conform to what JSLint wants for everything but one. I asked for a
        > change to support this several months ago and it was rejected. I feel
        > compelled though to beg one last time. ;-)
        >
        > It seems very common to see one line if statements (in code that isn't
        > checked by JSLint) for simple things like:
        >
        > if (err) throw err;
        >
        > I see that in a lot of node.js code. People with a background in
        > languages like Perl, Python and Ruby are used to one-liners like that.
        > JSLint doesn't like that and wants this instead:
        >
        > if (err) {
        > throw err;
        > }
        >
        > I know the rationale is that omitting the braces can lead to confusion
        > when the statement after the if is placed on a separate line.
        > I also understand that I have at least two options for getting what I want now.


        Programming is all about making good trade offs. The better we are at making trade offs, the better our programs get.

        So let me suggest two rules from a much larger set of rules:

        1. Code consistently in order to avoid ambiguity and errors.

        2. Break a rule only when there is a significant benefit for doing so.

        JSLint helps you to benefit from Rule 1. You want to exercise Rule 2. So the question you have to answer is "What is the significant benefit?"

        When programs were prepared on punched cards, saving a line or two here or there had a real monetary benefit. You could save maybe a dollar in the development of a program by squeezing out vertical space. But that was a long time ago. It was a very bad trade off then. It is an even worse trade off now.
      • Mark Volkmann
        ... 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
        Message 3 of 9 , Aug 23, 2010
        • 0 Attachment
          On Mon, Aug 23, 2010 at 2:46 PM, Douglas Crockford <douglas@...>wrote:

          > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Mark
          > Volkmann <r.mark.volkmann@...> wrote:
          > > I'm sure many people that use JSLint have some things they wish could
          > > be changed about it. I understand that there is no way to make
          > > everyone happen and opinions differ on what is good practice in
          > > writing JavaScript code. I have been able to bend my preferences to
          > > conform to what JSLint wants for everything but one. I asked for a
          > > change to support this several months ago and it was rejected. I feel
          > > compelled though to beg one last time. ;-)
          > >
          > > It seems very common to see one line if statements (in code that isn't
          > > checked by JSLint) for simple things like:
          > >
          > > if (err) throw err;
          > >
          > > I see that in a lot of node.js code. People with a background in
          > > languages like Perl, Python and Ruby are used to one-liners like that.
          > > JSLint doesn't like that and wants this instead:
          > >
          > > if (err) {
          > > throw err;
          > > }
          > >
          > > I know the rationale is that omitting the braces can lead to confusion
          > > when the statement after the if is placed on a separate line.
          > > I also understand that I have at least two options for getting what I
          > want now.
          >
          > Programming is all about making good trade offs. The better we are at
          > making trade offs, the better our programs get.
          >
          > So let me suggest two rules from a much larger set of rules:
          >
          > 1. Code consistently in order to avoid ambiguity and errors.
          >
          > 2. Break a rule only when there is a significant benefit for doing so.
          >
          > JSLint helps you to benefit from Rule 1. You want to exercise Rule 2. So
          > the question you have to answer is "What is the significant benefit?"
          >
          > When programs were prepared on punched cards, saving a line or two here or
          > there had a real monetary benefit. You could save maybe a dollar in the
          > development of a program by squeezing out vertical space. But that was a
          > long time ago. It was a very bad trade off then. It is an even worse trade
          > off now.
          >

          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]
        • Michael Mikowski
          Hi Mark: And what is wrong with the following? ... function foo(a, b) { if (a b){ return 1;} // Now have several lines of code (say
          Message 4 of 9 , Aug 23, 2010
          • 0 Attachment
            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@...>
            To: jslint_com@yahoogroups.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]
          • 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 5 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 6 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 7 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.