Programming style

from Wikipedia, the free encyclopedia

A programming style ( code conventions , coding conventions , coding standards ) in programming is the creation of source code according to certain predetermined rules. It is considered a partial aspect of software quality , in particular the comprehensibility and maintainability of software ; these are criteria for software quality in accordance with To support ISO / IEC 9126 (updated by ISO / IEC 25000 ).

A programming style and the specifications for it regulate "how" a program, i. H. its source code should be designed in terms of form and structure - regardless of "what" the program should do. Three aspects work together:

  • The rule: the definition of rules or conventions / standards. In the sense of (software) “quality” (= “meeting requirements”), these are “requirements”.
  • The action: Implementing / observing these rules; 'Programming' / creating program code
  • The result: the source text with its structure and appearance; Can be checked for compliance with the regulation (s) as part of quality assurance

In a broader sense, the programming paradigms also apply as a (fundamental) programming style.

Assessing a programming style usually requires a deep semantic understanding of the program source code. For this reason, the Style Checker and Beautifier have so far not been able, or only to a very limited extent , to check for a good programming style with regard to these elements or to be able to guarantee compliance.

purpose

The purpose of a defined programming style is to make the work of all team members involved in a programming project easier. This relates in particular to the readability, comprehensibility and maintainability of program source text and the elimination of avoidable sources of error in programs.

In the interests of comprehensibility and maintainability, a guideline can restrict or prohibit the use of program constructs that are permitted (but “unclean”) in the program language. Adhering to previously defined nomenclatures for variables, procedures and class names can significantly improve the readability and maintainability of program code.

Adhering to a defined programming style is even more important during maintenance than during development. As a guide, 80% of the life of a software product is spent on maintenance. Often times a program is not maintained by the original person who wrote it. It is all the more important that a good programming style is used from the very first moment.

A programming style shouldn't necessarily be construed like a doctrine. Violations of this should be allowed as long as they are well justified. In individual cases, for example (in the case of programming style in the narrower sense), this can improve the overview through optimized use of space, emphasize certain details for clarity, or pursue the goals of the programming style by other means as an ad hoc special rule for particular code parts.

Examples of elements of programming style

The content that is the subject of a programming style may vary from case to case. The bandwidth ranges from simple specifications for structuring the code (indentations) to specifications for all the details relating to the "how" of the implementation .

In larger projects and companies where many people are involved in software development , the programming style requirements are often specified in programming guidelines. Often these are based on inter-company or internationally published conventions and recommendations; Examples are the “ Hungarian Notation ” or the “Java Code Conventions”. Some of the rules are geared towards the programming language used . Individual or many elements can be important depending on the situation (from “must” to “not relevant”); z. B. depending on whether the software is to be used only once or permanently. In the private or non-commercial sector, software developers often only use a programming style that has been learned or used intuitively and is not explicitly defined.

Examples of elements of the programming style are listed below (including from):

  • Use of the usual procedures in the selected programming paradigm (e.g. object-oriented programming )
  • Definition of naming conventions : How are identifiers to be selected?
  • Application of design patterns
  • Use of compiler directives and switches
  • Structuring of the code (indentations, module / procedure size, GOTO prohibition): Where should spaces be located? How to Engage Maximum number of lines in a routine.
  • Typing (choice of type for a symbol or a variable)
  • Initializing variables
  • Access to variables of external objects / procedures
  • Design of function calls (parameter transfers, return values)
  • Standard components to be used as required, such as subroutines , APIs, etc.
  • Avoidance of redundancy and the widest possible reusability - through modularization
  • Independence of different program parts ( modularity )
  • Uniformity in solving similar problems, e.g. B. by standardized programming
  • Robustness through detailed error and exception handling
  • Extent and form of the documentation : per procedure, per line; Level of detail; coordinated with other documents

Source code formatting example

Important aspects of programming style, the arrangement of sub-program elements ( indentation ) which thus directly encloses also the positioning of syntax elements such as {}, [], (), BEGINor ENDinfluence, and the use of blank spaces and blank lines and the interleaving subordinate program elements.

