The aim of standardization is to make reading simpler code, for both
of others as the author himself. Thus it reduces testing costs and
maintenance. Costs mainly I refer to the time lost to testing and
In oriented programming objects should be created a
file for each class, with the same class name, or two if there
declaration file and implementation. Programming not object-oriented,
the project should be divided into modules, each module being a file.
This modules should contain functions that are related to each other,
and should not be very large.
The language used should always be
the same throughout the code, both in the names of variables and
functions as the reviews.
Each line of code must begin with four spaces for each block of code
that is inserted. I usually use two spaces, the important thing is
always the same throughout the file.
Size of lines:
Lines as much code as comments should not exceed 80 characters. If
you can not, it must occupy more than one line. In the second line
of code is indented, in the comments do not.
Arguments: The argument lists, both in the
definition and in call
are not considered code blocks. So should be written on the same
line, taking into account the size of the line.
Block start: The start
tag and end of code block should use a line to the beginning and one
for the end of the block. Functional languages can
ignore this rule, since in general the first block element is an
identifier and it is appropriate that it is the same line as the
opening block. Fortran, for example, is procedural programming but
is similar to functional programming. Here let a line only for the
block start mark does not consider essential, the important thing is
to be constant.
Location: Comments should precede the code that
Class Comments: At the
beginning of each class must be a class comment. Must contain the
author, last modification, description.
Methods Comments: Each method should also have an
to date last modified, the algorithm description, the temporal
complexity, conditions, for example the vector elements are
arranged, and restrictions, for example maximum value.
Line Comment: Place
only in complex areas and assume that the reader knows the
It is not easy to write comments. First because when the code is
complex is also difficult to explain, second because we are focused
programming and uninspired for literature, to briefly add something
useful. And also how the code works without comment we tend to leave
then, but there are comments that can not wait till later because
even the author himself later may have difficulty understanding the
Variable names must begin with a lowercase letter. The integer
variables must be iterator i, j and k. For actual iterator or other
variables l, m and n.
No iterator variable:
Not iterator variables should use explanatory names. At the junction
of two names the first letter of the second name should be
capitalized. If there are explanatory names, using u, v and w for
integers x, y, z for real, a, b and c for strings, and p, q and r
Constants and macros: They must be written in capital letters, and
words separated by an "underscore": '_'.
Structures and classes: They always have explanatory names and must
begin by T if an abstract data type, S if a structure, and C is a
class overall, D if a class to an interface dialogs print shop. At
the junction of two names, the first letter of each name should be
Methods: The method names should always have explanatory names. In
the case of non-object-oriented programming, the names of functions
and procedures must be preceded by the name or initials of the
module to which they belong. At the junction of two names, the first
letter of each name should be capitalized. Do not use the same name
for functions or methods with different arguments, except that the
functions or methods are just different versions. In principle, the
name of a procedure must contain a verb in the infinitive, while the
name of a function must have the name of the greatness that
calculates, not requiring verb. Functions with Boolean result should
contain a verb or adjective in the present in order to be used
The names are similar to those comments: difficult to obtain
essential for understanding the code irrelevant to execution. But the
size does not affect productivity or create problems there mistakes
code blocks: Do not open code block to a single command. For
example, a for loop with an instruction only is unnecessary braces.
Repetitions: Do not repeat a sequence of commands. Many times a user
to write code, repeated commands when they could be placed within a
Size of the method: size of methods: Do not make too big methods
(over 100 lines of code). In this case the command group related to
methods, even though the method will be called once.
Commands on one line: Always start a new row for a command.