Programming style

A programming style (English code conventions, coding conventions, coding standards ) is in programming to create source code according to certain prescribed rules. He is regarded as one aspect of software quality, the gem in particular the clarity and maintainability of software, these are criteria for software quality. ISO / IEC 9126, is to assist.

Regulate to a programming style and the specifications, " like" a program, that is, its source code, is to be designed in formal and structural point of view - regardless of "what" is to make the program. Three aspects work together:

• The rule: The definition of rules or conventions / standards. In the sense of (software ) ' quality ' ( = ' meeting requests ' ) are the ' requirements '.
• The plot: The relocation / recognition of these rules; ' Programming ' / creating program code
• The result: The source code with its structure and appearance; in the context of quality assurance on compliance with the requirement (s) checked

In a broader sense, the programming paradigms are considered ( fundamental ) programming style.

The evaluation of a programming style usually requires a deep semantic understanding of the program source code. For this reason StyleChecker and Beautifier are not yet or only extremely limited ability with respect to these elements to carry out or to ensure compliance checking for a good programming style.

Purpose

The purpose of a defined programming style is to facilitate the work of all team members involved in a programming project. This applies in particular to the readability, comprehensibility and maintainability of software source code or the elimination of avoidable errors in programs.

In terms of comprehensibility and maintainability can restrict the use of program language allowed (but " dirty" ) program constructs or completely prohibit a policy. Compliance with previously defined nomenclature for variables, procedures, and class names can substantially improve readability and maintainability of the program code.

During maintenance, the maintenance of a defined programming style is more important than during development. A guideline is that 80 % of the lifetime of a software product is accounted for maintenance. Rarely a product is maintained by the original programmer. It, that is already used from the first moment a good programming style is more important.

A programming style should not necessarily be interpreted as a doctrine. Violations should be allowed, provided they are well-founded. This can improve in some cases, for example (in the style of programming in the narrower sense) through optimized space utilization track, serve by emphasizing certain details of the course or pursue as an ad hoc special rule for particular parts of the code, the goals of programming style by other means.

Examples of elements of programming style

The content that is the subject of a programming style, can be different from the case of the case. The spectrum ranges from simple specifications for code structuring ( indentation ) to specifications for all the "how" of the relevant details implementation.

In larger projects and companies, where many stakeholders work together in software development, requirements are often set to the programming style in programming guidelines. Often these are based on published as an apprentice or international conventions and recommendations; Examples are the ' Hungarian Notation ' or the ' java code conventions '). A portion of the rules is focused on the programming language used. Single or multiple elements can be important depending on the situation differently (from 'must ' to ' not relevant '); For example, depending on whether the software is to be used only once or permanently. In the private or non-commercial area of ​​software developers often turn to only a learned or intuitively applied, not explicitly defined programming style.

Examples of elements of programming style ( and even after ) are listed below:

• Use the usual procedures in the chosen programming paradigm (eg, object -oriented programming )
• Establishing naming conventions: How are identifiers to choose?
• Application of design patterns
• Use of compiler directives and switches
• Structuring the code ( indenting, Modul-/Prozedurgröße, GOTO ban): Where are spaces available? How to be engaged? Maximum number of lines of a routine.
• Typing ( choice of the type of a symbol or a variable)
• Initializing variables
• Access to variable foreign objects / procedures
• Design of function calls ( parameter transfers, return values ​​)
• Standard components dutifully to be used as subroutines, APIs, etc.
• Avoid redundancy and wide as possible reusability - through modularization
• Independence of different parts of the program ( modularity )
• Uniformity in the solution of similar problems, eg by Standardized programming
• Robustness through detailed error and exception handling
• Extent and form of documentation: the procedure for each line; detail; matched to other documents

Example source code formatting

Important aspects of programming style are the arrangement of sub- program elements ( Indent ) which have, directly on the positioning enclosing syntax elements, such as { }, [], (), BEGIN or END influence, and the use of blank lines and the nesting subordinate program elements.

In addition, the absence of comments in the source code is a sign of bad programming style. A programmer always has to assume that his code must be read and understood by others, this comments are essential. Nowadays, there are also often fixed formats for comments that explain, for example, input and output parameters of a function or method individually. These can then be used by automated documentation programs like doxygen or javadoc to automatically generate a human-readable documentation.

The naming conventions for symbols play an important role in relation to the assessment of programming style. The name of a symbol should adequately explain the function or manner of use or suggest at least. Since today there is enough space for the code that is previously used space-saving use of abbreviations such as " dskmngr " no longer justified. Often, a different notation is used to read as the symbol name can whether it is a variable, a function, a class, or a constant, etc. for different types of symbols. ( See also Hungarian notation ). In this context, the length and the girth of symbols and their declaration order of importance.

These aspects of the source code formatting relate primarily to the optical readability, thereby directly but also on the comprehensibility of a program source code.

StyleChecker such as Checkstyle can check most of the criteria for a good programming style respect to these elements. Beautifier are to ensure in a position by reformatting the source code compliance with good style on these elements.

Controversial elements

The following elements of programming styles are controversial. It follows for every element a comparison of the respective arguments of the proponents and opponents. If possible, as generally accepted viewable, a recommendation closes with respect to the controversial element to the discussion.

Line length

Often a limit on the row length is considered good programming style. For such a limitation is the fact that

• Shorter lines usually are easier to read than longer (especially lighter than several long, automatically umbrochene only on a word boundary lines among each other ), see the multi-column set of newspapers
• Can be longer lines mostly semantically split into parts
• Comparison tools are similar to diff often work line by line, while easier to detect changes
• When confined to a secure printable area (80 characters) remain semantically motivated line breaks and indentation in expression

For a limiting line length is the fact that

• This requires manual work either in programming or in setting up the IDE
• Especially newer APIs long symbol names used, which favors the formation of very long lines
• Grep with the indicated reference in a search - by default a single line out of context lines - contains the complete statement

As consensus can not be that long lines should not contain more than one statement.

Indent

The indentation is probably the most controversial issue of programming style.

The following recommendations are, however, generally recognized as:

• Set within a project, part - project, team or company. Example: "For our open source projects written in C and C , we use the GNU coding standards for Java basically the Code Conventions of SUN and otherwise in accordance with Allman. "
• Consistent implementation
• No mixture of different styles in one project

Also discussed much is the question of the indentation depth for subordinate blocks and whether spaces or tabs it you should have the preference. So writes the code convention for Java, for example, an indentation depth of four spaces, the code convention for Linux maintains an indentation depth of eight characters before. The advantage of indentation with spaces is that the indentation is always maintained regardless of the display options of the display program or editor.

Tabs for indentation in return offer the advantage that any developer can even by the configuration of Tabulatorschrittweite his text editor determine the indentation depth shown. There is agreement, however, regarding the opinion that one should not mix the two variants. A mixture of tabs and spaces in indentation leads to inconsistent indenting for items on the same hierarchy level, what readability is more detrimental.

Regulations

Some quality standards in the software environment (IEC 61508, CMMI, SPICE, etc.) require explicitly the application of certain rules. In the environment of the automotive industry in the MISRA -C is used for example.