Jump to content

Talk:Indent style/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Advantages and disadvantages of each style

Is this commentary really necessary? It seems completely POV. I think it suffices to state what each style is, and let the reader make their own decision about the pros and cons. --JRavn 21:29, 26 July 2006 (UTC)

I take that back. I think the commentary is a good idea. But I think it could be really improved. It almost reads as not NPOV if you don't read carefully - it doesn't necessarily distinguish itself as opinion. So I think some editing could be used to improve the pro/con commentary. --JRavn 21:34, 26 July 2006 (UTC)

linux kernel in K&R style?

The linux kernel is not written in K&R style - it's closer to BSD/KNF style. Some parts of it (eg. drivers) are written in other styles though.

The K&R style looks identical to BSD/KNF style. What's the difference? Also, I would say the linux kernel uses its own style, as documented by Linus's CodingStyle file in the source. It is very similar to K&R. --JRavn 20:45, 26 July 2006 (UTC)
The KNF style appears to be more strict than the K&R style as it also has rules on how to indent continuing broken lines (i.e. using 8 columns indentation for blocks but 4 for continuing broken lines). Although many styles can be used independently of the indentation width, it is not the case for KNF. Moreover, KNF styled code must be printable on standard 80 columns terminals and printers, and as such the style also regulates the tabulation settings and maximum line length. 66.11.179.30
K&R uses the same indent rules. I'm pretty sure K&R also dictates using a max of 80 columns. Maybe the difference is that KNF is a specific standard, whereas K&R is just based on the style used in the K&R book examples. --JRavn talk 14:59, 17 August 2006 (UTC)
I may have spoken prematurely. I'll have to check my K&R book when I get home. --JRavn talk 15:04, 17 August 2006 (UTC)

pulling returns left, merge

I personally use Allman style in my projects and at work, but I think this statement about 1TBS is just untrue: "Disadvantages of this style are that the beginning brace can be difficult to locate when scanning lines of programming code (the eye must repeatedly jump from the beginning of the line to the end and back again)" -- would this author say that reading English is at a disadvantage because the eye must change lines? That's bullcrap.

I don't think 1TBS users even care to locate the beginning brace. They know where it is without seeing it. If we truly used the braces to read code, we wouldn't bother with the indentation. In 1TBS, the beginning brace is intentionally placed in an out-of-the-way location so it isn't a distraction. Indentation itself is the visual indicator of code blocks, with the beginning brace serving solely to appease the compiler. AlbertCahalan 18:11, 4 June 2006 (UTC)

To locate a brace in 1TBS, simply find the first indented line; this is easy to see by looking at the left margin. The line before the first indented line contains the brace at the end. This is also easy to locate: find the indented line, move up one, scan to the end. The eye can do all of these things very easily. There is no "confusion" about where the eye has to scan, and there is certainly no "repeated" jumping. Saying the eye has to repeatedly jump is a lie and should be changed.

In pretty much every brace style, the eye has to do the same amount of work. That's not the reason for using various brace style. The primary differences are just in the look-and-feel. Allman is for me because I like verbose code. I can see why a lot of people use 1TBS; it's probably my second favorite style. The rest of them are very shitty, though. No one really writes code that way =P Well, ok, sometimes.

Opinions? Xiphoris 08:58, 3 June 2006 (UTC)

Nobody here seems to care that over 4.7 billion trees a year are destroyed by advocates of the Allman style. (yes I know, citation needed) Additionally, doesn't it make sense that your mouse wheel will last so much longer if you embrace the One True Brace ? Sorry, I'm in the perfect job except for the fact that Allman is used, and I must conform. I needed to vent somewhere. ;) pax vobiscum Woolhiser (talk) 05:23, 17 August 2011 (UTC)

I concur it's pretty much the same amount of work for the eye, and a matter of taste (or way of thinking). As long as you are used to the style, things are where you expect them to be, so no need to scan for things. It becomes "difficult to locate" only when you have to read a style you are not accustomed to. So, I vote to remove that offending "repeatedly jump" part.

(And I am one of those who write code that "shitty" way, thank you very much ;P - Whitesmiths style here.) --92.204.95.172 (talk) 10:37, 18 February 2011 (UTC)


I like to pull returns and break to the left, so that the flow break is very visible, but this probably a brainchild of mine that never caught on.

Has anyone considered merging this article with the material under indentation? I think they are both children of the Jargon File entry on the same. --Ardonik 00:46, Jul 16, 2004 (UTC)

