s
Visual Architecture
Code conventions
Version 1.0
Visual Architecture
Code conventions
Version:
1.0
Date: 2010-01-21
Revision History
Date
2010-01-21
Version
1.00
Description
Final version
Author
Vedran Palajić
2
Visual Architecture
Code conventions
Version:
1.0
Date: 2010-01-21
Table of Contents
1.
1.
Introduction
1. Purpose of this document
2. Intended Audience
3. Scope
4. Coding conventions
3
Visual Architecture
Code conventions
1.
1.
Version:
1.0
Date: 2010-01-21
Introduction
Purpose of this document
The purpose of this document if so provide the rules for the whole developing group to how the coding should
be done.
2.
Intended Audience
The document is mostly targeted the following user groups
● Project Members
3.
Scope
This document will define how the coding progress should be done. This includes class naming, variable
naming, method naming, encapsulating, interface exposing and code quality.
4.
Coding conventions
Naming conventions:
Class names
Class names should start with capital letters. If the name consists of more words each new word should start
with capital letter as well. No special symbols should be used when defining a class name. For example
VisualArchitectureClass is good class name. Bad class names are visualArchitectureClass or
Visualarchitectureclass or visual_Architecture_Class.
It is advised that class names are nouns which give a hint of what the class name is doing. For example class
VisualArchitectureDiagram could be a good name for class which contains and manipulates some kind of
diagram which has to do something with visual architecture. Naming it something which does have no
connection with architecture or diagram would be bad.
Variable names
Variable names should not start with capital letters. If the name of variable consists of more words each new
word should start with capital letter as well. No special symbols should be used when defining a variable name.
For example visualArchitectureVariable is a good variable name. Bad variable names are
VisualArchitectureVariable or visualarchitecturevariable or visual_Architecture_Variable.
It is advised that variable names are descriptive nouns which means that they give a strong hint of what the
variable is used for. For example diagramPath is good name for a variable which stores the path to some kind of
diagram used in program. Naming it with something which has no connection to diagrams or paths would be
bad.
Method names
Method names should not start with capital letter. If the name of method consists of more words each new word
should start with capital letter as well. No special symbols should be used when defining a method name. For
example startProgram is a good method name. Bad method names are StartProgram, startprogram or
start_Program.
It is advised that method names are verbs which describe what the method is supposed to do. For example
startProgram is good method name for method which actually starts program. Naming it something which has
no connection with starting something or with a program would be bad.
4
Visual Architecture
Code conventions
Version:
1.0
Date: 2010-01-21
If method is used to get or set a name of the variable its name should start with get and set respectively fallowed
by variable name. For this purpose only capitalize the first letter of variable name.
General naming advises
Names should not be to short or to long. Advise is to use two or three maybe maximum of for words when
naming classes, variable and methods. Another advise it to keep the number of variables classes or methods
with very long names to minimum. Names with more then 16 letters are considered very long.
When descriptive names should always be in English language. Full word usage is advised. If the names end up
to long some letters can be left out but try to avoid this as often as possible.
Encapsulation
Make sure that only those parts of class are visible to other classes that are absolutely necessary. Make those
methods and variables which have to accessed by other classes public and everything else private.
It is advised to start with making everything private and turn something from private to public when its needed.
Avoid making variables directly public. Make them private and define methods for setting and getting values of
this variables instead.
Code quality
Declare variables as close to the point where u will use them as possible.
Aim that each variable is only visible and usable in as small part of the code as possible. If some variable is only
needed inside function don’t make it globally visible inside whole class. If some variable is only needed inside
the loop declare it inside the loop and hence make it visible only there.
Make sure variable and method names are descriptive and give a hint of what is there purpose.
Do not use variables for more then one purpose. If you need to store same type of that at two parts of program
do not use the same variable regardless if the old value its no longer needed.
When returning a value do not use special variable values to point to special events like errors and such. If
method should return a value between 50 and 100 do not return -1 to indicate an error throw an exception
instead.
5