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

Re: one line if statements

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.