Scribd
Upload
49 views2 pages

Coding Standard

The document discusses key elements that should be included in a coding standards document such as naming conventions, indentation, layout, exception handling, logging, and commenting. It emphasizes that the purpose is to promote uniformity across code written by different developers rather than define right and wrong approaches. The document recommends keeping coding standards simple and concise so that developers will actually follow them.

Uploaded by

courtney.sc.thompson
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
49 views2 pages

Coding Standard

The document discusses key elements that should be included in a coding standards document such as naming conventions, indentation, layout, exception handling, logging, and commenting. It emphasizes that the purpose is to promote uniformity across code written by different developers rather than define right and wrong approaches. The document recommends keeping coding standards simple and concise so that developers will actually follow them.

Uploaded by

courtney.sc.thompson
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

The first important thing to note is that a coding standards document is not about right and

wrong. It's not about good and bad or which method is better.

A coding standards document's purpose is to make sure that all code is designed, written
and laid out the same to make it easier for a developer to switch from one persons work to
another without the needed change of mentality to read someone else's style.

It's all about uniformity, and nothing about "Right and wrong"

With that in mind some things you should clarify in a coding standards document are:

Naming Conventions
How will you name your methods, variables, classes and interfaces? Which notation will you
be using?

Also something else included in our standards was a split off standards for SQL, so we had
similar names for tables, procedures, columns, id fields, triggers, etc.

Indentation
What will you be using for indentation? A single tab? 3 spaces?

Layout
Will braces be kept on the same line as the opening method line? (generally java) or on the
next line or a line of its own? (generally C#)

Exception Handling / Logging


What are your standards for exception handling & logging, is it all home grown or are you
using a third party tool? How should it be used?

Commenting
We have standards to dictate grammatical correctness, and that comments begin on the
line before, or after, not on the same line, this increases readability. Will comments have to
be indented to the same depth as the code? Will you accept those comment borders used
around larger texts?

How about the \\\ on Methods for descriptions? Are these to be used? When?

Exposure
Should all of your methods and fields be implementing the lowest level of access possible?

Also an important thing to note. A good standards document can go a long way in helping
review code, does it meet these minimum standards?

I've barely scratched the surface of what can go into one of these documents, but K.I.S.S.
Don't make it long, and boring, and impossible to get through, or those standards just wont
be followed, keep it simple.

General Principles

Formatting Conventions

Indentations, spaces, tabs (to use them or not), number of characters per line, etc.

Naming Conventions

Meaningful names (names that describes the variable use, etc)

Naming formats

(example naming formats for constants,

Variable names (boolean, numeric, string, datetime, etc.),

aliases (SQL), etc.

classes,

methods

Output files example reports, XML, EXCEL, EAM configuration exports, etc.

Input files example EXCEL, templates, etc. uploaded within EAM, etc.

Documentation Conventions

Writing comments and types of comments

Documenting changes and additions to codes

Change management related documentation such as linking changes to ITSM tickets, ADO cards, etc.

Programming Conventions

Exception handling, pop-up messaging, etc.

You might also like