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

RE: [jslint] Style

Expand Messages
  • Luke Page
    The prime example of this fragmentation can be seen with the recently announced jshint.. I m surprised no one here has yet mentioned it. I agree that
    Message 1 of 5 , Feb 28, 2011
    • 0 Attachment
      The prime example of this fragmentation can be seen with the recently
      announced jshint.. I'm surprised no one here has yet mentioned it.

      I agree that consistent style helps all developers, but as a consultant that
      has to obey corporate style documents that differ from company to company
      and someone who preaches jslint to full time javascript developers who don't
      know what === is let alone how to refactor code to use it safely (recently
      during a code review I asked a guy to make his code conform to jslint.. he
      find and replaced all == with === introducing several major bugs) I find
      jslint to be slightly too restrictive and authoritarian for the real world
      even if I continue to use it for my own greenfield development.

      However I acknowledge that too many style options can also undo the work of
      having options at all. Yes, it is a fine line.
      On 28 Feb 2011 19:52, "Rob Richardson" <erobrich@...> wrote:
      > I have to disagree. If there was a consistent style taught by all and/or
      > enforced by all, it would be reasonable to apply it universally to all in
      a
      > tool we all use. However, since we're still in a land of artisans where
      > delicately crafted recipes produce works of art, we can't limit matters of
      > preference.
      >
      > In cases where accurate execution or legibility of intent are in question,
      > no doubt a standard should be adopted.
      >
      > In cases where corporate policy or personal preference has created habits
      > that don't conform but also don't produce side-effects, the style is
      likely
      > left to what makes the developer most comfortable and thus most
      productive.
      >
      > I'm very glad that JSLint carefully balances this with options such as
      > "strict whitespace", "disallow ++ and --", "tolerate continue" that allow
      us
      > to select our preference for conformity to the proposed styles.
      >
      > I wish there were more options for this. Resharper's formatting choice
      > dialogs could be a great template here, though I grant creating an
      intuitive
      > single-page interface to that depth is tricky.
      >
      > Because such options aren't available, I've begun to see competing tools
      > emerge that fragment this space and confuse the community:
      >
      > Google Closure Linter
      > (http://closuretools.blogspot.com/2010/08/introducing-closure-linter.html)
      >
      > JavaScript Compiler (http://jscompiler.org/)
      >
      > JavaScript Memory Leak Detector
      > (
      http://blogs.msdn.com/b/gpde/archive/2009/08/03/javascript-memory-leak-dete
      > ctor-v2.aspx)
      >
      > Microsoft Ajax Minifier (http://aspnet.codeplex.com/releases/view/40584)
      >
      > Ok, I'll concede the last is more about fixing the problems and less about
      > teaching the developer not to make them.
      >
      > Rob
      >
      >
      > -----Original Message-----
      > From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
      > Behalf Of Douglas Crockford
      > Sent: Monday, February 28, 2011 11:39 AM
      > To: jslint_com@yahoogroups.com
      > Subject: [jslint] Style
      >
      > The place to express yourself in programming is in the quality of
      > your ideas, and the efficiency of execution. The role of style is
      > the same as in literature. A great writer doesn't express himself
      > by putting the spaces before his commas instead of after, or by
      > putting extra spaces inside his parentheses. A great writer will
      > slavishly conform to some rules of style, and that in no way
      > constrains his power to express himself creatively. See for
      > example William Strunk's The Elements of Style
      > [http://www.crockford.com/wrrrld/style.html%5d.
      >
      > I think this applies to programming as well. Conforming to a
      > consistent style improves readability, and frees you to express
      > yourself in ways that matter. JSLint here plays the part of a
      > stern but benevolent editor, helping you to get the style right
      > so that you can focus your creative energy where it is most needed.
      >
      >


      [Non-text portions of this message have been removed]
    • Douglas Crockford
      ... I have always been opposed to programming in ignorance, and I have worked hard to try to improve the knowledge and thoughtfulness of this community. Simply
      Message 2 of 5 , Feb 28, 2011
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
        > I agree that consistent style helps all developers, but as a consultant that
        > has to obey corporate style documents that differ from company to company
        > and someone who preaches jslint to full time javascript developers who don't
        > know what === is let alone how to refactor code to use it safely (recently
        > during a code review I asked a guy to make his code conform to jslint.. he
        > find and replaced all == with === introducing several major bugs) I find
        > jslint to be slightly too restrictive and authoritarian for the real world
        > even if I continue to use it for my own greenfield development.

        I have always been opposed to programming in ignorance, and I have worked hard to try to improve the knowledge and thoughtfulness of this community.

        Simply replacing '==' with '===' is a stupid act. I believe that JSLint can help people better programmers, but it cannot succeed if it is used stupidly.

        Many people think they have good reasons for doing things badly. JSLint's purpose is not to help them feel better about that.
      Your message has been successfully submitted and would be delivered to recipients shortly.