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

1438Re: [jslint] Re: one line if statements

Expand Messages
  • Mark Volkmann
    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]
    • Show all 9 messages in this topic