Talk:Indent style
From Wikipedia, the free encyclopedia
[edit] 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)
[edit] 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)
-
[edit] 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)
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)
[edit] 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)
[edit] 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)
-
- 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 do begin blah blah blah with blah then begin blah blah end blah blah end
if' blah blah blah do begin blah blah blah with blah then 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
-
[edit] 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)
[edit] 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)
[edit] Sun's recommended style for Java
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
[edit] 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)
[edit] The Dwayne style is primarily used by guys named Dwayne
WTF? is this real? —The preceding unsigned comment was added by 82.148.97.69 (talk) 13:40, 27 January 2007 (UTC).
[edit] Banner Style
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.
[edit] Actual Frequency
More text on how often each style is actually used, please. Which is most popular?
[edit] 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, none the less.
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 persons 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)
[edit] 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.
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)