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

switch / case

Expand Messages
  • Rob Richardson
    JSLint doesn t barf if the last case doesn t end in a break or return. For example JSLint believes this is ok: switch (somevar) { case a : // some code
    Message 1 of 4 , Oct 25, 2010
    • 0 Attachment
      JSLint doesn't barf if the last case doesn't end in a break or return. For
      example JSLint believes this is ok:

      switch (somevar) {
      case 'a':
      // some code
      break;
      case 'b':
      // some code
      // this falls through
      }

      Also is there an option to allow formatting switch/case with the following
      indenting instead (without {white:false})?:

      switch (somevar) {
      case 'a':
      // some code
      break;
      case 'b':
      // some code
      break;
      }

      Visual Studio keeps "helping" by reformatting my code this way, and setting
      it back is getting tedious. I also prefer it this way as it highlights to
      me that case defines a block inside switch's block. (No need to start a
      religious war, just my view of the world.)

      Rob
    • Rob Richardson
      The wonderment of html spacing spoils the day again ... JSLint prefers this: switch (somevar) { case a : t// some code tbreak; case b : t// some code
      Message 2 of 4 , Oct 25, 2010
      • 0 Attachment
        The wonderment of html spacing spoils the day again ...

        JSLint prefers this:

        switch (somevar) {
        case 'a':
        \t// some code
        \tbreak;
        case 'b':
        \t// some code
        \tbreak;
        }

        Switch and case are indented the same, the case body is indented one more
        than case.

        Visual Studio and I prefer this (and Visual Studio keeps setting it this way
        to boot):

        switch (somevar) {
        \tcase 'a':
        \t\t// some code
        \t\tbreak;
        \tcase 'b':
        \t\t// some code
        \t\tbreak;
        }

        Case is indented one more than switch, the case body is indented one more
        still.

        Is there a way to flag this preference without disabling all space checking
        with {white:false}?

        Rob


        -----Original Message-----
        From: Rob Richardson [mailto:erobrich@...]
        Sent: Monday, October 25, 2010 8:03 PM
        To: 'jslint_com@yahoogroups.com'
        Subject: switch / case

        JSLint doesn't barf if the last case doesn't end in a break or return. For
        example JSLint believes this is ok:

        switch (somevar) {
        case 'a':
        // some code
        break;
        case 'b':
        // some code
        // this falls through
        }

        Also is there an option to allow formatting switch/case with the following
        indenting instead (without {white:false})?:

        switch (somevar) {
        case 'a':
        // some code
        break;
        case 'b':
        // some code
        break;
        }

        Visual Studio keeps "helping" by reformatting my code this way, and setting
        it back is getting tedious. I also prefer it this way as it highlights to
        me that case defines a block inside switch's block. (No need to start a
        religious war, just my view of the world.)

        Rob
      • Luke Page
        I d like to back Rob up - this is the only thing stopping me from switching on whitespace checking in jslint. I looked on the website for a reason and haven t
        Message 3 of 4 , Oct 29, 2010
        • 0 Attachment
          I'd like to back Rob up - this is the only thing stopping me from switching
          on whitespace checking in jslint. I looked on the website for a reason and
          haven't found one...

          On 26 October 2010 05:48, Rob Richardson <erobrich@...> wrote:

          >
          >
          > The wonderment of html spacing spoils the day again ...
          >
          > JSLint prefers this:
          >
          > switch (somevar) {
          > case 'a':
          > \t// some code
          > \tbreak;
          > case 'b':
          > \t// some code
          > \tbreak;
          > }
          >
          > Switch and case are indented the same, the case body is indented one more
          > than case.
          >
          > Visual Studio and I prefer this (and Visual Studio keeps setting it this
          > way
          > to boot):
          >
          > switch (somevar) {
          > \tcase 'a':
          > \t\t// some code
          > \t\tbreak;
          > \tcase 'b':
          > \t\t// some code
          > \t\tbreak;
          > }
          >
          > Case is indented one more than switch, the case body is indented one more
          > still.
          >
          > Is there a way to flag this preference without disabling all space checking
          > with {white:false}?
          >
          > Rob
          >
          >
          > -----Original Message-----
          > From: Rob Richardson [mailto:erobrich@... <erobrich%40robrich.org>]
          >
          > Sent: Monday, October 25, 2010 8:03 PM
          > To: 'jslint_com@yahoogroups.com <%27jslint_com%40yahoogroups.com>'
          > Subject: switch / case
          >
          > JSLint doesn't barf if the last case doesn't end in a break or return. For
          > example JSLint believes this is ok:
          >
          > switch (somevar) {
          > case 'a':
          > // some code
          > break;
          > case 'b':
          > // some code
          > // this falls through
          > }
          >
          > Also is there an option to allow formatting switch/case with the following
          > indenting instead (without {white:false})?:
          >
          > switch (somevar) {
          > case 'a':
          > // some code
          > break;
          > case 'b':
          > // some code
          > break;
          > }
          >
          > Visual Studio keeps "helping" by reformatting my code this way, and setting
          > it back is getting tedious. I also prefer it this way as it highlights to
          > me that case defines a block inside switch's block. (No need to start a
          > religious war, just my view of the world.)
          >
          > Rob
          >
          >
          >


          [Non-text portions of this message have been removed]
        • Cheney, Edward A SSG RES USAR USARC
          Luke, ... There is no uniform length definition for a tab stop character. This is several problematic with consideration for text based documentation where
          Message 4 of 4 , Oct 29, 2010
          • 0 Attachment
            Luke,

            > I looked on the website for a reason and haven't found one...

            There is no uniform length definition for a tab stop character. This is several problematic with consideration for text based documentation where there are no formal meta-data descriptions for describing or formatting the supplied content. In this regard it is absolutely essential that white space is used in a consistent and uniform manner to prevent confusion in the presentation of such documentation. JavaScript is inherently text based at every step of its life including interpretation, and every good programmer should write timely and comprehensive documentation to describe their contributions and the description of functionality in any code base regardless of the accessibility to that documentation.

            For examples of rather complex text based documentation that has stood the tests of time read the RFCs, internet drafts, and other works published by the IETF. Text based documentation was the de facto universal standard 20 years ago, and it is still widely circulated in the world of computer science.

            In Crockford's defense he has discussed this in the third section of this page:
            http://javascript.crockford.com/code.html

            In your defense this reasoning is entirely absent from jslint.com/lint.html

            Thanks,

            Austin Cheney, CISSP
            http://prettydiff.com/
          Your message has been successfully submitted and would be delivered to recipients shortly.