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

Re: [jslint] dot property name

Expand Messages
  • Jean-Charles Meyrignac
    ... As a C coder, I prefer the following: function func1(foo) { var bar = foo .replace( o , 0 ) .replace( a , 4 ); return bar; } In my opinion, the dot
    Message 1 of 9 , Aug 25, 2010
    • 0 Attachment
      On Thu, Aug 26, 2010 at 12:44 AM, Marcel Duran <contact@...>wrote:

      > Couldn't it be optional?
      >
      > I believe this is useful when indenting long chain of methods like some
      > popular JS frameworks do.
      >
      > The following although correct wouldn't be OK to JSLint:
      > function func1(foo) {
      > var bar = foo.
      > replace('o', '0').
      > replace('a', '4');
      > return bar;
      > }
      >
      >
      As a C coder, I prefer the following:

      function func1(foo) {
      var bar = foo
      .replace('o', '0')
      .replace('a', '4');
      return bar;
      }

      In my opinion, the dot should always be placed before the method, not on the
      line above.

      JC


      [Non-text portions of this message have been removed]
    • Mark Volkmann
      ... This is how I indent long chains of method calls. ... -- R. Mark Volkmann Object Computing, Inc.
      Message 2 of 9 , Aug 25, 2010
      • 0 Attachment
        On Wed, Aug 25, 2010 at 5:44 PM, Marcel Duran <contact@...> wrote:
        > Couldn't it be optional?
        >
        > I believe this is useful when indenting long chain of methods like some
        > popular JS frameworks do.
        >
        > The following although correct wouldn't be OK to JSLint:
        > function func1(foo) {
        >    var bar = foo.
        >            replace('o', '0').
        >            replace('a', '4');
        >    return bar;
        > }

        This is how I indent long chains of method calls.

        > A possible workaround would be:
        > function func2(foo) {
        >    var bar = foo.replace(
        >            'o', '0'
        >        ).replace(
        >            'a', '4'
        >        );
        >    return bar;
        > }
        >
        > Not sure how developers are indenting long chains, specially jQuery ones.
        >
        > Marcel
        >
        >
        > On Wed, Aug 25, 2010 at 3:17 PM, Douglas Crockford <douglas@...>wrote:
        >
        >>
        >>
        >> JSLint now requires that there be no whitespace or line break between a .
        >> and a property name. This has always been a good practice, and is now
        >> especially desirable because of reserved word relaxation in ES5.
        > --
        > Marcel Duran

        --
        R. Mark Volkmann
        Object Computing, Inc.
      • Rob Richardson
        I prefer to indent long chains by putting the dot at the beginning of the next line like so: var bar = foo .replace( o , 0 ) .click(function () {
        Message 3 of 9 , Aug 25, 2010
        • 0 Attachment
          I prefer to indent long chains by putting the dot at the beginning of the
          next line like so:

          var bar = foo
          .replace('o', '0')
          .click(function () {
          $(this).hide();
          };

          In this way it's clear to me by scanning the far left edge of my code that
          "replace" and "click" aren't under-declared vars.

          Rob


          On Wed, Aug 25, 2010 at 3:55 PM, Mark Volkmann <r.mark.volkmann@...>wrote:

          >
          >
          > On Wed, Aug 25, 2010 at 5:44 PM, Marcel Duran <contact@...<contact%40marcelduran.com>>
          > wrote:
          > > Couldn't it be optional?
          > >
          > > I believe this is useful when indenting long chain of methods like some
          > > popular JS frameworks do.
          > >
          > > The following although correct wouldn't be OK to JSLint:
          > > function func1(foo) {
          > > var bar = foo.
          > > replace('o', '0').
          > > replace('a', '4');
          > > return bar;
          > > }
          >
          > This is how I indent long chains of method calls.
          >
          >
          > > A possible workaround would be:
          > > function func2(foo) {
          > > var bar = foo.replace(
          > > 'o', '0'
          > > ).replace(
          > > 'a', '4'
          > > );
          > > return bar;
          > > }
          > >
          > > Not sure how developers are indenting long chains, specially jQuery ones.
          > >
          > > Marcel
          > >
          > >
          > > On Wed, Aug 25, 2010 at 3:17 PM, Douglas Crockford <
          > douglas@... <douglas%40crockford.com>>wrote:
          > >
          > >>
          > >>
          > >> JSLint now requires that there be no whitespace or line break between a
          > .
          > >> and a property name. This has always been a good practice, and is now
          > >> especially desirable because of reserved word relaxation in ES5.
          > > --
          > > Marcel Duran
          >
          > --
          > R. Mark Volkmann
          > Object Computing, Inc.
          >


          [Non-text portions of this message have been removed]
        • Frederik Dohr
          ... I would prefer this as well. My colleagues and I made a conscious decision to use a trailing dot to indicate line continuation, which turned out positive
          Message 4 of 9 , Aug 26, 2010
          • 0 Attachment
            > Couldn't it be optional?

            I would prefer this as well.
            My colleagues and I made a conscious decision to use a trailing dot to
            indicate line continuation, which turned out positive in terms of code
            maintenance.


            -- F.
          • Douglas Crockford
            ... I made the same decision as well, and I now believe that decision was incorrect. I recommend that you update your code.
            Message 5 of 9 , Aug 26, 2010
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, Frederik Dohr <fdg001@...> wrote:
              >
              > > Couldn't it be optional?
              >
              > I would prefer this as well.
              > My colleagues and I made a conscious decision to use a trailing dot to
              > indicate line continuation, which turned out positive in terms of code
              > maintenance.

              I made the same decision as well, and I now believe that decision was incorrect. I recommend that you update your code.
            • g2223060
              I agree about the leading dot- it is an obvious hint that the line continues the one above it. I dislike the trailing dot on the previous line. I think DC
              Message 6 of 9 , Aug 26, 2010
              • 0 Attachment
                I agree about the leading dot- it is an obvious hint that the line continues the one above it. I dislike the trailing dot on the previous line. I think DC said it right- whitespace after the dot is bad.

                --- In jslint_com@yahoogroups.com, Jean-Charles Meyrignac <jcmeyrignac@...> wrote:

                > As a C coder, I prefer the following:
                >
                > function func1(foo) {
                > var bar = foo
                > .replace('o', '0')
                > .replace('a', '4');
                > return bar;
                > }
                >
                > In my opinion, the dot should always be placed before the method, not on the
                > line above.
                >
              • Michael S. Mikowski
                FWIW, here s my $0.02: Porting style from Conway s PBP, breaking before every operator and using K&R style indenting makes for very readable JS code IMO. var
                Message 7 of 9 , Sep 13, 2010
                • 0 Attachment
                  FWIW, here's my $0.02:

                  Porting style from Conway's PBP, breaking before every operator and using K&R
                  style indenting makes for very readable JS code IMO.

                  var fnHello = function (){
                  if ( ary_foo.length > 25
                  || ary_foo < 5
                  ){
                  hash_elem.$body
                  .find('div .namespace')
                  .html( ''
                  + '<h3>Hello</h3>
                  + '<p>'
                  + 'Hello World'
                  + '</p>'
                  )
                  .end()
                  .find('input')
                  .css({'border-color':'#f00'})
                  ;
                  hash_state.sw_foo = true;
                  }
                  };

                  Compare with the alternative:

                  var fnHello = function (){
                  if ( ary_foo.length > 25 ||
                  ary_foo < 5
                  ){
                  hash_elem.
                  $body.
                  find('div .namespace').
                  html('<h3>Hello</h3> +
                  '<p>' +
                  'Hello World' +
                  '</p>').
                  end().find('input').
                  css({'border-color':'#f00'});
                  hash_state.sw_foo = true;
                  }
                  };

                  Operators on the end make them very hard to spot, not just the ., but also the
                  || and the +.

                  Keeping all lines below 80 characters allows me to view 3 files simultaneously
                  side-by-side on my monitor. Finally, all jQuery elements are prefixed by a '$'
                  sigil, a handy convention.

                  YMMV.

                  Cheers, Mike


                  On Thursday, August 26, 2010 05:57:23 am Douglas Crockford wrote:
                  > --- In jslint_com@yahoogroups.com, Frederik Dohr <fdg001@...> wrote:
                  > > > Couldn't it be optional?
                  > >
                  > > I would prefer this as well.
                  > > My colleagues and I made a conscious decision to use a trailing dot to
                  > > indicate line continuation, which turned out positive in terms of code
                  > > maintenance.
                  >
                  > I made the same decision as well, and I now believe that decision was
                  > incorrect. I recommend that you update your code.


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