Talk:Indentation style

message: 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)
thread_title:  Tabs and spaces 

message: 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.
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/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)
thread_title:  GNU indent 

message: 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)
replies: text: I added a mention of Emacs's ability to indent using tabs followed by spaces, resulting the the minimal number of indentation characters. — Loadmaster (talk) 18:09, 17 December 2013 (UTC)

text: Emacs "default" behavior may well be adjusted by your distribution vendor and personal files in emacs.d. IMHO one should test with --no-init-file.
=== Removing "dubious" after fact-checking ===
> The GNU Emacs text editor and the GNU systems' indent command will reformat code according to this style by default.
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/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)
thread_title:  How GNU Emacs indents by default 

message: > The GNU Emacs text editor and the GNU systems' indent command will reformat code according to this style by default.
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/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)
thread_title:  Removing "dubious" after fact-checking 

message: 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)
thread_title: Praise

message: 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)
replies: text: .  Stepho  talk  05:27, 4 August 2014 (UTC)
thread_title:  Kernel example 

message: 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)
replies: text: I would just add a note to each of the affect styles to say that the space between the ')' and the '{' is optional. Similar for '} else {' and '}else{' .  Stepho  talk  05:17, 4 August 2014 (UTC)
thread_title:  What about coding styles omitting a space after the parenthesis? 

message: 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)
replies: text: Whether or not braces are used is not really a part of an indentation style. The documentation of the Linux kernel describes something very similar to the "kernel normal form" but the actual code does not follow that documentation. Schily (talk) 10:17, 17 June 2015 (UTC)
thread_title:  What is the Linux kernel written in? 

message: 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)
thread_title:  publication vs copyright dates 

message: 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)
thread_title:  Removal of section "Compact control readability style" 

message: Hello fellow Wikipedians,
I have just added archive links to  on Indent style. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive http://web.archive.org/web/20060228095122/http://developers.sun.com:80/prodtech/cc/products/archive/whitepapers/java-style.pdf to http://developers.sun.com/prodtech/cc/products/archive/whitepapers/java-style.pdf
*Added archive http://web.archive.org/web/20080513084244/http://java.sun.com/docs/codeconv/CodeConventions.pdf to http://java.sun.com/docs/codeconv/CodeConventions.pdf
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 05:29, 28 February 2016 (UTC)
thread_title:  External links modified 

message: 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.
Jibsendk (talk) 21:48, 2 April 2016 (UTC)
thread_title:  Stroustrup encouraging Allman style 

message: 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:
: When adhering to K&R, each function has its opening brace at the next line on the same indentation level as its header, the statements within the braces are indented, and the closing brace at the end is on the same indentation level as the header of the function at a line of its own.
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)
replies: text: K&R indents functions and control statements differently. On control statements, the opening brace is on the same line. On a function definition, it is on the next line, like in Allman's.— Edgar.bonet (talk) 19:10, 14 December 2016 (UTC)

text: I think the confusion is caused by Suns style guide as it claims to use K&R for a completely different language. They really mean egyptian brackets. I develop in C/C++ for almost 20th years now. If Suns style is a variation of K&R, then from my perspective Allmans is too, since all styles for C style languages are more or less derived from K&R. So I suggest to use Sun Style instead and use K&R only for C and C++ (see false dilemma).--80.151.196.211 (talk) 16:42, 16 May 2019 (UTC)
thread_title:  Confusion as to difference between K&R and Allman. 

message: "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)
replies: text: Of course they can both be right. They are quoting contrasting opinions. — Edgar.bonet (talk) 13:20, 22 February 2017 (UTC)
thread_title: Tabs vs Spaces

message: "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)
replies: text: That statement in the article contradicts the overview table. One of them has to be wrong. --mfb (talk) 11:24, 23 July 2017 (UTC)
replies: text: I corrected the categorical statement in the overview table. As the article currently stands, K&R style for functions differs from the brace style for compound statements. Thank you for catching this. --Ancheta Wis    (talk  | contribs) 10:32, 24 July 2017 (UTC)
thread_title: K&R style description is wrong

