Coding Standards

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 maintenance.
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.

Formatting:

• Indentation: 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.

Comments:

• Location: Comments should precede the code that comment.

• 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 initial comment, 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 programming language.

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 code.

Names:

• Iterated variables: 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 for pointers.

• 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 capitalized.

• 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 inside conditional.

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 writing.

Style:

• 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 cycle.

• 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.

________
ZXCoders