Code Library

Traditionally the XP practice of coding standards focused on a set of rules that the development team agreed upon for the formatting and naming conventions of code. In our experience, coding standards go far beyond formatting and naming conventions. We are far more concerned with overly long methods and poorly named variables than the need to underscore local variables.

Coding standards dictate such things as keeping each method’s source code no longer than the height of your monitor, and having self-documenting code. That, in turn, entails properly naming variables—avoiding such mysterious names as i or j—and instead giving each variable a meaningful name so that the next programmer can quickly understand the role it plays. A good software craftsman will not program only for himself, but “program ahead” and write easily maintainable code for the next person coming in to add a new feature.

A standard code style throughout a project will certainly contribute to collective ownership and help people working on different parts of the system to recognize the style and formatting. Popular tools such as JetBrains’ ReSharper can highlight coding that does not adhere to a defined set of coding standards, so when a coding style is agreed upon it is easy to implement.

We feel it is important to ensure that code is well written and clearly conveys its intention. A great resource that can help with creating clean code is Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin (Prentice Hall, 2008). Another way to ensure coding standards are adhered to is to have all developers understand the SOLID set of design principles as catalogued in Agile Principles, Patterns, and Practices in C# by Robert Martin (Prentice Hall, 2006).

Briefly, the SOLID design principles are as follows:

• Single Responsibility Principle: An object should have only a single responsibility—a focused task.

• Open/Closed Principle: Software entities should be open for extension, but closed for modification.

• Liskov Substitution Principle: Objects in a program should have the ability to be replaced by instances of their subtypes without altering the correctness of that program. Typically, this is accomplished through design by contract.

• Interface Segregation Principle: Many client-specific interfaces are better than one general-purpose interface.

• Dependency Inversion Principle: Develop against abstractions and do not depend upon concretions.

Source of Information : Pro Agile .NET Development with SCRUM