message: 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)
replies: text: It's hard to understand the tagged contribution: should this tag be "editorial opinion in lieu of source"?  Do the sentences about ALGOL mean we ought to ignore the braces in the GNU example? Wouldn't it be cleaner to delete the opinions about ALGOL, since there is no ALGOL code example, and that we are expected to imagine its style? --Ancheta Wis    (talk  | contribs) 02:09, 12 January 2018 (UTC)

text: Editors are not reliable sources of information.  If you want to discuss that aspect, you might want to first read the guideline.  Also original research detracts from a topic TEDickey (talk) 09:01, 12 January 2018 (UTC)
thread_title:  editorial option in lieu of source 

message: 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)
replies: text: If memory serves me, 1TBS was meant ironically, not meant literally, in the beginning. I would need to dig in Kernighan / Ritchie .. to back this up with a page number /date... (who else, any suggestions?) This was the period when C was the latest and greatest, and programming was not so heavyweight. Now that I have written this down, the formative period 1972 to 1978 must have been the time, such as when Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code (all 10,000 lines) was samizdat. (There was a time when every copy of the Lions book was tracked down and taken away!) --Ancheta Wis    (talk  | contribs) 23:55, 8 November 2018 (UTC)
thread_title: 1TBS sources

message: 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)
thread_title: YAML

message: 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 style
while (x == y)         {
    something();
    somethingelse();   }
- Bevo (talk) 12:48, 2 June 2019 (UTC)
thread_title: Python style

message: Currently, the name of this article is "Indentation style". To my opinion, this is just misleading, because:
* The main difference between these styles lies in the placing of the braces of the compound statement ({...}) that often follows a control statement (if, while, for...).
* These styles are also describes how to use spaces inside the line (e.g. the space after a function name: GnuStyleFunction () vs. AllmanStyleFunction().
So, the name "Programming style" or something like "Brace placement" will be better. However, the "Programming style" article already exists. - 178.66.136.200 
:The name 'indentation style' is how it is known in the industry. Changing the name would lead to even more confusion.  Stepho  talk  10:32, 14 July 2019 (UTC)
replies: text: This good faith suggestion would incorrectly restrict the article from including the views expressed in languages that depend on the off-side rule, which is on-topic. --Ancheta Wis    (talk  | contribs) 11:31, 14 July 2019 (UTC)

text: Regarding the name "Brace placement", it should be noted that programming languages exist that do not use braces, such as Python. LordOfPens (talk) 22:15, 28 August 2019 (UTC)

text: I agree with you 178.66.136.200! (if that really is your name:) ... But seriously, you are right that the article goes beyond indentation 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. ... Stepho's comment is neither here nor there. You didn't suggest or imply changing what terms industry uses (which is not even possible). ... Ancheta Wis's comment seems to imply that you want to drop talk of off-side rule but you didn't say or imply that ... LordOfPens's comment is good in that I don't think this article should be called "brace placement". Further, an article name should be a notable term; not a description (even if the description is apt). ... What I see is that the article covers a broader topic than indentation style. I propose to move any information that it outside the concept of indentation style to another article. I'll add a new entry at the bottom (for visibility) with details. Stevebroshar (talk) 12:38, 22 March 2024 (UTC)
thread_title:  The name of this article 

message: 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)
thread_title:  K&R vs. Linux kernel 

message: 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)
replies: text: That 'Haskell example on in the "Brace placement in compound statements" section' is actually (supposed to be) a C example using what is called "Haskell indentation style", I think? -- Tea2min (talk) 11:22, 18 January 2023 (UTC)
replies: text: I think that's the intention, but as far as I'm aware there is no such thing as "Haskell indentation style" for C programs! I've never come across this style in the wild, and there are no references for it in this article. I think the author of these examples was doing some "original research" in adapting Haskell style to C code. Kcsmnt0 (talk) 00:16, 19 January 2023 (UTC)
replies: text: Yes, I agree. I'm removing that example from the "Brace placement in compound statements" section. -- Tea2min (talk) 06:00, 19 January 2023 (UTC)
thread_title:  Misleading Haskell example 

message: This article goes beyond indentation style. The example styles cover more than indentation. They about coding style in general.
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. 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)
thread_title:  Scope creep