In addition, the absence of comments in the source code is a sign of bad programming style. A programming person must always assume that their code must also be read and understood by others; comments are essential for this. Nowadays there are often fixed formats for comments, which, for example, explain the input and output parameters of a function or method individually. This means that they can be used by automatic documentation programs such as doxygen or javadoc in order to generate human-readable documentation fully automatically.

The naming conventions for symbols also play an important role in the evaluation of the programming style. The name of a symbol should sufficiently explain, or at least suggest, its function or use. Since there is sufficient memory space available for the code today, the space-saving use of abbreviations such as "dskmngr" that was customary in the past is no longer justified. A different spelling is often used for different types of symbols in order to be able to read from the symbol name whether it is a variable , a function , a class or a constant etc. (See also Hungarian notation ). In this context, the length and scope of symbols and the order in which they are declared are also important.

These aspects of the source text formatting primarily relate to optical readability, but also directly to the understandability of the program source text.

Style checkers such as Checkstyle can check most of the criteria for good programming style in relation to these elements. Beautifiers are able to ensure that these elements are kept in a good style by reformatting the source code.

Controversial items

The following elements of programming styles are controversial. For each element a comparison of the arguments of the respective supporters and opponents follows. If possible and generally accepted, a recommendation regarding the controversial element follows the discussion.

Line length

Often, limiting the length of lines is considered good programming style. One of the reasons for such a limitation (depending on the specified maximum line length) is that

  • shorter lines are generally easier to read than longer ones (especially easier than several long lines that are automatically broken only at word boundaries), see the multi-column sentence of newspapers
  • longer instructions can usually be semantically divided into individual parts / lines
  • Comparison tools like diff often work line by line and changes are easier to see
  • if restricted to the safe printable area (80 characters), semantically motivated line breaks and indentations are also retained in the printout

Against a limitation of the line length (i.e. for unabridged lines) speaks that

  • this requires manual labor either in programming or in setting up the IDE
  • Newer APIs in particular use long symbol names, which favors the creation of very long lines
  • When searching with grep, the occurrence - by default a single line without context lines - can show the complete statement

The consensus can be that even long lines should never contain more than one statement.

Indentation style

The indentation style is arguably the most controversial point of any programming style.

However, the following recommendations are generally recognized:

  • Definition within a project, sub-project, team or company. Example: "For our open source projects in C and C ++ we use the GNU coding standards, for Java basically the SUN code conventions and otherwise those according to Allman."
  • consistent implementation
  • No mix of different styles in one project

The question of the indentation depth for subordinate blocks and whether one should give preference to spaces or the tabulator is also much discussed . For example, the Code Convention for Java stipulates an indentation depth of four spaces, whereas the Code Convention for Linux stipulates an indentation depth of eight characters. The advantage of indenting with spaces is that the indentation is always retained regardless of the display options of the viewer or editor.

On the other hand, tab characters for indentation offer the advantage that every developer can determine the indentation depth displayed by configuring the tab spacing of his text editor. There is agreement, however, that the two variants should not be mixed. A mixture of tabs and spaces in the indentation leads to inconsistent indentation depths for elements on the same hierarchical level, which is rather detrimental to legibility.

Regulations

Some quality standards in the software environment ( IEC 61508 , CMMI , SPICE etc.) explicitly require the use of certain sets of rules for programming. For example, the MISRA-C programming standard is often prescribed in the automotive industry .

See also

literature

  • Joseph Bergin: Coding at the Lowest Level . Coding Patterns for Java Beginners. Ed .: Pace University. ( pace.edu [accessed February 19, 2010]).

Web links

Individual evidence

  1. ↑ Andreas Schwill, University of Paderborn: Programming styles in the beginning lessons
  2. ↑ Oracle Code Conventions for the Java TM Programming Language [1] (1999)
  3. ↑ Uwe Sauerland: Guidelines for programming style