I would argue to keep them separate. Indentation has a seperate meaning to that in computing. The text in this article is a bit more refined, IMO, as well, so perhaps merge the programming stuff in Indentation here. Dysprosia 02:08, 16 Jul 2004 (UTC)
As above, but I suggest that there be a more generic article on formatting of source code. (I really hope that isn't as boring as it sounds on re-reading)
What if this page was moved to Programming Styles, and the examples fleshed out to, maybe, 7 lines to show how variables are named and where spaces go?
I suggest this because a "Programming Styles" page would be useful, but if it existed it would duplicate the info on this page. So, if I get the time some night, any objections to me turning this into a full blown Programming Styles article? Gronky 23:11, 29 Jul 2004 (UTC)
What other styles are there? As this page says, there are other indenting or whatever styles used by people, which come and go. If you're talking about variable naming and spacing or whatever, we have articles on Hungarian notation and Camel case and naming convention or whatever, so I think it may just duplicate those articles. Dysprosia 03:11, 30 Jul 2004 (UTC)
I've never pulled returns and breaks to the left, but I've been pulling all temporary debugging code all the way to the left for years. It makes the debugging code stand out a bit, which encourages me to delete it as soon as possible, enforcing the "temporary" nature. 66.93.32.217 04:57, 18 May 2006 (UTC)
Likewise. It's a Good Thing. PeteVerdon 22:16, 23 May 2006 (UTC)

GNU style

The pros and cons for GNU style looked like filler, so I'm guessing no one was madly attached to them. While 2+2 == 4, GNU style won't produce any more line overflow than the other styles. As a GNU styler, I know the con I've written is true. Gronky 23:43, 28 Jul 2004 (UTC)

To explain the Lisp influence, perhaps contrasting with some code would be a good idea. For example, 

while (x == y)
  {
    something ();
    somethingelse ();
  }
finalthing ();

translated to Lisp, 

;; using C-style,
(while (= x y)
  (
    (something)
    (something-else)
  ))
(final-thing)
;; though the typical formatting is
(while (= x y)
  (something)
  (something-else))
(final-thing)

Comments?--66.46.41.93 18:55, 7 April 2006 (UTC)

Other languages

I added a note to point out that indentation isn't ALWAYS just a matter of readability. A number of programming languages use the indentation to DETERMINE the structure of the program - rather than it merely being a matter of readability. Occam and Python came to mind - if anyone knows of others - they should probably be added.

Older Fortran and Cobol compilers had annoying restrictions on indentation. --DavidCary 18:02, 20 Apr 2005 (UTC)

There's Haskell, too. Fredrik | talk 18:21, 20 Apr 2005 (UTC)
And of course the horrible RPG. - tgirl

It might also be good to add one or two examples in other languages. Indentation of Pascal using anything other than BSD style would look pretty nasty. How do people indent LISP?

LISP is fairly unique, like python, for not having many different ways of indenting. If you want to know more about indentation I'd reccomend looking at Practical Lisp, as it has a section detailing it.


if (x < 0) {
    printf("Negative");
    negative(x);
} else {
    printf("Positive");
    positive(x);
}

K&R style 


if(x<0){
    printf("Negative");
    negative(x);
}else{
    printf("Positive");
    positive(x);
}

Another common style that squeezes out even more spaces. Is there a name for this style? Other than Avoiding Guido's pet peeves? --DavidCary 18:02, 20 Apr 2005 (UTC)

It actually sort of looks more like Python than many other styles... Fredrik | talk 18:21, 20 Apr 2005 (UTC)

Well, I always did Pascal in one of two ways. First way: 

 IF blah blah blah BEGIN
   blah blah
   blah
   WITH blah BEGIN
     blah
     blah
   END
   blah blah
 END

Second way: 

 IF blah blah blah BEGIN
   blah blah
   blah
   WITH blah BEGIN
     blah
     blah
     END
   blah blah
   END

AlbertCahalan 06:09, 5 January 2006 (UTC)

That is not Pascal, this is: 

 if blah blah blah then begin
   blah blah
   blah
   with blah do begin
     blah
     blah
     end
   blah blah
   end

 if blah blah blah then 
 begin
   blah blah
   blah
   with blah do 
   begin
     blah
     blah
   end
   blah blah
 end

Personal opinion: due to Pascal's verbosity, the second one is pretty, and the first one is ugly (although the simplicity of the for loop in Pascal is actually less verbose than many other languages). Another personal opinion: CAPS LOCK may have been useful on older computer systems, but nowadays since syntax highlighting is dominant in many text editors, there is no point in obfuscating the code with caps lock code. LFiveZeroFive 07:45, 6 July 2007 (UTC)

You used do and then the wrong way round - I fixed that for you. Apart from that I find the article so C dominant it should be renamed to "C indent style". But then - in most other languages controversy is not as high - for example in Pascal only Allman and GNU style was ever used. --Krischik T 06:52, 14 October 2008 (UTC)

NPV

Can someone have a look at the writeups for the styles to make sure they're NPV? The article seems to favor BSD/Allman by using "proponents of this style" with the other two. I'm not sure this is appropriate, and looks like a simple fix for someone familiar with the topic. --Steven Fisher 06:53, 29 Apr 2005 (UTC)

Okay, I decided to give it a go myself. Please have a look and see if I've screwed anything up. --Steven Fisher 03:26, 7 May 2005 (UTC)

I'd like for something to counter the egregiously non-NPOV "The One True Brace Style" slogan claimed by K&R advocates. Is there a counter-slogan for any of the other styles? - 204.145.242.1

This doesn't come under the NPOV policy, because Wikipedia isn't claiming that it is the One True Brace Style, merely that certain people think so. PeteVerdon 21:43, 19 April 2006 (UTC)
POV? I have heard they defend languages as their religion. Indent style? lol! Anu Raj (talk) 20:18, 25 February 2012 (UTC)

A style adopted by the Nagios product.

A format used by the http://www.nagios.org project: 

   if (x < 0) {
       printf("Negative");
       negative(x);
       }
   else {
       printf("Positive");
       positive(x);
       }

This is eccanomic with lines so that a page of code scans well. It shows the content of the section very clearly, all lines in the section are intented by the same amount.

Fine, but due to Wikipedia:No original research, we don't include people's own personal styles. Dysprosia 12:34, 17 Jun 2005 (UTC)
I Have altered reference to point at Nagios project, rather than my self. Nagios also uses this style. Hope this is better. ben@clewett.org.uk 09:07, 15th Sep 2005
Long ago I used it, so clearly Nagios isn't the only project to come up with this idea. It does kind of make sense. AlbertCahalan 04:27, 3 October 2005 (UTC)
I have encountered this indentation style in many projects as "banner indenting" and included a section on it, including an invitation to readers to help find other names for it (hope that's ok -- am a wikipedia newbie and am still getting the hang of the etiquette here). Banner indenting has some visual scanning features that appeal to me as an engineering psychologist, and I though it deserved some pixels. Jfkelley 16:01, 5 March 2006 (UTC)

K&R style less common?

What's the source for this?

It probably is less common for C++, but more common for plain C. I think Bjarne Stroustrap used the BSD style. The first book on the language sets the style standard. Somebody should mention the common Java and C# styles, almost certainly being the styles used in examples from the language designers. AlbertCahalan 04:25, 3 October 2005 (UTC)
No, Stroustrup uses the K&R style in "The C++ Programming Language". John Tsiombikas 00:41, 2 November 2005 (UTC)

K&R Function Style

I added K&R style for Functions, as this is the way it's done in the book. I don't know if it's the accepted method for One True Brace, though, so if not feel free to edit. - mcfly

It is accepted. The Linux CodingStyle file mandates it. The minor variation of not special-casing functions is decently common though. Spacing within the line (that is, other than the indent) is seldom strictly enforced. AlbertCahalan 06:00, 5 January 2006 (UTC)

BSD style differing from the KNF ?

The article says BSD style puts the first brace of the control statement on a line of its own, but FreeBSD and OpenBSD both dictate the other method. From the KNF (Kernel Normal Form) manpage of Freebsd: 

   for (; cnt < 15; cnt++) {
           stmt1;
           stmt2;
   }

see FreeBSD KNF and OpenBSD KNF

Think of "BSD style" as just a name. Dysprosia 08:36, 18 January 2006 (UTC)
I also find it odd that Allman style is called "BSD/Allman" considering that most BSD code is actually using the BSD/KNF style, indeed. This also makes it confusing whenever I see people relate to the "BSD style" in the article or in this discussion page; which are they referring to? BSD/Allman appears to be misnamed. 66.11.179.30
The page references "Jargon File article on indent style", that states "Allman style — Named for Eric Allman, a Berkeley hacker who wrote a lot of the BSD utilities in it (it is sometimes called BSD style)." So if noone opposes I will rename it BSD/Allman as it was named until 2007-07-10. —Preceding unsigned comment added by Kvasi (talk • contribs) 15:56, 11 September 2007 (UTC)

Indentation of broken long lines

I think that this article shoud consider talking about the indentation style used when a line of code has more than 80 characters.

An example could be something like 

printf("This is a long long line used to debug: %s = %d",
       the_first_parameter(),
       the_second_parameter());

So it would be interesting to know what the coding style guides say or imply about these cases.

(unsigned)

I suggest breaking it like this:
printf(
       "This is a long long line used to debug: %s = %d",
       the_first_parameter(),
       the_second_parameter()
);
24.110.60.225 04:47, 13 February 2006 (UTC)
I often find myself using this in Python:
printf(
    "This is a long line used to debug: %s = %d",
    the_first_parameter(),
    the_second_parameter())
or with dicts:
very_long_variable_name = {
    'eggs': 5,
    'spam': True}
This is probably a LISP-y modification of the style I was familiar with from Java et al (like 1TBS for braces, but without the space before the opening one).
It makes sense in Python because blocks don't have to be closed due to the lack of braces, so the closing (brace/parens/whatever) line feels a bit inconsistent and distracting.
I would never use this syntax for control structures (in languages that use braces for them), though, so I think the two are indeed very distinct conventions (ultimately this is probably a matter of coding style, though, as some conventions are pretty exhaustive, e.g. Python's PEP 8) --- 78.35.103.86 (talk) 08:43, 28 April 2010 (UTC)

K&R Section a little confusing

The K&R section is a little confusing because it compares and contrasts it to the BSD style indentation, which we haven't seen yet. This was my first time reading the article and I ended up scrolling down to read teh BSD style description and then going back to read the K&R description.

So BSD/Allman should come before K&R
No, the K&R section just needs some minor editing. (K&R belongs first for historical reasons)

While true that many Java programmers use the Allman style, Sun recommends mostly a K&R style. See http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Modified BSD/Allman style

I'm starting to think that I'm the only person on the planet that does this: 

while (x == y)
{   something();
    somethingelse();
}
finalthing();

Almost all of the benefits of the BSD/Allman style, and it doesn't eat any more screen space than K&R. The braces are still vertically aligned so you can visually pair them up. The only downside is that it makes copy-and-paste coding slightly more difficult, since you can't just do select-by-line, but since I use the mouse for selecting blocks of text, it's not hard (for me, at least) to click just to the right of the brace and drag down. Also, I've never found out how to explain this style to Emacs (I use NEdit, or nano under duress). --146.6.204.179 22:40, 24 January 2007 (UTC)

I also use a modified Allman style. if(x == y) { something(); somethingelse(); } else { yetsomethingelse(); onemorething(); } finalthing();

I like how the else or else if ties to the previous if. 71.169.8.7 (talk) 06:19, 6 August 2011 (UTC)

The banner added to the top of Banner Style asks for references or sources. That seems odd, since it doesn't seem to reference anything. Unless someone is wondering why it is called "Banner", and is that name wide spread? So some etymology section is in order.

As for showing that it's been in use, I've used that style in some 140 publications since 1989. I've never known it to have a special name.

—Długosz

HTML example reverted

User dlugosz updated the HTML section under Banner Style to align/indent the html tags in a manner that is more commonly used (where the closing tag, e.g., /td, aligns with the opening tag, e.g., td). I appreciate the improvement, but, begging your pardon, I did an "undo" on those changes because they did not reflect the Banner Style (where the closing tag aligns with the indented content, not with the opening tag). Jfkelley (talk) 14:09, 4 November 2008 (UTC)

Actual Frequency

More text on how often each style is actually used, please. Which is most popular?

GNU good, everything else bad?

While reading this article, I got the feeling that someone was trying to say "GNU style good, the rest is bad." With one of the reasons being: "A more critical disadvantage of this style is the danger that a programmer may accidentally, out of habit, end the 'while' line with a semi colon."

A *critical* disadvantage, nonetheless.

I have been programming C for many years, using a lot of different styles throughout those years, and I have never accidentally put a semicolon after a while(). What's more, if that would have happened, it could just as well have happened while using the GNU style or the K&R style, and it wouldn't be more/less difficult to see it because of the indentation style. The *font* and *syntax highlighting*, however, would be able to help there.

I frankly don't care what style people use. One can discuss aesthetics, but when someone starts to try to make it seem like a indentation style lessens the likelihood that you'll accidentally push wrong button, and then miss that you did that (or however that accident is supposed to happen), then I can not help think "What is this person's ulterior motive?"

Someone should add a big "This is a subjective 'article.' It presents opinions, not facts" sign on the top of the page. —The preceding unsigned comment was added by 130.243.238.207 (talk) 12:46, 30 March 2007 (UTC).

Yup, this paragraph should go - it has nothing to do with identation style. 85.130.32.45 20:04, 27 April 2007 (UTC)

Whitesmiths style

I believe this is the primary style used in most OpenSSL source code. Could someone more familiar with this style double check? If it is confirmed, I think it should be mentioned since the article seems to imply that nobody uses this style anymore.

it's a well known fact that chicks dig dudes who use Whitesmith brace style. You come up to a honey like this with your weak Allman shit an start talkin bout gettin some digits and she'd be all like "naw you a scrub" and you'll be all "damn girl that's cold." Meanwhile I roll up with my whitesmith all up in the place and she be all over my jock, because the bitches go crazy for the One True Brace Style. ps an old coworker used K&R style and he was the worst person ever. The only way you could have made him useful would have been to skin him and make wallets and belts out of his oily hide. 202.78.240.7 (talk) 04:23, 11 June 2008 (UTC)
the man above speaks the Truth. Whitesmith is what life is all about; anything else and you might as well saw off your head with any implement available. —Preceding unsigned comment added by 71.10.64.64 (talk) 10:29, 23 January 2009 (UTC)
Whitesmiths only here - even made it company policy. Several zillion lines of code per year in Whitesmiths, different languages, that ought to count for something. --92.204.95.172 (talk) 10:41, 18 February 2011 (UTC)

what 92.204.95.172 en 202.78.240.7 be talkin about? des brothas best show what Whitesmith style be all about — Preceding unsigned comment added by 50.133.254.143 (talk) 05:35, 5 January 2013 (UTC)

I've been coding for 20 years on my own projects, with nobody around to tell me how to indent. Over the years, just coming up with a style that I personally found the most readable and logical to me alone, I find that I had reinvented the Whitesmith style on my own. JeramieHicks (talk) 23:26, 11 February 2013 (UTC)

K&R in today's C syntax

Since the book is based on a syntax which was subsequently modified by later C standards, the K&R style should be seen or reviewed according to the current C/C++ syntax. Today K&R would indent a function header like this: 

int main(int argc, char **argv) {
    ...

since AFAIK in other examples in the book, whenever a function had no arguments, it was presented with the { on the same line with the function declaration. Here's an example: 

int zero() {
        return 0;
}

K&R did not see a necessity to have { } match up on the same line since the function declaration already matches up with the } indent-wise. Having { on a line by itself was the next visually acceptable thing to do as the original C syntax did not permit to have it all in one line.

So modern K&R style would be to never have a { on a line by itself. --lynX 11:24, 23 June 2007 (UTC)

As far as I know, K&R always put function braces on their own lines. At any rate, there are numerous times when functions with no specified arguments (e.g. main()) had the brace on a separate line (K&R p. 134) or when a function with void parameters (e.g. rand(void)) had a brance on a separate line (K&R p. 46). – Mipadi 15:46, 23 June 2007 (UTC)

Alright, I don't have the book. So I saw citations from the book that were presented inaccurately on the web. Yet, one could presume K&R only put function braces on their own lines because in one case it was necessary and in the other case it would have been an illogical exception. Now that arguments have moved into the function declaration, wouldn't it be a very appropriate speculation that K&R would have chosen to never have the open brace on its own line, because there no longer is an obvious necessity to do so, so it's an exception from the rule now. Why put open braces on their own line in just one case if in all other cases they are attached to the end of the line? So it could be appropriate to speak of an Updated K&R style. Best of course if K&R throw in an opinion themselves!  ;°) --lynX —The preceding signed but undated comment was added at 09:57:28, August 19, 2007 (UTC).

K&R put braces on their own line for functions because in C, function declarations originally looked like this:
int my_funct(x)
int x;
{
(This might not be the exact syntax, but it's something like that.)
I believe that later on, the reason for putting a brace on its own line was because functions couldn't be nested.
Anyway, I'm just reporting on how K&R do it in The C Programming Language. I can't speculate on anything else, especially since this isn't the way I use braces. :) – Mipadi 13:45, 19 August 2007 (UTC)

I have the K&R book version 2.0, which uses modern C/C++ syntax; I will check to see where they put braces in function definitions tonight. —Random832 22:08, 6 December 2007 (UTC)

Xcode

The Allman style section ends with "This style is used by default in Microsoft Visual Studio 2005 and Apple's Xcode.", but Xcode 2.5, at least, uses BSD KNF style by default. Does anybody know if it changed in a recent version of Xcode, or if the sentence is simply an error? Cheers, Tangotango (talk) 02:06, 21 November 2007 (UTC)

  • Xcode is largely style agnostic. Most of the example code distributed with it uses KNF style, but, in Xcode 3.0, using the Refactor tool to extract code into a function produces Allman style code. It's reindent command seems to be style-agnostic. Resistor (talk) 23:18, 22 December 2007 (UTC)

Wishart

This rather rare indentation is not represented in the article, I think it ought to be. I don't know the exact formating nor history of it so maybe someone who do know could fill it in. Lord Metroid (talk) 21:52, 6 December 2007 (UTC)

Found out it is called Whitesmiths style as well as Wishart Style. Lord Metroid (talk) 00:05, 23 December 2007 (UTC)
This is the style I started using naturally, because it is the only one that is clear and makes any sense. All of the others are horrible, and if those are what most people use, it's now wonder that the world is so full of terrible software and bugs. -- Jerome P. —Preceding unsigned comment added by 71.10.64.64 (talk) 10:32, 23 January 2009 (UTC)
Funny you should say that, same for me - it's the style that shows what really happens, with scopes and stackframes opened and closed. Repent, sinners! --92.204.95.172 (talk) 10:45, 18 February 2011 (UTC)
Same here. I developed my own personal style that I found most readable to me, and turns out it's almost the exact same thing as Whitesmiths. JeramieHicks (talk) 18:10, 8 March 2013 (UTC)

Missing Brace in BSD KNF Example?

It looks to me as though the second example in this section--the one that begins with "(data != NULL && res > 0"--is missing a closing brace. I'm not really clear on what the code in the fourth line is doing, but it opens a brace that is never closed... Szarka (talk) 10:44, 28 April 2008 (UTC)

K&R Citation Needed?

"In other words, the K&R style, along with "brace everything," makes code development and maintenance easier and safer, by reducing the opportunities for erroneous code insertion.[citation needed] It is not space-saving, but logic-preserving and syntax-expressing.[citation needed]" Huh?

What is the controversy here? The text presents examples showing K&R style vs. another style with fewer lines (so K&R is not space-saving); and examples of non-K&R style wherein //1, //2, etc., code insertions throw errors or break logic, against the K&R style example where //1, //2, etc., insertions will not throw errors nor break logic. The citations asked for would be the examples given. PKlammer (talk) 08:33, 28 May 2008 (UTC)

I think the whole assertion that this style is inherently 'safer' and 'easier' should be thrown out - the 'opportunity for erroneous code insertion' would be the same regardless of indent style; the only real difference would be how the error manifests itself. The example makes the case for 'brace everything', which would benefit all styles, not just K&R.
Furthermore, the terms 'logic-preserving' and 'syntax-expressing' are vague. The assumption the original author is making that both are inherently good things, without saying why or even what they are.
I move that everything from 'At first glance...' to '...syntax-expressing' be cut. Rexstuff (talk) 20:05, 29 May 2008 (UTC)
I've let this question stew for a couple weeks (That's me, Rexstuff, above - I've had a name change since then), and no-one's said anything, so I'm going to go ahead and make the cut. The original text is posted below. --TFriesen (talk) 04:58, 13 June 2008 (UTC)
As much as any author hates to see his writing edited, I have an impulse to defend my contribution. However, enough of it survives, both in the clipping below (between """'s, and I thank you for that!), as well as that remaining in the main article, that I'm not pained. In particular, the idea that style choice is not merely arbitrary consistency, and that K&R style represents syntactical as well as logical structure in its layout, is now present in the narrative where it wasn't before.
I would like to second (or third) the nomination of a "Consistent K&R Style" or "Modern K&R" definition (started under "K&R in today's C syntax" above), including particularly the consistency of no lonely opening-brace lines (as modern C no longer requires anything between a function's type-name-arguments declaration and the brace opening its body definition. Along with that, the no-unbraced-ifs (or -elses, -whiles, or dos) rule. But this is didactic advocacy, now, which isn't the province of the Wikipedia article, is it? Where, then? PKlammer (talk) 02:18, 25 June 2008 (UTC)

"""

At first glance, the motivation of this style is seems to be to conserve screen real estate (and keep more code visible at once) by avoiding the need to dedicate an entire line to a single character (at the time this style was originated, a typical terminal had only 24 lines visible). However, the dedication of an entire line to the closing brace belies that notion; otherwise, a style fully motivated by line conservation would look more like this: 

//...
    while (x == y) {
        something();
        somethingelse(); }
    if (some_error) {
        do_correct(); }

On the contrary, many advocates of the K&R style also advocate "brace EVERY if (and else, and while, etc.), which does not minimize lines. Consider in the following example: 

//...
    if (some_error) {
        //1
        do_correct();
        //2
    } else {
        //3
        continue_as_usual();
        //4
    }

By adding braces, and increasing the number of lines, new lines of code may be safely inserted at all locations //1, //2, //3, and //4, without breaking logic or syntax.

By contrast, as in all the remaining styles below, insertion of code at these locations breaks either syntax or logic: 

int main(int argc, char *argv[])
//1
{
    while (x == y) 
    //2
    {
        something();
        somethingelse();
        if (some_error)
            //3
            do_correct();
            //4
        else
            //5
            continue_as_usual();
            //6
    }
    finalthing();
}

In other words, the K&R style, along with "brace everything," makes code development and maintenance easier and safer, by reducing the opportunities for erroneous code insertion.[citation needed] It is not space-saving, but logic-preserving and syntax-expressing.[citation needed]

"""

"form follows syntax"

I'm removing the sentence

The elegance of the K&R bracing style lies in its expression of "form follows syntax", by maintaining a simple principle: separate lines (only) where lines may be inserted.

because I cannot see how the italic part supports the bold part (looking at the C grammer, the form follows syntax argument seems much easier to make for the Whitesmiths style), and because I couldn't find any reference to this outside of this article.

92.194.35.246 (talk) 11:27, 8 July 2008 (UTC)

Fibonacci Indentation

I seem to recall there was once a Mozilla developer who used Fibonacci indentation in C/C++ code. So code would look something like this: 

int main(int argc, char *argv[])
{
  ...
  while (x == y) { // indent=2
     something();
     somethingelse();
     if (some_error) // indent=2+3
          do_correct(); // indent=2+3+5
     else
          continue_as_usual();
  }
  finalthing();
  ...
}



I don't get it. Aloysius-Fibonacci (talk) 13:27, 5 October 2009 (UTC)

As shown in the example, Fibonacci indentation uses increased spacing with every indent level: 2 spaces for the 1st level, 3 for the second, 5 for the third. Whatdoesitwant (talk) 09:46, 20 January 2010 (UTC)

1TBS: What does it say about functions?

A strict reading of the 1TBS description would imply that it does not follow the K&R style for functions, where the opening brace for the function is on a separate line from the function declaration. However, 1TBS is described as a variant of K&R, and it does not explicitly say that it changes the rule for functions. In a quick google search I can't find any other source that clarifies this question. Can anyone with more knowledge clarify this point?

Kevin Ballard (talk) 10:48, 5 March 2009 (UTC)

I want to know this too. 109.255.182.79 (talk) 02:41, 13 November 2010 (UTC)

References to Vi

This is about the hard/soft tabulator paragraph in BSD KNF style, where Vi is mentioned. According to Vi documentation shiftwidth/sw default value is 8 not 4. It also states that shiftwidth/sw (soft tabulator in the article) is used to indent a block, not tabstop/ts (hard tabulator in the article). Mentioning Vi as an example doesn't seem to serve the purpose here.

Juduve (talk) 18:22, 12 May 2009 (UTC)

Allman style unsuitable for javascript

Allman style is unsuitable for javascript because return statements that are not empty are misinterpreted as empty. In javascript lacking end-of-statement semicolons are not illegal. Javascript interpreters simply insert virtual semicolons to correct. According to Robert Nyman:

Unfortunately, semicolons are optional in JavaScript, which leads to developers being sloppy, using them in some places, while omitting them elsewhere. “Luckily”, JavaScript interpreters take this into account, and at runtime, insert semicolons where it thinks it should be one.

Nyman quotes Douglas Crockford as his primary source. 

return; // Semicolon inserted, believing the statement has finished. Returns undefined
{ // Considered to be an anonymous block, doing nothing
	javascript : "fantastic"
};// Semicolon interpreted as an empty dummy line and moved down

[1] Whatdoesitwant (talk) 10:02, 20 January 2010 (UTC)

True. This doesn't work in Python (which also allows semicolons) either, though. What's happening is that you're not defining a block but an object (in Python this would be a dict, or as of Python 3000 a set, depending on what you write in between the braces). In Python this distinction makes sense (look up the rationale behind Python's lambda syntax), but in JS this may catch you by surprise if you think JS behaves like Java.
Apparently JS allows defining blocks (though this is a bit pointless as they don't create a nested scope) just like Java. But it also overloads the syntax to allow you to define objects à la JSON. Therefore your example's comment is wrong: you're not defining an "anonymous block, doing nothing", you're defining an object without assigning it.
It should probably generate a warning because the code is unreachable, though. --- 78.35.103.86 (talk) 08:21, 28 April 2010 (UTC)
Allman style does not require all braces to be wrapped, only those for blocks, so your argument does not hold water. In particular, I strongly recommend to make a distinction between declarations/statements and expressions, both with functions (FunctionDeclaration vs. FunctionExpression) and with literals, by including newline before the opening brace of the former, but not the latter. --PointedEars (talk) 17:46, 26 November 2010 (UTC)
I also support convention that Allman style requires only block lines to start with a lone brace, even more: for *Perl* I use an agreement that hashes (which are called objects in Javascript) must not start with a lone brace. In rare cases when hash definitions are mistaken with blocks, I use unary "+" (that is for Perl, I repeat). 92.243.165.4 (talk) 19:48, 17 January 2011 (UTC)

Notes on the Contextual style

The basic problem of this section is that it makes specific claims that are unverified (or unverifiable), especially as to the spectacular performance gains that this style supposedly brings, or its widespread (from the sound of the text) adoption in large companies.

In particular, the contention that it brings faster, let alone "much faster" development times is especially problematic. First in that it lacks specificity (umm, compared to what, please?); and that while it's at least plausible to believe that adopting some kind of consistent formatting style can bring significant productivity gains to a team (though even this is far from solidly substantiated) -- it simply strains the limits of basic logic and common sense to assert this particular style, or any of the other major indent styles could be that much better than all the others. —Preceding unsigned comment added by 65.88.88.174 (talk) 18:21, 22 September 2010 (UTC)

HTML, XHTML, XML

How about these? I believe they should also be mentioned in the article. —Preceding unsigned comment added by 91.49.247.220 (talk) 17:14, 13 January 2011 (UTC)

Yes, that would be nice. The problem is that there would not seem to be any single indentation style that is more preferred than the others. Probably two-space indentation per level is the most widespread. But that's when newlines and indentation are even used, as many HTML pages don't even bother with these human-readable conveniences. Then there is the problem of whether you're limiting the discussion to HTML/XHTML/XML or if you're also including Javascript in the mix. — Loadmaster (talk) 15:30, 18 April 2011 (UTC)

Original K&R indentation

The original K&R white book indented each level by five spaces. Presumably this was because each indent level was the standard typesetting indentation of one-half inch, combined with the 10-point Courier font used (at 10 characters per inch), resulting in an indentation equivalent of five character columns. IIRC, the original Unix kernel code used 8-space tabs, and I'm not aware of any official (Bell Labs) C code that actually used 5-space indents, so this convention probably existed only for the benefit of typesetting the book. — Loadmaster (talk) 15:23, 18 April 2011 (UTC)

Compact Control Readability style

Shouldn't it be placed as a K&R variant, as is the 1TBS style ? 82.216.176.12 (talk) 18:05, 10 July 2011 (UTC) anon 10 july 2011

Does any one know about the origins or users of this style? The earliest reference to the style that I can find is in this article in March 2011, which is not reassuring. Who established this convention, who uses it, and when did these events happen? — Preceding unsigned comment added by Mobius (talk • contribs) 02:14, 23 January 2012 (UTC)

Capitalization of style names

Are the style names proper names or common noun phrases? If they proper names then we should capitalize "Style" (e.g. "KNR Style", "Allman Style", "Compact Control Readability Style"). If they are common noun phrases we should write "one true brace style" and "compact control readability style" and, as we do now, use caps only for proper names (e.g. "Allman style") and acronyms (e.g. "BSD KNF style"). Jojalozzo 03:01, 23 January 2012 (UTC)

Title of page

"Indent style" is poor grammar, and not the most popular term for this subject; "indentation style" is prescriptively better grammar and also more popular. I suggest that the title of the page should be "indentation style" with "indent style" as a redirect, rather than the current situation which is the other way around. 130.179.29.61 (talk) 16:23, 23 January 2012 (UTC)

That is true, however, most programmers are probably used to hearing the term "indent style", having seen it in the user preferences in IDEs such as MS Visual Studio (where it's called "Indent size") and Eclipse. Wikipedia tends to favor the most well-known term for article titles. — Loadmaster (talk) 17:17, 23 January 2012 (UTC)
I don't believe that "indent style" is the most well-known term. The correct one has more hits in Google. 130.179.29.61 (talk) 15:29, 27 January 2012 (UTC)
I agree with the petition for the name change. Even though it might be popular, it would be better to inform all of the preferred and grammatically correct term. Indent style could still redirect to "Indentation Style". — Prietoguy (talk) 04:20, 25 September 2012 (UTC)

Allman vs. ANSI/ISO style

ISO/ANSI style is not the same as Allman style. This can be seen in the C99 spec (n1124.pdf). For example, the opening brace placement in §6.5.2.3 example 3 (p.74): 

union {
    struct {
        int alltypes;
    } n;
    struct {
        int type;
        int intnode;
    } ni;
    struct {
        int type;
        double doublenode;
    } nf;
} u;
u.nf.type = 1;
u.nf.doublenode = 3.14;

and in §6.8.3 example 3 (p.133): 

while (loop1) {
    /* ... */
    while (loop2) {
        /* ... */
        if (want_out)
            goto end_loop1;
        /* ... */
    }
    /* ... */
end_loop1: ;
}

However, the example in §6.8.4.2 (p.135) shows a different opening brace style: 

switch (expr)
{
    int i = 4;
    f(i);
case 0:
    i = 17;
    /* falls through into default code */
default:
    printf("%d\n", i);
}

But this last one may simply be an editing oversight, since it's the only example like this; all of the other examples appear to use the K&R brace style. — Loadmaster (talk) 15:39, 12 May 2012 (UTC)

Baehr style

An anonymous IP keeps adding[1] [2] a "Baehr style" section, which describes an obviously personal coding style. A google search turns up nothing substantial for the purported inventor "Christopher Baehr". Until reliable references for this style or examples of major software projects that have employed it are provided, this kind of text cannot be included in this article. (With thanks to M4gnum0n for monitoring this.) — Loadmaster (talk) 19:14, 25 July 2012 (UTC)

Thank you! Obviously I too did a little research before reverting and found nothing relevant. --M4gnum0n (talk) 10:18, 26 July 2012 (UTC)

Remove python code?

Can we remove the python example (in the Lisp section)?

Since indentation styles mostly deal with the placement of curly braces and curly braces don't exist in python, I feel that the example is uninformative. Furthermore, as indentation has semantic meaning in python, pretty much every indentation style would look the same in python. 2001:6B0:1:1E00:225:4BFF:FEBD:5DA (talk) 22:33, 21 September 2012 (UTC)

Firstly, this article is about source code indentation, not braces per se. (The article could also cover indentation styles for Pascal, SQL, and others.) Secondly, is there more than one indentation style used by Python programmers? If so, then it's relevant to this article. — Loadmaster (talk) 00:34, 22 September 2012 (UTC)
There are, if you consider bracketed expressions, e.g. multi-line lists/tuples/dicts, or function arguments. But that's not the case of the example. — 80.174.59.63 (talk) 21:27, 6 December 2012 (UTC)

A more general and informational approach

I propose that we restructure the article so that the intro becomes shorter and easier to understand. The first section can be split into two headings, the intro, and another titled controversies (for lack of a better term). We can then list every indentation style under the sun, focusing on the positive strengths of each approach, and perhaps only including any limitations or language specific notes.

The idea behind this is to allow the user being directed here to make his or her mind about which approach to adhere to. We also should have in mind that level of skill (or lack thereof) of the user reading the article. If for example, I were teaching a friend/co-worker about coding, and wanted to refer her to a list of indentation styles, this page would allow her to be informed without receiving biased opinion to one style over another.

A conclusion section to reiterate the overarching goals of adhering to a standardized indentation style would be a great way to finish the article. It would serve to remind the user that in the end, what matters most if consistency, and future collaboration. — Prietoguy (talk) 04:14, 25 September 2012 (UTC)

a Guillemet pair to indicate a block of text

Perhaps the use of a pair of Guillemets (French angle brackets) might also be discussed to denote a block of text, like indentation. They have been used in a sublanguage of UML (OCL - Object Constraint Language) to denote phrases. --Ancheta Wis   (talk | contribs) 19:18, 8 March 2013 (UTC)

The C Programming Language-- K&R?

What the book uses looks like K&R (of course), but the page says under 1TBS

"It should be noted that The C Programming Language does not explicitly specify this style, though it is followed consistently throughout the book. Of note from the book:" Am I misunderstanding? Joshuans (talk) 00:13, 10 March 2013 (UTC)

I fail to see any differences in the examples. Besides, there's some discussion as to what is Banner 'official' name, maybe it is Ratliff? Sorry if I'm mistaken. 189.5.110.254 (talk) 18:04, 6 September 2013 (UTC)

I too am confused on this point. Perhaps the Banner style should be removed? 167.220.26.215 (talk) 18:20, 10 December 2013 (UTC)

Windows set tabs to 8 spaces

The following sentence is wrong: "Macintosh and Microsoft Windows environments would set them to four..." Windows Notepad sees a tab as 8 characters wide, not 4. — Preceding unsigned comment added by Eriction (talk • contribs) 11:44, 9 September 2013 (UTC)

tabs vs spaces for indentation

It's very hard to decide the tabs vs. spaces discussion because no choice seems far superior then the other. Therefor it's interesting to see what the majority of software projects or reputable software developers prefers. This section collects such preferences. I'd like such an overview to become part of Wikipedia somewhere, not necessarily in the Intend article. Found the Indentation article now, which already contains such a list. Thkoch2001 (talk) 17:57, 25 September 2013 (UTC)

Who prefers tabs or spaces?

  • Tabs vs. Spaces in the 21st Century - majority: spaces
  • Review of Indentation Policies - majority: spaces
  • popularconvention (loads very slowly) continuously evaluates the popularity of coding convention on Github, not only tabs vs. spaces. As of september 25th 2013:
    • JavaScript: 81% spaces, 19% tabs
    • C#: 84% spaces, 16% tabs
    • Ruby: 93% spaces, 7% tabs
    • Scala: 97% spaces, 3% tabs
    • Python: 96% spaces, 4% tabs
    • Java: 76% spaces, 24% tabs

Preferences of coding styles

Pro tabs:

Pro spaces:

Preferences of people

Pro tabs:

Pro spaces:

Archive 1
  1. ^ http://robertnyman.com/2008/10/16/beware-of-javascript-semicolon-insertion/
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Indent_style/Archive_1&oldid=1086700650"