Talk:Indentation style

Tabs and spaces

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)

GNU indent

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)

How GNU Emacs indents by default

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)

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)

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)

Praise

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)

Kernel example

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)

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

What about coding styles omitting a space after the parenthesis?

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)

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?

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)

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

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

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"

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?

The first example in the K&R section (https://en.wikipedia.org/wiki/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)

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

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:

• 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 {{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).

• 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.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 05:29, 28 February 2016 (UTC)

Stroustrup encouraging Allman style

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.

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)

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)

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)

The excerpt is not wrong, but is incomplete as it only talks about the function block. Someone extended the description to describe internal blocks (with cuddled open) at some point since your comment. Stevebroshar (talk) 11:23, 6 June 2024 (UTC)

Tabs vs Spaces

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

K&R style description is wrong

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

That statement in the article contradicts the overview table. One of them has to be wrong. --mfb (talk) 11:24, 23 July 2017 (UTC)

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)

editorial option in lieu of source

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)

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)

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)

1TBS sources

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)

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'_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)

The name "one true brace" itself is in reference to K&R, and the perceived "inconsistency" that K&R uses a different brace style for function declarations than other statement blocks. By placing the opening brace of a function body on the same line as the declaration, it uses only one single brace style for all statement blocks i.e. "one true brace". It is therefore stylistically a "variant of K&R" in that it is derived from K&R by making one change. Quoting the Linux kernel coding style manual:

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

MarcelB612 (talk) 05:33, 28 August 2024 (UTC)

References

Poor Examples

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)

The example was for exception processing, as in goto ErrorHandlingForThisSituation

In this case, it's a forward goto, which is never bad, as distinct from a LoopOfExceptionsToIgnore: which is a red flag.

Exceptions, errors, and failures need to be handled by recognizing that their respective Handlers do not belong at the same level as ordinary code. This is an organizational issue (an exceptional issue), rather than a style issue.

See longjmp .

Perhaps the article might say See Failure in the next line.

--10:31, 12 May 2019 (UTC)

YAML

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)

Python style

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)

I thought Python didn't use curlies. ... anyway, someone added python at some point already. Stevebroshar (talk) 11:08, 6 June 2024 (UTC)

They're talking about using Python-like indentation style in another language — C in this case. — W.andrea (talk) 17:04, 6 June 2024 (UTC)

The name of this article

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. — Preceding unsigned comment added by 178.66.136.200 (talk) 09:46, July 14, 2019 (UTC)

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)

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)

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)

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 post a new topic at (for visibility) with details. Stevebroshar (talk) 12:38, 22 March 2024 (UTC)

K&R vs. Linux kernel

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)

I think this was address at some point since the comment was posted. ... FWIW, although differences are not noted explicitly as such, they are both described in sufficient detail today that one can compare them. The main diff is that Linux kernel is rather explicit whereas K&R is implicit (never stated). For example, I think most would say that K&R does not imply an indentation size or whether to use tab or space. But Linux kernel requires indentation via tabs and tab stops at 8 spaces. Therefore, one could say that Linux kernel style is a specialized K&R style. Stevebroshar (talk) 11:04, 6 June 2024 (UTC)

Usefulness of having a style?

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)

There must be at least 100 flame wars for ever serious study but there are some studies out there. Eg https://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf (which refers to some more). https://thenewstack.io/spaces-vs-tabs-a-20-year-debate-and-now-this-what-the-hell-is-wrong-with-go/ also links to a few more studies about which is the most popular (although doesn't necessarily look at the effectiveness). For myself, which of the common methods used isn't really that important but consistency within the team is paramount. Choose one and everybody in the team sticks with it.  Stepho  talk  21:22, 17 October 2019 (UTC)

You're right, IP user, this is largely a religious war, and like other religious wars it will never be "won" by any one group — at least, not on the merits of their position. As biased as we humans are we can recognize good things, and if any one style had clear advantages over the others we'd all be using it. But as Stepho says, the exact nature of the style used isn't so important, the important thing is to simply have one and apply it consistently. This is true of any collaborative production, and ultimately source code should be viewed as one of the products of development.

Which is why productions adopt style guidelines — whether it's a film settling on a particular historical period to base their costume designs on, an advertising firm producing a "style bible" for each client they take on, or a publication maintaining a house style all of their contributors are expected to follow. Even Wikipedia has an extensive Manual of Style.

Code is no different, and the reasons for it are no different: It's not about technical differences (every style is syntactically equivalent), it's about maintaining consistency of tone, so that all of the content fits together harmoniously and can be easily appreciated as a coherent whole. For producers of the content, it means that they don't have to worry about the unwinnable debate over merits (just follow the guidelines), and consistency makes errors easier to spot.

To that end, and because you're not wrong that the debate over style is an unproductive use of time, some developers have been turning to automation as a solution. Tools like Black (named for Henry Ford's apocryphal policy regarding the color of the Model T automobile) and clang-format are advanced enough that they can impose formatting on code so that it adheres to either a configurable (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

That final claim is particularly compelling when it comes to collaborative development, which is why some projects (especially open development projects that may have dozens or hundreds of contributors) are choosing to simply automate their code formatting. Many more are adding formatting scans to their CI processes, and may block or reject contributions that violate the project style. (Something we should probably cover, possibly in this article, some to think of it.) -- FeRDNYC (talk) 19:03, 29 November 2019 (UTC)

IMO: When there are multiple ways to do something it will be done in every possible way. And although people have good reasons to do what they do, there is probably no best answer. I advise you to push for quality while maintaining compassion for your fellow human. Stevebroshar (talk) 12:17, 22 March 2024 (UTC)

Misleading Haskell example

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)

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)

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)

Yes, I agree. I'm removing that example from the "Brace placement in compound statements" section. -- Tea2min (talk) 06:00, 19 January 2023 (UTC)

Off topic info

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)

For reference, the scope and name of this article was previously discussed at § The name of this article. — W.andrea (talk) 17:13, 6 June 2024 (UTC)

Python Style?

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)