Programming style: Difference between revisions

Revision as of 11:12, 19 December 2019

Latest revision as of 14:53, 6 August 2025

(31 intermediate revisions by 24 users not shown)

Line 1:

{{Short description|Manner of writing source code}}

{{multiple issues|

{{Essay-likeMore citations needed|date=OctoberJune 20082016}}

{{refimprove|date=June 2016}}

}}

'''Programming style''', also known as '''codecoding style''', isare athe setconventions of rules orand guidelinespatterns used whenin writing the [[source code]], forresulting in a consistent and readable [[computer programcodebase]]. ItThese isconventions often claimedencompass thataspects followingsuch aas particular[[Indentation style|indentation]], [[Naming convention (programming)|naming styleconventions]], will[[capitalization]], helpand [[programmerComment (computer programming)|comments]]s. readConsistent andprogramming understandstyle sourceis codegenerally conformingconsidered tobeneficial thefor style,[[code readability]] and help[[maintainability]], toparticularly avoidin introducingcollaborative errorsenvironments.

Maintaining a consistent style across a codebase can improve readability and ease of software maintenance. It allows developers to quickly understand code written by others and reduces the likelihood of errors during modifications. Adhering to standardized coding guidelines ensures that teams follow a uniform approach, making the codebase easier to manage and scale. Many organizations and [[Open source|open-source]] projects adopt specific coding standards to facilitate collaboration and reduce cognitive load.

A classic work on the subject was ''[[The Elements of Programming Style]]'', written in the 1970s, and illustrated with examples from the [[Fortran]] and [[PL/I]] languages prevalent at the time.

TheStyle programmingguidelines stylecan usedbe formalized in adocuments particularknown programas may'''coding beconventions''', derivedwhich fromdictate thespecific [[codingformatting conventions]]and ofnaming arules. companyThese orconventions othermay computingbe organization,prescribed asby wellofficial asstandards thefor preferencesa ofprogramming thelanguage authoror ofdeveloped theinternally code.within Programminga stylesteam areor oftenproject. designedFor for a specificexample, [[Python (programming language)|Python]]'s (or[[PEP language8]] family):is a widely recognized style consideredguide goodthat inoutlines best practices for writing Python code. In contrast, languages like [[C (programming language)|C]] source code may not be appropriate foror [[BASICJava (programming language)|BASICJava]] sourcemay code,have etc.industry However,standards some rulesthat are commonlyeither appliedformally documented or adhered to manyby languagesconvention.

== Automation ==

==Elements of good style==

Adherence to coding style can be enforced through automated tools, which format code according to predefined guidelines. These tools reduce the manual effort required to maintain style consistency, allowing programmers to focus on logic and functionality. For instance, tools such as <code>Black</code> for Python and <code>clang-format</code> for C++ automatically reformat code to comply with specified coding standards.

Good style is a subjective matter, and is difficult to define. However, there are several elements common to a large number of programming styles. The issues usually considered as part of programming style include the [[Layout_(computing)|layout]] of the source code, including [[Indentation (typesetting)|indentation]]; the use of [[Whitespace_character|white space]] around operators and keywords; the capitalization or otherwise of keywords and variable names; the style and spelling of user-defined identifiers, such as function, procedure and variable names; and the use and style of [[Comment (computer programming)|comments]].

== Style guidelines ==

==Code appearance==

Common elements of coding style include:

