Talk:Indent style

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.

GNU indent[edit]

I find it odd that this article does not discuss mixing tabs and spaces. 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). -- (talk) 14:19, 17 December 2013 (UTC)

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)


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 (talkcontribs) 14:30, 28 March 2014 (UTC)

Kernel example[edit]

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 (talk) 11:59, 9 April 2014 (UTC)

Fixed.  Stepho  talk  05:27, 4 August 2014 (UTC)

What about coding styles omitting a space after the parenthesis?[edit]

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 (talkcontribs) 03:41, 4 August 2014 (UTC)

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)

What is the Linux kernel written in?[edit]

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 ( "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 (talkcontribs) 17:45, 16 June 2015 (UTC)

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)

publication vs copyright dates[edit]

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)

need better source for script[edit]

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)

You replaced the link to the original sources by a link to a modified version and now you complain? Schily (talk) 22:40, 6 February 2015 (UTC)
Which edit are you referring to? Yesterday, I added tags, did not change any URL TEDickey (talk) 12:10, 7 February 2015 (UTC)
P.S.: I published cstyle on July 17 2004 with permission from Bill and Sun. This was the first publication to a non-closed group. Later cstyle was published by Sun on June 14 2005 as Part of OpenSolaris, but this is of course easy to find out by everybody. Schily (talk) 23:47, 6 February 2015 (UTC)
I've seen nothing to support your statement regarding 2004. Rather, your mailing postings around that time only complain that Sun had not released it. Show us a mailing list posting, or publicly accessible bug report database showing this release announcement, which can be dated. TEDickey (talk) 12:10, 7 February 2015 (UTC)
Let me try to continue your path of thoughts...I've never seen you and I cannot find any image from you, so you cannot exist.
I recommend you to have a look at the original history from OpenSolaris at: [1] and the sccs log output from my repository:

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)

Your sccs log is not a published source of information. Also, the issue is traceability to Shannon's script, not your personal copy of it (aside from Schilling, no one comments on those changes, making them non-notable) TEDickey (talk) 01:28, 10 February 2015 (UTC)
In context of the current discussion, none of your reply is relevant to a release announcement on "July 17, 2004" TEDickey (talk) 09:54, 10 February 2015 (UTC)
Are you serious with this idea?
If yes, then we would need to edit the Revision Control System article and mention that RCS source code did never meet the OSS rules and that recent published versions are illegally using the GPL as license. Note that there is no published source of information that would allow a different interpretation of the RCS source state.
On the other side, cstyle was published by me at the mentioned day and this was announced in the public. If you are unable to find the related information, you either looked at the wrong places or the information disappeared from the net since then. Schily (talk) 14:59, 13 February 2015 (UTC)
Hmm - you still aren't responding constructively. (It appears that you have no source for any of your comments) TEDickey (talk) 00:38, 14 February 2015 (UTC)
To remind you: what is needed is a verifiable reliable source which shows when the script was first published. Comments about a program, and unverifiable claims of prior work are disregarded on Wikipedia. TEDickey (talk) 13:03, 14 February 2015 (UTC)

Removal of section "Compact control readability style"[edit]

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)

Is this a variation or does it fall under K&R / 1TBS?[edit]

The first example in the K&R section ( 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 (talk) 23:10, 5 November 2015 (UTC)

I would say it's a variant of K&R, as K&R uses this brace placement for everything... except for functions. I have seen this style used a lot in Arduino code, as most examples shipped with the Arduino environment use this style. I do not know whether it has a name. The Linux kernel coding style briefly mentions this possibility, without naming it (on chapter 3):
[functions] have the opening brace at the beginning of the next line [...] Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent [...]”.
— Edgar.bonet (talk) 08:32, 6 November 2015 (UTC)
This variant was used by K&R in the early days when there was only "ed" and people tried to avoid lines. Schily (talk) 10:58, 6 November 2015 (UTC)

External links modified[edit]

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}}).

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—cyberbot IITalk to my owner:Online 05:29, 28 February 2016 (UTC)

Stroustrup encouraging Allman style[edit]

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)

Confusion as to difference between K&R and Allman.[edit]

Under "placement of braces", K&R and variants are said to follow the

   while (x == y) {


And that Allmans follows the

   while (x == y) 


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 (talk) 20:54, 13 December 2016 (UTC)

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)

Tabs vs Spaces[edit]

"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)

Of course they can both be right. They are quoting contrasting opinions. — Edgar.bonet (talk) 13:20, 22 February 2017 (UTC)