| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-xo5gft-2zQGWhxjKcGxSQQ" |
| name="new_concept,_0lnRMMqOEduwrYVlQ9zp3w" guid="-xo5gft-2zQGWhxjKcGxSQQ" changeDate="2008-01-08T17:21:22.030-0800" |
| version="1.0.0"> |
| <mainDescription><p>
 |
| Using a coding standard is a widely accepted software development practice. The need for this practice takes on added
 |
| importance in a highly collaborative environment. The team should have a standard way of naming and formatting things
 |
| so they can understand the code quickly and know where to look at all times. This enables shared code ownership since
 |
| any team member should be able to quickly understand the code written by others.&nbsp;
 |
| </p>
 |
| <p>
 |
| Ideally, the coding standard should be the result of team consensus. Involving the team members will aid adoption of
 |
| the standards.
 |
| </p>
 |
| <p>
 |
| Coding Standards cover such areas as:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Naming standards. This includes the naming of elements all the way down to the smallest variable. In covering
 |
| larger-scale elements, this overlaps into what could be considered design standards.
 |
| </li>
 |
| <li>
 |
| File organization. This includes file naming conventions and how the files will be organized on the file system.
 |
| </li>
 |
| <li>
 |
| Comment standards. Too much emphasis on comments implies a lack of confidence that readable code is being written,
 |
| plus there is always a concern that the comments are not up to date. Yet, a consistent approach to comments
 |
| improves understandability and can support the ability to generate documentation from the code.
 |
| </li>
 |
| <li>
 |
| Coding conventions. Consistent application of specific code-level conventions and the exclusion of some considered
 |
| poor form improve the quality of the code.
 |
| </li>
 |
| <li>
 |
| White space. Though it can be argued to be less critical than the other items listed here, a consistent usage of
 |
| white space as indentation and blank lines also improves readability.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| In some cases, decisions will be arbitrary (like how much to indent). Each item in the standard should support one or
 |
| more goals, improved communication being one of the most critical goals. Once the team agrees on a standard, all
 |
| members of the teams are expected to follow it. With time, the team will use and modify the standard to develop a style
 |
| that is well adapted to the environment.
 |
| </p>
 |
| <p>
 |
| Though some standards can transcend any language, coding standards must be language specific for the most part.
 |
| </p>
 |
| <p>
 |
| For example coding standards, see the <a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html" target="_blank">Code Conventions for the JavaTM Programming Language</a> or these <a href="http://blogs.msdn.com/brada/articles/361363.aspx" target="_blank">Internal Coding Guidelines</a> for .NET
 |
| development.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