Programming styles commonly deal with the visual appearance of source code, with the goal of readability. Software has long been available that formats source code automatically, leaving coders to concentrate on naming, logic, and higher techniques. As a practical point, using a computer to format source code saves time, and it is possible to then enforce company-wide standards without [[Flaming (Internet)#Holy Wars|debates]].

* ''Indentation and [[whitespace character]] use'' – Ensures consistent block structures and improves readability.

* ''Naming conventions'' – Standardizes how [[Variable (computer science)|variables]], [[Function (computer programming)|functions]], and [[Class (computer programming)|classes]] are named, typically adhering to [[Camel case|camelCase]], [[snake case]], or [[Pascal (programming language)|Pascal]]Case, depending on the language.

* ''Capitalization'' – Dictates whether keywords and identifiers are capitalized or lowercase, in line with language syntax.

* ''Comment use'' – Provides context and explanations within code without affecting its execution.

=== Indentation ===

[[Indentation style]]s can assist a reader in various ways including: identifying control flow and blocks of code. In some programming languages, indentation is used to delimit[[off-side logicalrule|delimit blocks of code;]] correctand indentation in these casestherefore is more than anot matter of style. In other languages, indentationthat andignore [[Whitespace character|white space]] do not affect functionwhitespace, although logical and consistent indentation makescan codeaffect more readablereadability. Compare:

For example, formatted in a commonly used style:

<source lang="c">

<syntaxhighlight lang="c">

if (hours < 24 && minutes < 60 && seconds < 60) {

return true;

Line 25 ⟶ 29:

return false;

}

</syntaxhighlight>

</source>

Arguably, poorly formatted:

or

<source lang="c">

<!-- The code block below is mis-indented intentionally. Do not correct or fix it to use proper indentation. -->

if (hours < 24 && minutes < 60 && seconds < 60)

<syntaxhighlight lang="c">

{

return true;

}

else

{

return false;

}

</source>

with something like

<!-- Note that the following code block is intentionally mis-indented. Do not "fix" it to use correct indentation. -->

<source lang="c">

if ( hours < 24

&& minutes < 60

Line 49 ⟶ 43:

{return false

;}

</syntaxhighlight>

</source>

==== Notable indenting styles ====

The first two examples are probably much easier to read because they are indented in an established way (a "hanging paragraph" style). This indentation style is especially useful when dealing with multiple nested constructs.

===== ModuLiq =====

{{Further|ModuLiq}}

The '''ModuLiq''' Zero Indentation Style groups by empty line rather than indenting.

Example:

Note, however, that this example is the same as simply:

<sourcesyntaxhighlight lang="c">

return hours < 24 && minutes < 60 && seconds < 60;

</source>

====ModuLiq====

The ModuLiq Zero Indentation Style groups with [[carriage return|carriage returns]] rather than indentations. Compare all of the above to:

<source lang="c">

if (hours < 24 && minutes < 60 && seconds < 60)

return true;

Line 68 ⟶ 58:

else

return false;

</syntaxhighlight>

</source>

===== Lua =====

{{Further|Lua}}

[[Lua (programming language)|Lua]] does not use the traditional [[curly braces]] or [[parenthesis]]. if/else statements only require the expression be followed by <code>then</code>, and closing the if/else statement with <code>end</code>.

'''Lua''' does not use the traditional [[curly braces]] or [[parentheses]]; rather, the expression in a conditional statement must be followed by <code>then</code>, and the block must be closed with <code>end</code>.

<source lang="lua">

<syntaxhighlight lang="lua">

if hours < 24 and minutes < 60 and seconds < 60 then

return true

Line 78 ⟶ 69:

return false

end

</syntaxhighlight>

</source>

IndentationIndenting is optional in Lua. <code>and</code>, <code>or</code>, and <code>not</code> arefunction usedas in between true/falselogical statementsoperators.

They are true/false statements, as <source lang="lua">print(not true)</source> would mean false.

===== Python =====

{{Further|Python (programming language)}}

[[Python language|Python]] uses indentation to indicate control structures, so ''correct indentation'' is required. By doing this, the need for bracketing with [[curly braces]] (i.e. <code>{</code> and <code>}</code>) is eliminated. On the other hand, copying and pasting Python code can lead to problems, because the indentation level of the pasted code may not be the same as the indentation level of the current line. Such reformatting can be tedious to do by hand, but some [[text editor]]s and [[Integrated development environment|IDE]]s have features to do it automatically. There are also problems when Python code being rendered unusable when posted on a forum or web page that removes white space, though this problem can be avoided where it is possible to enclose code in white space-preserving tags such as "&lt;pre&gt; ... &lt;/pre&gt;" (for [[HTML]]), "[code]" ... "[/code]" (for [[bbcode]]), etc.

'''Python''' relies on the ''[[off-side rule]]'', using indenting to indicate and implement control structure, thus eliminating the need for bracketing (i.e., <code>{</code> and <code>}</code>). However, copying and pasting indented code can cause problems, because the indent level of the pasted code may not be the same as the indent level of the target line. Such reformatting by hand is tedious and error prone, but some [[text editor]]s and [[integrated development environment]]s (IDEs) have features to do it automatically. There are also problems when indented code is rendered unusable when posted on a forum or web page that removes whitespace, though this problem can be avoided where it is possible to enclose code in whitespace-preserving tags such as "&lt;pre&gt; ... &lt;/pre&gt;" (for [[HTML]]), "[code]" ... "[/code]" (for [[bbcode]]), etc.

<sourcesyntaxhighlight lang="python">

if hours < 24 and minutes < 60 and seconds < 60:

return True

else:

return False

</syntaxhighlight>

</source>

Notice that Python doesstarts nota useblock curly braces, butwith a regular colon (e.g. <code>else:</code>).

Many Python programmers tend to follow a commonly agreed style guide known as PEP8.<ref>{{cite web |url=https://www.python.org/dev/peps/pep-0008/ |title=PEP 0008 --: Style Guide for Python Code |publisher=python.org}}</ref> There are tools designed to automate PEP8 compliance.

===== Haskell =====

{{Further|Haskell}}

[[Haskell (programming language)|Haskell]] similarly has the [[off-side rule]], i.e. it has a two-dimension syntax where indentation is meaningful to define blocks (although, an alternate syntax uses curly braces and semicolons).

'''Haskell''', like Python, has the ''off-side rule''. It has a two-dimension syntax where indenting is meaningful to define blocks (although, an alternate syntax uses curly braces and semicolons).

Haskell is a declarative language, there are statements, but declarations within a Haskell script. Example:

<source lang="haskell">

Haskell is a declarative language, there are statements, but declarations within a Haskell script.

Example:

<syntaxhighlight lang="haskell">

let c_1 = 1

c_2 = 2

in

f x y = c_1 * x + c_2 * y

</syntaxhighlight>

</source>

may be written in one line as:

<sourcesyntaxhighlight lang="haskell">

let {c_1=1;c_2=2}
in f x y = c_1 * x + c_2 * y

</syntaxhighlight>

</source>

Haskell encourages the use of [[literate programming]], where extended text explains the genesis of the code. In literate Haskell scripts (named with the <code>lhs</code> extension), everything is a comment except blocks marked as code. The program can be written in [[LaTeX]], in such case the <code>code</code> environment marks what is code. Also, each active code paragraph can be marked by preceding and ending it with an empty line, and starting each line of code with a greater than sign and a space. Here an example using LaTeX markup:

Haskell encourage the use of [[literate programming]], where extended text explain the genesis of the code.

<syntaxhighlight lang="haskell">

In literate Haskell scripts (named with the <code>lhs</code> extension), everything is a comment except blocks marked as code.

The program can be written in [[LaTeX]], in such case the <code>code</code> environment marks what is code.

Also each active code paragraph can be marked by preceding and ending it with an empty line, and starting each line of code with a greater than sign and a space.

Here an example using LaTeX markup:

<source lang="haskell">

The function \verb+isValidDate+ test if date is valid

\begin{code}

Line 124 ⟶ 117:

\end{code}

observe that in this case the overloaded function is \verb+fromDate :: Date -> (Int,Int,Int)+.

</syntaxhighlight>

</source>

And an example using plain text:

<sourcesyntaxhighlight lang="haskell">

The function isValidDate test if date is valid

Line 136 ⟶ 129:

observe that in this case the overloaded function is fromDate :: Date -> (Int,Int,Int).

</syntaxhighlight>

</source>

=== Vertical alignment ===

Some programmers consider it valuable to align similar elements vertically (as tabular, in columns), citing that it can make typo-generated bugs more obvious.

For example, unaligned:

It is often helpful to align similar elements vertically, to make typo-generated bugs more obvious. Compare:

<source lang="php">

<syntaxhighlight lang="php">

$search = array('a', 'b', 'c', 'd', 'e');

$replacement = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0;

$anothervalue = 1;

$yetanothervalue = 2;

</syntaxhighlight>

</source>

with:

aligned:

<source lang="php">

<syntaxhighlight lang="php">

$search = array('a', 'b', 'c', 'd', 'e');

$replacement = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0;

$anothervalue = 1;

$yetanothervalue = 2;

</syntaxhighlight>

</source>

Unlike the unaligned code, the aligned code implies that the search and replace values are related since they have corresponding elements. As there is one more value for search than replacement, if this is a bug, it is more likely to be spotted via visual inspection.

The latter example makes two things intuitively clear that were not clear in the former:

* the search and replace terms are related and match up: they are not discrete variables;

* there is one more search term than there are replacement terms. If this is a bug, it is now more likely to be spotted.

However,Cited notedisadvantages that there are arguments ''against''of vertical alignment include:

* Dependencies across lines which leads to maintenance load. For example, if a long column value is added that requires a wider column, then all lines of the table must be modified (to maintain the tabular form) which is a larger change which leads to more effort to review and to understand the change at a later date

* '''Inter-line false dependencies'''; tabular formatting creates dependencies across lines. For example, if an identifier with a long name is added to a tabular layout, the column width may have to be increased to accommodate it. This forces a bigger change to the source code than necessary, and the essential change may be lost in the noise. This is detrimental to [[Revision control]] where inspecting differences between versions is essential.

* '''Brittleness''';: if a programmer does not neatlycorrectly format the table when making a change, maybe legitimately with the previous point in mind, the result becomesis a visual mess that deterioratesis withharder furtherto suchread changesthan unaligned code. Simple refactoring operations, such as search-and-replacerenaming, may alsocan break the formatting.

* '''Resistance to modification'''; tabular formatting requires moreMore effort to maintain. Thiswhich may put offdiscourage a programmer from making a beneficial change, such as adding, correcting or improving the name of an identifier, because itdoing willso messwould uprequire thesignificant formatting. effort

* Requirement to use a fixed-width fonts; not proportional fonts

* '''Reliance on mono-spaced font'''; tabular formatting assumes that the editor uses a fixed-width font. Many modern code editors support proportional fonts, and the programmer may prefer to use a proportional font for readability.

* '''Tool dependence'''; some of the effort of maintaining alignment can be alleviated by tools (e.g. a [[source code editor]] that supports [[elastic tabstop]]s), although that creates a reliance on such tools.

Maintaining alignment can be alleviated by a tool that provides support (i.e. for [[elastic tabstop]]s), although that creates a reliance on such tools.

For example, if a simple refactoring operation is performed on the code above, renaming variables "$replacement" to "$r" and "$anothervalue" to "$a", the resulting code will look like this:

As an example, simple refactoring operations to rename "$replacement" to "$r" and "$anothervalue" to "$a" results in:

<source lang="php">

<syntaxhighlight lang="php">

$search = array('a', 'b', 'c', 'd', 'e');

$r = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0;

$a = 1;

$yetanothervalue = 2;

</syntaxhighlight>

</source>

TheWith original sequentialunaligned formatting, willthese stillchanges lookdo finenot afterhave such changea dramatic, inconsistent or undesirable effect:

<sourcesyntaxhighlight lang="php">

$search = array('a', 'b', 'c', 'd', 'e');

$r = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0;

$a = 1;

$yetanothervalue = 2;

</syntaxhighlight>

</source>

===Spaces Whitespace ===

A [[free-format language]] ignores [[whitespace character]]s: spaces, tabs and new lines so the programmer is free to style the code in different ways without affecting the meaning of the code. Generally, the programmer uses style that is considered to enhance [[readability]].

In those situations where some [[Whitespace character|white space]] is required, the grammars of most [[free-format language]]s are unconcerned with the amount that appears. Style related to white space is commonly used to enhance [[readability]]. There are currently no known hard facts (conclusions from studies) about which of the whitespace styles have the best readability.

The two code snippets below are the same logically, but differ in whitespace.

For instance, compare the following syntactically equivalent examples of C code:

<sourcesyntaxhighlight lang="c">

int i;

for(i=0;i<10;++i){

printf("%d",i*i+i);

}

</syntaxhighlight>

</source>

versus

<sourcesyntaxhighlight lang="c">

int i;

for (i = 0; i < 10; ++i) {

printf("%d", i * i + i);

}

</syntaxhighlight>

</source>

The use of [[Tab key|tabs]] for whitespace is debatable. Alignment issues arise due to differing tab stops in different environments and mixed use of tabs and spaces.

===Tabs===

The use of [[Tab key|tabs]] to create white space presents particular issues when not enough care is taken because the ___location of the tabulation point can be different depending on the tools being used and even the preferences of the user.

As an example, one programmer prefers [[tab stop]]s of four and has their toolset configured this way, and uses these to format their code.

<sourcesyntaxhighlight lang="c">

int ix; // Index to scan array

long sum; // Accumulator for sum

</syntaxhighlight>

</source>

Another programmer prefers tab stops of eight, and their toolset is configured this way. When someone else examines the original person's code, they may well find it difficult to read.

<sourcesyntaxhighlight lang="c">

int ix; // Index to scan array

long sum; // Accumulator for sum

</syntaxhighlight>

</source>

One widely used solution to this issue may involve forbidding the use of tabs for alignment or rules on how tab stops must be set. Note that tabs work fine provided they are used consistently, restricted to logical indentation, and not used for alignment:

<sourcesyntaxhighlight lang="cpp">

class MyClass {

int foobar(

Line 249 ⟶ 236:

int quuux); // third parameter

};

</syntaxhighlight>

</source>

== See also ==

* {{Annotated link|MISRA C}}

* [[Coding conventions]]

* {{Annotated link|Naming convention (programming)}}

* [[MISRA C]]

* [[Naming convention (programming)]]

== References ==

{{Reflist}}

==External links==

*{{dmoz|/Computers/Programming/Development_Tools/Source_Code_Formatters/|Source Code Formatters}}

[[Category:Source code]]

[[Category:Programming language comparisons]]

<!-- Hidden categories below -->

[[Category:Articles with example C code]]

[[Category:Articles with example Haskell code]]

[[Category:Articles with example PHP code]]

[[Category:Articles with example Python (programming language) code]]

[[Category:Articles with example pseudocode]]