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

Re: [cinci-art] Coding Standards Documentation

Expand Messages
  • Rob Biedenharn
    ... That s easy, never use a TAB character — ever. ... One caveat to all of this is that you tend to respect the existing formating of code. Right is
    Message 1 of 4 , May 12, 2011
    View Source
    • 0 Attachment
      On May 12, 2011, at 6:56 PM, Edward Sumerfield wrote:
      The key drivers to coding standards on an Agile project are:

      -  shared code ownership, so if you have to edit someone else's code you soon get through the tab/no-tab arguments.

      That's easy, never use a TAB character — ever.


      -  pair programming as you mention because the conversation is more powerful and adaptable that your out of date doc.

      -  communication, as a fundamental ensures that the team is talking about the issues they notice and indentation is always one of them. The coding standards document is also a way to communicate these ideas but the doc should have a self destruct built in of one month. The best documentation is existing code.

      -  team room, reenforces communication and brings up complaints about the curly braces often enough that a solution is found.

      That is not to say that everyone will follow but there is no solution to that. If a team values coding standards then the team is responsible for policing themselves.

      One caveat to all of this is that you tend to respect the existing formating of code. "Right" is better than wrong, but consistently wrong is better than inconsistent.

      When formatting is done for formatting sake (esp. for trailing whitespace; one of my pet-peeves), put those changes into a commit separate from other code changes.


      Another cool approach is a pre-checkin hook to auto-format everything.

      I've never found an auto-formatter that got it "right" (for whatever definition) 100% of the time to make this truly worthwhile.

      However, I do defer to Emacs when I don't have a strong opinion about indentation. At least back in the day when I was coding in C, there was a sufficiently rich set of options to control the indentation style.

      I think I still have the book any my errata for C Programming Style that was the basis for coding standards where I worked from 1992-1995.  In that situation, the bunch of coders were Pascal programmers being converted to C and so a common starting point that included a reasonable justification for why  the particular style convention was used helped greatly.

      -Rob


      On Thu, May 12, 2011 at 17:37, Carin <gigasquid@...> wrote:
       

      I was poking through a code base and came across an ancient document of Coding Standards. It obviously hadn't been updated in years and was not even close to useful.

      So what does Agile have to say about getting everyone on the same coding style, standards for a project. Does the problem go away when you pair and it is passed on by Oral tradition + pairing code review?





      +1 513-295-4739
      Skype: rob.biedenharn




      Begin forwarded message:

      From: Edward Sumerfield <esumerfd@...>

      Date: May 12, 2011 6:56:24 PM EDT

      To: cinci-art@yahoogroups.com

      Subject: Re: [cinci-art] Coding Standards Documentation

      Reply-To: cinci-art@yahoogroups.com


      The key drivers to coding standards on an Agile project are:

      -  shared code ownership, so if you have to edit someone else's code you soon get through the tab/no-tab arguments.

      -  pair programming as you mention because the conversation is more powerful and adaptable that your out of date doc.

      -  communication, as a fundamental ensures that the team is talking about the issues they notice and indentation is always one of them. The coding standards document is also a way to communicate these ideas but the doc should have a self destruct built in of one month. The best documentation is existing code.

      -  team room, reenforces communication and brings up complaints about the curly braces often enough that a solution is found.

      That is not to say that everyone will follow but there is no solution to that. If a team values coding standards then the team is responsible for policing themselves.

      Another cool approach is a pre-checkin hook to auto-format everything.


      On Thu, May 12, 2011 at 17:37, Carin <gigasquid@...> wrote:
       

      I was poking through a code base and came across an ancient document of Coding Standards. It obviously hadn't been updated in years and was not even close to useful.

      So what does Agile have to say about getting everyone on the same coding style, standards for a project. Does the problem go away when you pair and it is passed on by Oral tradition + pairing code review?


    Your message has been successfully submitted and would be delivered to recipients shortly.