I find it odd that this article does not discuss mixing tabs and spaces. --146.211.0.10 (talk) 14:19, 17 December 2013 (UTC)
Following this text that appears in page:
> The GNU Emacs text editor and the GNU systems' indent command will reformat code according to this style by default.[dubious – discuss]
On Ubuntu 18.04, I tested indent (which is version 2.2.11). I copied the source code from section https://en.wikipedia.org/wiki/Talk:Indentation_style/Indentation_style#GNU_style to a file and removed every whitespace (including newline) except between "static" and "char". It yields this string:
static char*concat(char*s1,char*s2){while(x==y){something();somethingelse();}finalthing();}
then I called indent on it.
indent sr.c
It produced exactly the original source code (md5 is 8faf982bf7fa49f7579b115e7fd8090e).
At the very least, indent exactly conforms to the style shown in the page, on this example, including whitespace.
Stephane.gourichon (talk) 08:01, 3 July 2019 (UTC)
Anyway, do you agree with the statement that emacs indents with two spaces? Last time I tried emacs 23.3.1 it used by default tabs instead of 8 spaces, while still indenting with two spaces at the beginning (first three indent levels). --146.211.0.10 (talk) 14:19, 17 December 2013 (UTC)
> The GNU Emacs text editor and the GNU systems' indent command will reformat code according to this style by default.[dubious – discuss]
On Ubuntu 18.04, I tested GNU Emacs (which is version 25.2.2). I copied the source code from section https://en.wikipedia.org/wiki/Talk:Indentation_style/Indentation_style#GNU_style to a file and removed every whitespace at a beginning of line (keeping newlines). Then I selected the whole file and did M-x indent-region and saved the file. It produced exactly the original source code (md5 is 8faf982bf7fa49f7579b115e7fd8090e).
So, I think the "dubious" part can be removed.
Stephane.gourichon (talk) 08:01, 3 July 2019 (UTC)
I came to this page because I am updating some code code I first published to comp.sources.unix 26 years ago, and I needed to decide on how to best modernize my indentation. This entire article is impressive even though it is not perfect. Best for this comment to remain anonymous. — Preceding unsigned comment added by 198.0.155.131 (talk • contribs) 14:30, 28 March 2014 (UTC)
I think the Kernel example should be modified to not include an else branch with the preceding if branch unconditionally returning. This pattern is actively avoided in the kernel sources. It has been mentioned quite a few times over the years on lkml. — Preceding unsigned comment added by 62.116.255.28 (talk) 11:59, 9 April 2014 (UTC)
I noticed that all coding styles mentioned on this page that do not involve a new line for the curly brace do this if(example) { But why no mention of something like this? if(example){ Should this article cover that coding style? — Preceding unsigned comment added by Sonic12228 (talk • contribs) 03:41, 4 August 2014 (UTC)
From the article, it appears that the Linux kernel is written in Kernel style, but the OTBS variant of K&R says that it's written in that style. Are they really the same? Only the OTBS section has citations.
In fact, the 1TBS section seems almost entirely inaccurate. It claims that:
The source code of both the Unix[4] and Linux[5] kernels is written in this style. The main difference from the K&R style is that the braces are not omitted for a control statement with only a single statement in its scope.
However, K&R, Unix and Linux all omit braces around single-statement blocks in many cases, and Linux even puts this in their style guide (https://www.kernel.org/doc/Documentation/CodingStyle): "Do not unnecessarily use braces where a single statement will do." So, the "phrase braces are not omitted for a control statement with only a single statement in its scope" certainly does not apply. — Preceding unsigned comment added by Trombonehero (talk • contribs) 17:45, 16 June 2015 (UTC)
Wikipedia needs the publication date for sources. It is not unusual to have copyright dates that precede publication by several years, hence they are not useful. TEDickey (talk) 21:49, 6 February 2015 (UTC)
The current link points to a modified version of the cstyle script, as seen in the history. It would be nice also to confirm that the "original" script was provided by Sun as part of OpenSolaris (some comments which I have read indicate this was not the case). TEDickey (talk) 22:01, 6 February 2015 (UTC)
Sat Aug 21 20:56:37 2010 joerg
* /home/joerg/cmd/cstyle/cstyle 1.9 Aufruestung auf Sun cstyle-1.8 6538468 add Mercurial support to ON developer tools 6658967 /etc/publickey entries get removed on upgrade Portions of 6538468 contributed by Rich Lowe. Portions of 6538468 contributed by Mike Gerdts.
Sat Aug 21 20:53:58 2010 joerg
* /home/joerg/cmd/cstyle/cstyle 1.8 Aufruestung auf Sun cstyle-1.7 6251095 cstyle should optionally accommodate splint comments 6251101 cstyle should optionally accommodate doxygen style comment blocks 6315797 cstyle should not think space after cast for __NORETURN in .c files 6333761 codereviews should include delta comment
Wed Jul 27 15:29:25 2005 joerg
* /home/joerg/cmd/cstyle/cstyle 1.7 Aufruestung auf Sun cstyle-1.6 6288411 New cstyle -c does not allow no-argument, non-statement macros
Mon Jul 25 13:18:48 2005 joerg
* /home/joerg/cmd/cstyle/cstyle 1.6 Aufruestung auf Sun cstyle-1.4
Sat Jun 11 14:10:55 2005 joerg
* /home/joerg/cmd/cstyle/cstyle 1.5 [-B] file neu
Sat Jun 11 14:09:40 2005 joerg
* /home/joerg/cmd/cstyle/cstyle 1.4 Neue Option -B Boxcomment /*------------
Thu Jun 9 12:26:06 2005 joerg
* /home/joerg/cmd/cstyle/cstyle 1.3 Aufruestung auf Sun cstyle-1.2
Sun Feb 29 21:46:32 2004 joerg
* /home/joerg/cmd/cstyle/cstyle 1.2 Neue Optionen -l -b -K
Fri Aug 3 15:21:26 2001 joerg
* /home/joerg/cmd/cstyle/cstyle 1.1 date and time created 01/08/03 15:21:26 by joerg
Schily (talk) 13:43, 9 February 2015 (UTC)
I just removed the mentioned section, which shows all signs of being original research.
A Google search for the section name shows many pages. Some of them mention the style without providing any reference. However, the ones that do provide a reference are only referencing this Wikipedia page.
Searching through the page history shows that the section was added on 2011-03-21 with no edit summary. It was then removed on 2013-10-26 with the summary “Removed "Caompact Control Style" because its equivalent to Stroustoup's variation of K&R.”, then added back on 2015-01-21 with the summary “CCR is not the same as the Stroustrup K&R variant. There are no spaces before or after the parentheses of control structures.” All these edits have been done anonymously.
According to that last edit summary, the only reason to consider CCR a distinct style is the lack of some spaces, yet this point is not discussed in the article itself. It is also worth noting that the CCR style did have the mentioned spaces in its version from 2011 to 2013, and even in the version that was added back in 2015. But one minute after reintroducing CCR, the same editor removed those spaces. Thus it appears that the argument used to reintroduce the style in the article has been fabricated by the editor doing the reintroduction.
I did a Google search for "Compact control readability style", asking for results older than its first appearance here (2011-03-21). There was only one result: a Wikipedia user page. From that page's history, it appears that the style was first mentioned there on 2015-06-08.
All this evidence suggests that the name "Compact control readability style" has been expressly created for Wikipedia, or at least that it had no notability until Wikipedia gave it some.
— Edgar.bonet (talk) 11:04, 2 July 2015 (UTC)
The first example in the K&R section (https://en.wikipedia.org/wiki/Talk:Indentation_style/Indent_style#K.26R_style) shows the implementation of function main() as such:
int main(int argc, char *argv[]){ ...}
Where would the following style fall under?
int main(int argc, char *argv[]) { ...}
Originally, looking at the first example on the page, with the while statment, I thought the second snippet of code would be K&R style. — Preceding unsigned comment added by 159.153.136.74 (talk) 23:10, 5 November 2015 (UTC)
Hello fellow Wikipedians,
I have just added archive links to 2 external links on Indent style. Please take a moment to review my edit. If necessary, add {{cbignore}}
after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}}
to keep me off the page altogether. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}}
(last update: 5 June 2024).
Cheers.—cyberbot IITalk to my owner:Online 05:29, 28 February 2016 (UTC)
At the end of the section on Stroustrup style, it says that he currently encourages a more Allman-style approach, with a reference to the contributing page of the C++ Core Guidelines. I am having trouble finding any evidence of this.
The referenced page only contains examples of function definitions, which are the same in K&R and Allman. In fact the C++ Core Guidelines specifically suggest using a K&R-based layout.[2]
Jibsendk (talk) 21:48, 2 April 2016 (UTC)
Under "placement of braces", K&R and variants are said to follow the
while (x == y) { ... }
format
And that Allmans follows the
while (x == y) { ... }
format.
However, under the "K&R Style" under styles, K&R is described as:
This suggests that K&R is the same as Allmans, which is not true if the above is correct. The code example below this quote seems to support said hypothesis.
So, which is K&R, which is Allmans? Is Allmans a variant of K&R? If so, why is K&R generally described as having the braces on a separate line, with a variant having it on the same line?
Confusion everywhere. — Preceding unsigned comment added by 78.108.46.137 (talk) 20:54, 13 December 2016 (UTC)
"Some programmers such as Jamie Zawinski[1] feel that spaces instead of tabs increase cross-platform functionality. Others, such as the writers of the WordPress coding standards,[2] believe the opposite, that hard tabs increase cross-platform functionality."
These two sentences are at the end of the Tabs, Spaces section. Both cannot be right; one of those "increase"s should be a "decrease".
Pls2000 (talk) 08:48, 22 February 2017 (UTC)
"When following K&R, each function has its opening brace at the next line on the same indent level as its header"
Isn't this Allman style?207.141.13.226 (talk) 21:19, 29 March 2017 (UTC)
The tagged comment is an editor's opinion that a given style was used, rather than a reliable source providing that opinion. TEDickey (talk) 00:59, 12 January 2018 (UTC)
The only source cited for 1TBS is the Jargon file entry, which makes no mention of it being a variation of K&R, and in fact says it is a just another name for K&R. This seems to be the case in general for older sources - in older usage, "One True Brace Style" was a nickname for K&R - not K&R plus extra rules about how to handle one-line conditionals.
All of the pages I can find that talk about 1TBS as a specific variant, actually point to this wikipedia article. So citing them here just would be circular.
Where, then, did the distinction actually come from?
Jeffrobertson1975 (talk) 17:47, 1 June 2018 (UTC)
MarcelB612 (talk) 05:33, 28 August 2024 (UTC)Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are **right** and (b) K&R are right. Besides, functions are special anyway (you can't nest them in C).[1]
References
An article on style using the "goto" statement. This should be avoided at all costs.
Also the examples' lines are too long causing wrapping even on a widescreen monitor so making it hard to see the format. 194.207.86.26 (talk) 07:25, 10 May 2019 (UTC)
goto ErrorHandlingForThisSituation
LoopOfExceptionsToIgnore:
which is a red flag.How about including a statement about Yet Another Markup Language (YAML), which uses indentation to indicate hierarchy in a data structure? --Ancheta Wis (talk | contribs) 10:31, 12 May 2019 (UTC)
I would like to see this style in the article, but I have no citations, so I'll just leave it here for now
// Python stylewhile (x == y) { something(); somethingelse(); }
- Bevo (talk) 12:48, 2 June 2019 (UTC)
Currently, the name of this article is "Indentation style". To my opinion, this is just misleading, because:
{...}
) that often follows a control statement (if
, while
, for
...).GnuStyleFunction ()
vs. AllmanStyleFunction()
.So, the name "Programming style" or something like "Brace placement" will be better. However, the "Programming style" article already exists. — Preceding unsigned comment added by 178.66.136.200 (talk) 09:46, July 14, 2019 (UTC)
They are described as slightly different, but instead of pointing out these differences, the article point to the similarities. So, what their differences are? — Preceding unsigned comment added by 92.100.48.61 (talk) 21:58, 22 July 2019 (UTC)
As a programmer, I have wasted countless hours arguing over indentation style. Everyone seems to believe there should be coding indentation standards, but no one agrees on what exactly they should be. Invariably, every place I have ever worked, the "blessed" indentation style has been some standard, but with some custom modifications that defy the use of automated indentation tools. This seems like a negative impact to productivity, not a positive one. I can read any code, and I can write in any style, but really I just want someone to hand me a tool that is properly tweaked to produce the style that they want to see, so we can stop arguing about it and get on to doing the actual work of writing code. In all this time, I have *NEVER* seen anyone produce any *ACTUAL*STUDIES* that show any performance improvements of one style over any other style, or even for having a "blessed" style at all. Has anyone ever seen any kind of scientific study that shows the benefits of having a specified indentation style in the workplace? Has anyone ever seen any kind of scientific study that attempts to quantify performance metrics among various indentation styles? 47.35.58.40 (talk) 18:18, 17 October 2019 (UTC)
clang-format
) or unconfigurable (black
) style. Black's description makes the case for its use:By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from
pycodestyle
nagging about formatting. You will save time and mental energy for more important matters.
Blackened code looks the same regardless of the project you're reading. Formatting becomes transparent after a while and you can focus on the content instead.
Black makes code review faster by producing the smallest diffs possible.
— Black · PyPi
The Haskell example on in the "Brace placement in compound statements" section is very misleading: it does not use idiomatic Haskell formatting, and it's so far from valid Haskell code that it seems meaningless as an example.
First, Haskell does not have a while
statement or any other built-in syntax for looping. There is really no straightforward transliteration of the example code into valid Haskell. An actually semantically-valid transliteration might look something like this:
loop x y = when (x == y) $ do something somethingelse loop x y
But this is also misleading, because something
and somethingelse
will not be able to modify x
and y
in any way. The entire idea of a looping control flow is expressed in a fundamentally different way in purely-functional languages.
More subtly, but very importantly, the example given in the "Brace placement in compound statements" section uses a different style than the actual Haskell code examples in the "Haskell style" section. Specifically, the "Brace placements in compound statements" example involves a trailing semicolon that is not idiomatic in Haskell, as evidenced by the "Haskell style" examples.
It is also very unidiomatic in Haskell code to use this "Haskell style" to separate statements. Within idiomatic Haskell, the "Haskell style" of brace-and-semicolon placement is used almost exclusively for separating the fields of a data type. This makes the "Brace placement in compound statements" category especially misleading for this example, because this style is usually specifically not used in the context of compound statements.
Unless someone plans a whole-article rewrite to differentiate the "brace styles" of compound statements from other sorts of "brace styles" in programming, I would advocate for simply removing all of the Haskell (and pseudo-Haskell) examples from this page, as they are simply irrelevant to compound statements in C-like languages. I think it's likely to confuse users of C-like languages as well as users of Haskell-like languages. Kcsmnt0 (talk) 02:22, 18 January 2023 (UTC)
This article goes beyond indentation style. The example styles cover more than indentation. They about the more general concept of coding style.
My guess is that the article has been edited a zillion times and its scope has increased over the years. I see it all the time in WP. It's not wrong per se, but IMO it's not good. If every article talks about everything then what's the point of organizing by articles?
I propose to move information from this articles that it outside the concept of indentation style to another article. In particular, this extra info probably fits in the scope of programming style (which is aka coding style). So, I propose moving this extra info there; leaving only info directly related to indentation style (which is an aspect of programming style). Stevebroshar (talk) 12:42, 22 March 2024 (UTC)
Notably the introduction of this article states:
This article focuses on curly-bracket languages (that delimit blocks with curly brackets, a.k.a. curly braces, a.k.a. braces) and in particular C-family languages
Why is Python, a notably non-curly bracketed language, being added to the "Notable Styles" section article? AFAIK this article is supposed to be focued on how C-style languages are typically indented, would it be appropriate to change the "Lisp style" section to just feature Lisp code? Or the now removed "Haskell style" to just feature Haskell code? — Preceding unsigned comment added by 184.22.157.104 (talk) 11:59, 12 September 2024 (UTC)