Coding conventions: Difference between revisions
GreenC bot (talk | contribs) Move 1 url. Wayback Medic 2.5 per WP:URLREQ#Network World |
|||
(34 intermediate revisions by 24 users not shown) | |||
Line 1: | Line 1: | ||
{{short description|Standards and guidelines for writing code}} |
{{short description|Standards and guidelines for writing code}} |
||
{{more footnotes needed|date=April 2021}} |
|||
{{Software development process}} |
{{Software development process}} |
||
'''Coding conventions''' are a set of guidelines for a specific [[programming language]] that recommend [[programming style]], practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, [[Indent style|indentation]], [[Comment (computer programming)|comments]], [[Declaration (computer science)|declarations]], [[statement (programming)|statements]], [[Whitespace (computer science)|white space]], [[Identifier naming convention|naming conventions]], [[Best Coding Practices|programming practices]], [[:Category:Programming principles|programming principles]], [[:Category:Programming rules of thumb|programming rules of thumb]], architectural best practices, etc. These are guidelines for [[Software quality model|software structural quality]]. [[programmer|Software programmers]] are highly recommended to follow these guidelines to help improve the [[readability]] of their [[source code]] and make [[software maintenance]] easier. Coding conventions are only applicable to the human maintainers and [[peer review]]ers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows<ref>{{Cite web|url=https://editorconfig.org/|title=EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs.|last=|first=|date=|website=EditorConfig|access-date=}}</ref> |
'''Coding conventions''' are a set of guidelines for a specific [[programming language]] that recommend [[programming style]], practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, [[Indent style|indentation]], [[Comment (computer programming)|comments]], [[Declaration (computer science)|declarations]], [[statement (programming)|statements]], [[Whitespace (computer science)|white space]], [[Identifier naming convention|naming conventions]], [[Best Coding Practices|programming practices]], [[:Category:Programming principles|programming principles]], [[:Category:Programming rules of thumb|programming rules of thumb]], architectural best practices, etc. These are guidelines for [[Software quality model|software structural quality]]. [[programmer|Software programmers]] are highly recommended to follow these guidelines to help improve the [[readability]] of their [[source code]] and make [[software maintenance]] easier. Coding conventions are only applicable to the human maintainers and [[peer review]]ers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows,<ref>{{Cite web|url=https://editorconfig.org/|title=EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs.|last=|first=|date=|website=EditorConfig|access-date=}}</ref> or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by [[compiler]]s. |
||
==Software maintenance== |
==Software maintenance== |
||
Reducing the cost of [[software maintenance]] is the most often cited reason for following coding conventions. In |
Reducing the cost of [[software maintenance]] is the most often cited reason for following coding conventions. In the introductory section on code conventions for the Java programming language, Sun Microsystems offers the following reasoning:<ref> |
||
{{cite web |
{{cite web |
||
| title = Code Conventions for the Java Programming Language : Why Have Code Conventions |
| title = Code Conventions for the Java Programming Language : Why Have Code Conventions |
||
Line 27: | Line 28: | ||
====Coding standards==== |
====Coding standards==== |
||
Where coding conventions have been specifically designed to produce high-quality code, and have then been formally adopted, they then become coding standards. Specific styles, irrespective of whether they are commonly adopted, do not automatically produce good quality code. |
Where coding conventions have been specifically designed to produce high-quality code, and have then been formally adopted, they then become coding standards. Specific styles, irrespective of whether they are commonly adopted, do not automatically produce good quality code. |
||
Just like pornhub.com click on this link and it will lead you to coding and designing stuff |
|||
====Reduction of complexity==== |
====Reduction of complexity==== |
||
Line 33: | Line 33: | ||
Complexity is a factor going against security.<ref> |
Complexity is a factor going against security.<ref> |
||
Tom Gillis. |
Tom Gillis. |
||
[https://www.networkworld.com/article/ |
[https://www.networkworld.com/article/953939/complexity-is-the-enemy-of-security.html "Complexity is the enemy of security"]. |
||
</ref> |
</ref> |
||
The management of complexity includes the following basic principle: minimize the amount of code written during the project development. This prevents unnecessary work which prevents unnecessary cost, both upfront and downstream. |
The management of complexity includes the following basic principle: minimize the amount of code written during the project development. This prevents unnecessary work which prevents unnecessary cost, both upfront and downstream. This is simply because if there is less code, it is less work not only to create the application, but also to maintain it. |
||
Complexity is managed both at the design stage |
Complexity is managed both at the design stage (how the project is architectured) and at the development stage (by having simpler code). If the coding is kept basic and simple then the complexity will be minimised. Very often this is keeping the coding as 'physical' as possible - coding in a manner that is very direct and not highly abstract. This produces optimal code that is easy to read and follow. Complexity can also be avoided simply by not using complicated tools for simple jobs. |
||
The more complex the code is the more likely it is to be buggy, the more difficult the bugs are to find and the more likely there are to be hidden bugs. |
The more complex the code is the more likely it is to be buggy, the more difficult the bugs are to find and the more likely there are to be hidden bugs. |
||
===Refactoring=== |
===Refactoring=== |
||
[[Refactoring]] refers to a software maintenance activity where [[source code]] is modified to improve readability or improve its structure. Software is often refactored to bring it into conformance with a team's stated coding standards after its initial release. Any change that does not alter the behavior of the software can be considered refactoring. Common refactoring activities are changing variable names, |
[[Refactoring]] refers to a software maintenance activity where [[source code]] is modified to improve readability or improve its structure. Software is often refactored to bring it into conformance with a team's stated coding standards after its initial release. Any change that does not alter the behavior of the software can be considered refactoring. Common refactoring activities are changing variable names, renaming methods, moving methods or whole classes and [[Extract Method|breaking large methods]] (or [[Function (programming)|function]]s) into smaller ones. |
||
[[agile software development|Agile software development methodologies]] plan for regular (or even continuous) refactoring making it an integral part of the team [[software development process]].<ref> |
[[agile software development|Agile software development methodologies]] plan for regular (or even continuous) refactoring making it an integral part of the team [[software development process]].<ref> |
||
Line 60: | Line 60: | ||
==Task automation== |
==Task automation== |
||
Coding conventions allow to have simple scripts or programs whose job is to process source code for some purpose other than compiling it into an executable. It is common practice to count the software size ([[Source lines of code]]) to track current project progress or establish a baseline for future [[Estimation in software engineering|project estimates]]. |
Coding conventions allow programmers to have simple scripts or programs whose job is to process source code for some purpose other than compiling it into an executable. It is common practice to count the software size ([[Source lines of code]]) to track current project progress or establish a baseline for future [[Estimation in software engineering|project estimates]]. |
||
Consistent coding standards can, in turn, make the measurements more consistent. Special [[Tag (metadata)|tag]]s within [[source code comment]]s are often used to process documentation, two notable examples are [[javadoc]] and [[doxygen]]. The tools specify the use of a set of tags, but their use within a project is determined by convention. |
Consistent coding standards can, in turn, make the measurements more consistent. Special [[Tag (metadata)|tag]]s within [[source code comment]]s are often used to process documentation, two notable examples are [[javadoc]] and [[doxygen]]. The tools specify the use of a set of tags, but their use within a project is determined by convention. |
||
Line 100: | Line 100: | ||
| url = http://www.linuxjournal.com/article/3882 }} |
| url = http://www.linuxjournal.com/article/3882 }} |
||
</ref> [[Tcl]], which uses a brace syntax similar to Perl or C/C++ to delimit functions, does not allow the following, which seems fairly reasonable to a C programmer: |
</ref> [[Tcl]], which uses a brace syntax similar to Perl or C/C++ to delimit functions, does not allow the following, which seems fairly reasonable to a C programmer: |
||
< |
<syntaxhighlight lang="tcl"> |
||
set i = 0 |
set i = 0 |
||
while {$i < 10} |
while {$i < 10} |
||
Line 107: | Line 107: | ||
incr i |
incr i |
||
} |
} |
||
</ |
</syntaxhighlight> |
||
The reason is that in Tcl, curly braces are not used only to delimit functions as in C or Java. More |
The reason is that in Tcl, curly braces are not used only to delimit functions as in C or Java. More |
||
generally, curly braces are used to group words together into a single argument.<ref> |
generally, curly braces are used to group words together into a single argument.<ref> |
||
Line 127: | Line 127: | ||
==Common conventions== |
==Common conventions== |
||
There are a large number of coding conventions; see ''[[b:Computer Programming/Coding Style|Coding Style]]'' for numerous examples and discussion. Common coding conventions may cover the following areas: |
There are a large number of coding conventions; see ''[[b:Computer Programming/Coding Style|Coding Style]]'' for numerous examples and discussion. Common coding conventions may cover the following areas:<!-- Please A-Z --> |
||
* [[Comment (computer programming)|Comment]] conventions |
* [[Comment (computer programming)|Comment]] conventions |
||
Line 139: | Line 139: | ||
Coding standards include the [[CERT C Coding Standard]], [[MISRA C]], [[High Integrity C++]]. |
Coding standards include the [[CERT C Coding Standard]], [[MISRA C]], [[High Integrity C++]]. |
||
==See also== |
==See also==<!-- Please A-Z --> |
||
*[[Comparison of programming languages (syntax)]] |
*[[Comparison of programming languages (syntax)]] |
||
*[[Hungarian Notation]] |
*[[Hungarian Notation]] |
||
*[[Indent style]] |
*[[Indent style]] |
||
*[[List of tools for static code analysis]] |
*[[List of tools for static code analysis]] |
||
*[[List of software development philosophies]] |
|||
*[[Motor Industry Software Reliability Association|MISRA]] |
|||
*[[Programming style]] |
*[[Programming style]] |
||
*[[Software metrics]] |
*[[Software metrics]] |
||
*[[Software quality]] |
|||
*[[The Power of 10: Rules for Developing Safety-Critical Code|The Power of 10 Rules]] |
|||
==References== |
==References== |
||
<references /> |
|||
{{reflist}} |
|||
==External links== |
|||
{{wikibooks|Ada Style Guide}} |
|||
{{wikibooks|Computer Programming/Coding Style}} |
|||
===Coding conventions for languages=== |
|||
*ActionScript: [https://web.archive.org/web/20120306040014/http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions Flex SDK coding conventions and best practices] |
|||
*Ada: [http://www.adaic.com/docs/95style/html/cover.html Ada 95 Quality and Style Guide: Guidelines for Professional Programmers] |
|||
*Ada: [https://www.researchgate.net/publication/234821111_Guidance_for_the_use_of_the_Ada_programming_language_in_high_integrity_systems Guide for the use of the Ada programming language in high integrity systems] (ISO/IEC TR 15942:2000) |
|||
*Ada: [https://web.archive.org/web/20100527142102/http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf NASA Flight Software Branch — Ada Coding Standard] |
|||
*Ada: [https://www.coursehero.com/file/43745886/bssc983pdf/ ESA Ada Coding Standard - BSSC(98)3 Issue 1 October 1998] |
|||
*Ada: [http://www.esa.int/TEC/Software_engineering_and_standardisation/TECRFBUXBQE_2.html European Space Agency's Software engineering and standardisation] |
|||
*C: [[CERT C Coding Standard]] [https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard CERT C Coding Standard] (SEI) |
|||
*C: [http://barrgroup.com/coding-standard Embedded C Coding Standard] (Barr Group) |
|||
*C: [http://www.ganssle.com/fsm.pdf Firmware Development Standard] (Jack Ganssle) |
|||
*C++: [http://www.state-machine.com/doc/AN_QL_Coding_Standard.pdf Quantum Leaps C/C++ Coding Standard] |
|||
*C++: [[b:C++ Programming/Programming Languages/C++/Code/Style Conventions|C++ Programming/Programming Languages/C++/Code/Style Conventions]] |
|||
*C++: [http://geosoft.no/development/cppstyle.html GeoSoft's C++ Programming Style Guidelines] |
|||
*C++: [https://google.github.io/styleguide/cppguide.html Google's C++ Style Guide] |
|||
*C++: [[High Integrity C++]] |
|||
*C#: [https://msdn.microsoft.com/en-us/library/ff926074.aspx C# Coding Conventions (C# Programming Guide)] |
|||
*C#: [http://msdn.microsoft.com/en-us/library/ms229042(VS.80).aspx Design Guidelines for Developing Class Libraries] |
|||
*C#: [http://blogs.msdn.com/brada/articles/361363.aspx Brad Abrams] |
|||
*C#: [http://www.tiobe.com/standards/gemrcsharpcs.pdf Philips Healthcare] |
|||
*D: [http://www.digitalmars.com/d/1.0/dstyle.html The D Style] |
|||
*Dart: [https://www.dartlang.org/articles/style-guide The Dart Style Guide] |
|||
*Erlang: [http://www.erlang.se/doc/programming_rules.shtml Erlang Programming Rules and Conventions] |
|||
*Flex: [http://sourceforge.net/adobe/flexsdk/wiki/Coding%20Conventions/ Code conventions for the Flex SDK] |
|||
*Java: [http://www.ambysoft.com/essays/javaCodingStandards.html Ambysoft's Coding Standards for Java] |
|||
*Java: [http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html Code Conventions for the Java Programming Language] (Not actively maintained. Latest version: 1999-APR-20.) |
|||
*Java: [http://geosoft.no/development/javastyle.html GeoSoft's Java Programming Style Guidelines] |
|||
*Java: {{dmoz|Computers/Programming/Languages/Java/Coding_Standards/|Java Coding Standards}} |
|||
*Java: [http://tech.dolhub.com/article/computer/Coding-Conventions SoftwareMonkey's coding conventions for Java and other brace-syntax languages] |
|||
*JavaScript: [http://javascript.crockford.com/code.html Code Conventions for the JavaScript Programming Language] |
|||
*Lisp: [http://mumble.net/~campbell/scheme/style.txt Riastradh's Lisp Style Rules] |
|||
*MATLAB: [http://computersandbuildings.com/matlab-coding-conventions/ Neurobat Coding Conventions for MATLAB] |
|||
*Object Pascal: [http://edn.embarcadero.com/article/10280 Object Pascal Style Guide] |
|||
*Perl: [http://perldoc.perl.org/perlstyle.html Perl Style Guide] |
|||
*PHP::PEAR: [http://pear.php.net/manual/en/standards.php PHP::PEAR Coding Standards] |
|||
*PHP::FIG: [http://www.php-fig.org/ PHP Framework Interop Group] |
|||
*Python: [https://www.python.org/peps/pep-0008.html Style Guide for Python Code] |
|||
*Ruby: [http://www.caliban.org/ruby/rubyguide.shtml The Unofficial Ruby Usage Guide] |
|||
*Ruby: [https://github.com/styleguide/ruby GitHub Ruby style guide] |
|||
*Shell: [https://google.github.io/styleguide/shell.xml Google's Shell Style Guide] |
|||
===Coding conventions for projects=== |
|||
*[http://httpd.apache.org/dev/styleguide.html Apache Developers' C Language Style Guide] |
|||
*[http://drupal.org/coding-standards Drupal PHP Coding Standards] |
|||
*[http://framework.zend.com/manual/1.12/en/coding-standard.html Zend Framework Coding Standards] |
|||
*[[GNU Coding Standards]] |
|||
*[https://code.google.com/p/google-styleguide/ Style guides for Google-originated open-source projects] |
|||
*[https://web.archive.org/web/20011025142432/http://lxr.linux.no/source/Documentation/CodingStyle Linux Kernel Coding Style] (or Documentation/CodingStyle in the Linux Kernel source tree) |
|||
*[https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style Mozilla Coding Style Guide] |
|||
*[http://www.qhull.org/road/road-faq/xml/cpp-guideline.xml Road Intranet's C++ Guidelines] |
|||
*[ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/style The NetBSD source code style guide] (formerly known as the BSD Kernel Normal Form) |
|||
*[http://man.openbsd.org/style.9 OpenBSD Kernel source file style guide (KNF)] |
|||
*{{cite web |
|||
| title = GNAT Coding Style: A Guide for GNAT Developers |
|||
| work = GCC online documentation |
|||
| publisher = Free Software Foundation |
|||
| url = https://gcc.gnu.org/onlinedocs/gnat-style/ |
|||
| accessdate = 2009-01-19 |
|||
}} ([https://gcc.gnu.org/onlinedocs/gnat-style.pdf PDF]) |
|||
*[http://rfc.zeromq.org/spec:21 ZeroMQ C Language Style for Scalability (CLASS)] |
|||
*Mono: [http://www.mono-project.com/Coding_Guidelines Programming style for Mono] |
|||
[[Category:Source code]] |
[[Category:Source code]] |
||
[[Category:Software engineering]] |
Latest revision as of 19:54, 26 April 2024
This article includes a list of general references, but it lacks sufficient corresponding inline citations. (April 2021) |
Part of a series on |
Software development |
---|
Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows,[1] or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers.
Software maintenance
[edit]Reducing the cost of software maintenance is the most often cited reason for following coding conventions. In the introductory section on code conventions for the Java programming language, Sun Microsystems offers the following reasoning:[2]
Code conventions are important to programmers for a number of reasons:
- 40%–80% of the lifetime cost of a piece of software goes to maintenance.[3]
- Hardly any software is maintained for its whole life by the original author.
- Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
- If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.
Quality
[edit]Software peer review frequently involves reading source code. This type of peer review is primarily a defect detection activity. By definition, only the original author of a piece of code has read the source file before the code is submitted for review. Code that is written using consistent guidelines is easier for other reviewers to understand and assimilate, improving the efficacy of the defect detection process.
Even for the original author, consistently coded software eases maintainability. There is no guarantee that an individual will remember the precise rationale for why a particular piece of code was written in a certain way long after the code was originally written. Coding conventions can help. Consistent use of whitespace improves readability and reduces the time it takes to understand the software.
Coding standards
[edit]Where coding conventions have been specifically designed to produce high-quality code, and have then been formally adopted, they then become coding standards. Specific styles, irrespective of whether they are commonly adopted, do not automatically produce good quality code.
Reduction of complexity
[edit]Complexity is a factor going against security.[4]
The management of complexity includes the following basic principle: minimize the amount of code written during the project development. This prevents unnecessary work which prevents unnecessary cost, both upfront and downstream. This is simply because if there is less code, it is less work not only to create the application, but also to maintain it.
Complexity is managed both at the design stage (how the project is architectured) and at the development stage (by having simpler code). If the coding is kept basic and simple then the complexity will be minimised. Very often this is keeping the coding as 'physical' as possible - coding in a manner that is very direct and not highly abstract. This produces optimal code that is easy to read and follow. Complexity can also be avoided simply by not using complicated tools for simple jobs.
The more complex the code is the more likely it is to be buggy, the more difficult the bugs are to find and the more likely there are to be hidden bugs.
Refactoring
[edit]Refactoring refers to a software maintenance activity where source code is modified to improve readability or improve its structure. Software is often refactored to bring it into conformance with a team's stated coding standards after its initial release. Any change that does not alter the behavior of the software can be considered refactoring. Common refactoring activities are changing variable names, renaming methods, moving methods or whole classes and breaking large methods (or functions) into smaller ones.
Agile software development methodologies plan for regular (or even continuous) refactoring making it an integral part of the team software development process.[5]
Task automation
[edit]Coding conventions allow programmers to have simple scripts or programs whose job is to process source code for some purpose other than compiling it into an executable. It is common practice to count the software size (Source lines of code) to track current project progress or establish a baseline for future project estimates.
Consistent coding standards can, in turn, make the measurements more consistent. Special tags within source code comments are often used to process documentation, two notable examples are javadoc and doxygen. The tools specify the use of a set of tags, but their use within a project is determined by convention.
Coding conventions simplify writing new software whose job is to process existing software. Use of static code analysis has grown consistently since the 1950s. Some of the growth of this class of development tools stems from increased maturity and sophistication of the practitioners themselves (and the modern focus on safety and security), but also from the nature of the languages themselves.
Language factors
[edit]All software practitioners must grapple with the problem of organizing and managing a large number of sometimes complex instructions. For all but the smallest software projects, source code (instructions) are partitioned into separate files and frequently among many directories. It was natural for programmers to collect closely related functions (behaviors) in the same file and to collect related files into directories. As software development shifted from purely procedural programming (such as found in FORTRAN) towards more object-oriented constructs (such as found in C++), it became the practice to write the code for a single (public) class in a single file (the 'one class per file' convention).[6][7] Java has gone one step further - the Java compiler returns an error if it finds more than one public class per file.
A convention in one language may be a requirement in another. Language conventions also affect individual source files. Each compiler (or interpreter) used to process source code is unique. The rules a compiler applies to the source creates implicit standards. For example, Python code is much more consistently indented than, say Perl, because whitespace (indentation) is actually significant to the interpreter. Python does not use the brace syntax Perl uses to delimit functions. Changes in indentation serve as the delimiters.[8][9] Tcl, which uses a brace syntax similar to Perl or C/C++ to delimit functions, does not allow the following, which seems fairly reasonable to a C programmer:
set i = 0
while {$i < 10}
{
puts "$i squared = [expr $i*$i]"
incr i
}
The reason is that in Tcl, curly braces are not used only to delimit functions as in C or Java. More generally, curly braces are used to group words together into a single argument.[10][11] In Tcl, the word while takes two arguments, a condition and an action. In the example above, while is missing its second argument, its action (because the Tcl also uses the newline character to delimit the end of a command).
Common conventions
[edit]There are a large number of coding conventions; see Coding Style for numerous examples and discussion. Common coding conventions may cover the following areas:
- Comment conventions
- Indent style conventions
- Line length conventions
- Naming conventions
- Programming practices
- Programming principles
- Programming style conventions
Coding standards include the CERT C Coding Standard, MISRA C, High Integrity C++.
See also
[edit]- Comparison of programming languages (syntax)
- Hungarian Notation
- Indent style
- List of tools for static code analysis
- List of software development philosophies
- MISRA
- Programming style
- Software metrics
- Software quality
- The Power of 10 Rules
References
[edit]- ^ "EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs". EditorConfig.
- ^ "Code Conventions for the Java Programming Language : Why Have Code Conventions". Sun Microsystems, Inc. 1999-04-20.
- ^ Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
- ^ Tom Gillis. "Complexity is the enemy of security".
- ^ Jeffries, Ron (2001-11-08). "What is Extreme Programming? : Design Improvement". XP Magazine. Archived from the original on 2006-12-15.
- ^ Hoff, Todd (2007-01-09). "C++ Coding Standard : Naming Class Files".
- ^ FIFE coding standards
- ^ van Rossum, Guido (2006-09-19). Fred L. Drake, Jr (ed.). "Python Tutorial : First Steps Towards Programming". Python Software Foundation. Archived from the original on 2008-09-28. Retrieved 2014-08-17.
- ^ Raymond, Eric (2000-05-01). "Why Python?". Linux Journal.
- ^ Tcl Developer Xchange. "Summary of Tcl language syntax". ActiveState.
- ^ Staplin, George Peter (2006-07-16). "Why can I not start a new line before a brace group". 'the Tcler's Wiki'.