Code ownership and standards

I am just digging into Dr Neil Roodyn's book eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers. Some short points he makes in the introductory overview are

• coding standards - by having everybody write code a similar style, it makes it easier for anybody (or pair) in the team modify and refactor as necessary. Which brings the next point...
• collective ownership - nobody singular owns any code - the team owns the code. It is the team that produces the solution, thus ownership is not isolated and segregated. This will drive the previous point, allowing more brains to work on a piece or module, instead of pushing to specific individuals. (Of course, this doesn't mean anybody should do everything, and thereby breaking the principle of specialists. Just that responsibility can be shared.)
  

As such, i'd like for the developers in our group to come together and agree on a coding standard for us to work on. There are already multiples in the Internet, so find one you love and bring to the table. Let us discuss over all of them, and evolve to our own.

A physical meeting is preferred.

I am not aware of any coding standard. I just used mine, which I'm comfortable in. If we want to standardise, we will need to meet soon. I'm briefing daren about the event system I want him to start to streamline the registration and stuff. Time that is required by microlau to do it is now is better used somewhere else

I usually follow what is recommended in MSDN. They have something on coding standards for .NET.

Hmm, I once read a guideline on coding standards published by Iridium Software on C#/Vb.net

Can be downloaded here

Firedancer wrote:

I usually follow what is recommended in MSDN. They have something on coding standards for .NET.

Those are design guidelines that are pretty much language agnostic. I am looking at language-specific standards, as well as code layout.

Things like

• type of commenting syntax to use in aspx pages. (I typically use <%-- "hidden" comments --%>)
• order of code-behind code (e.g page event handlers, custom handlers, protected properties, custom interface methods....)
  
• where to position curly braces. (yes)
• is omission of curly braces for one-line scope permissible (useful).
  
• order of namespaces, members, etc. (e.g. properties private, then protected, then public, then constructor, then events, then sub-classes....)
• useful region categories.
  
• spacing between operators and operands.
• breaking of methods with long parameter signatures.
• and many more...
  

icelava wrote:

type of commenting syntax to use in aspx pages. (I typically use ) order of code-behind code (e.g page event handlers, custom handlers, protected properties, custom interface methods....) where to position curly braces. (yes) is omission of curly braces for one-line scope permissible (useful). order of namespaces, members, etc. (e.g. properties private, then protected, then public, then constructor, then events, then sub-classes....) useful region categories. spacing between operators and operands. breaking of methods with long parameter signatures. and many more...

I used to have a manager who controls me like that. At one point in time, I thought it was a good thing to do. However, I don't think that is a good thing to do anymore because the objective of the developer is to develop the solution and not pass-up a beautifully formatted assignment paper.

As long as they conform to some standards i.e. no hungarian notation, no d1, d2, d3 as variable names and etc., I will accept it. I would like my developers to have the freedom in organizing their code. Afterall, they are adults. For code that I would like it to be organized my way, I automate it with my framework.

Firedancer wrote:

I used to have a manager who controls me like that. At one point in time, I thought it was a good thing to do. However, I don't think that is a good thing to do anymore because the objective of the developer is to develop the solution and not pass-up a beautifully formatted assignment paper.

I agree with that. No matter wat, the solution must be developed and the objectives meant. But of course coding standards must maintain. But if must place both(meeting requirements and coding standard) on a scale, I personally feel that meeting the objectives will be of more importance

Firedancer wrote:

I used to have a manager who controls me like that. At one point in time, I thought it was a good thing to do. However, I don't think that is a good thing to do anymore because the objective of the developer is to develop the solution and not pass-up a beautifully formatted assignment paper.

And thereby running the promise that everybody writes according to his/her own style. Which is the very point of formulating such a standard in the first place - so that developers don't get too attached to their code and making it difficult for others to read and work on. The spotlight is on the team, not the individual developer.

icelava wrote:

Firedancer wrote: I usually follow what is recommended in MSDN. They have something on coding standards for .NET. Those are design guidelines that are pretty much language agnostic. I am looking at language-specific standards, as well as code layout. Things like type of commenting syntax to use in aspx pages. (I typically use ) order of code-behind code (e.g page event handlers, custom handlers, protected properties, custom interface methods....) where to position curly braces. (yes) is omission of curly braces for one-line scope permissible (useful). order of namespaces, members, etc. (e.g. properties private, then protected, then public, then constructor, then events, then sub-classes....) useful region categories. spacing between operators and operands. breaking of methods with long parameter signatures. and many more...

I think your list is a bit overkill.

kitkai wrote:

I think your list is a bit overkill.

Minor and petty they might seem, these little things add up. And there are many more unmentioned. Remember, if you intend to present these code to the public, presenting a mesh of patterns that shout "amateurishly individual!" is really going to give them a tough time trying to abosrb the nature and style of writing. It is all about preparing and "briefing" the mind on how to read the code and look for certain things.