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

one line if statements

Expand Messages
  • Mark Volkmann
    I ve been using JSLint for quite a while now. I think it is an invaluable tool! I m sure many people that use JSLint have some things they wish could be
    Message 1 of 9 , Aug 21 1:52 PM
    • 0 Attachment
      I've been using JSLint for quite a while now. I think it is an invaluable tool!

      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.

      1) I can set an option (don't remember which one) that will tell
      JSLint not to complain about brace placement.
      I don't want to do this because I still want it to check for
      proper brace usage for multi-line constructs.

      2) I can set another option (don't remember which one) that will tell
      JSLint not to check indentation
      which allows me to write "if (err) { throw err; }" all on one line.
      I don't want to do this because I still want indentation checking.

      What I really want is an option to tell JSLint that single line "if"
      statements where a single statement follows the condition don't need
      braces.
      Am I the only one that wants this?
      Please, oh please add that option.

      --
      R. Mark Volkmann
      Object Computing, Inc.
    • Douglas Crockford
      ... I don t know. I do know that you would be better off in the long run to accept JSLint s advice.
      Message 2 of 9 , Aug 21 3:35 PM
      • 0 Attachment
        On 8/21/2010 1:52 PM, Mark Volkmann wrote:
        > Am I the only one that wants this?
        I don't know. I do know that you would be better off in the long run to
        accept JSLint's advice.
      • 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 3 of 9 , Aug 22 5:36 AM
        • 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 4 of 9 , Aug 23 12:46 PM
          • 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 5 of 9 , Aug 23 1:10 PM
            • 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 6 of 9 , Aug 23 3:57 PM
              • 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 7 of 9 , Aug 23 7:27 PM
                • 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 8 of 9 , Aug 25 8:19 AM
                  • 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 9 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.