Talk:C Programming/Code style

C89 vs C99

It's reasonable to mention single-line comments, which are supported by the C99 standard, but there isn't, as far as I know, a single compiler around that fully supports C99 yet. The majority of compilers in use are C89 and the C++ one-line comment is not part of that standard. Compilers that allow single-line comments through without warning usually do so as a courtesy, and if strict ANSI is enforced they will not be allowed (e.g. my gcc compiler will not allow them with the -ansi flag). I would prefer the tutorial to adhere to one standard or another, say which one it is, and stick to it. If it's going to be C89 then I'd outlaw single-line comments in an effort ot encourage good practice. I would also not use () to indicate no arguments to main. C89 mandates the use of void for that. -- Mickraus 23:29, 27 October 2007 (UTC)

As of 2013 the majority of compiler implements C99, and virtually all of them implement single-line comments. Maybe that should be mentioned in the article, since C99 is not a "very recent addition" any more. Moreover I was quite surprised to see that for loop initial declarations are not used in this page, which is also a C99 feature available on many compilers and is in my opinion a lot better than the C89 style. (even Visual Studio 2013 will implement that). Is it okay if I modify the page with

1 for(int i=0; i<12; i++)

instead of

1 int i;
2 for(i=0; i<12; i++)

? Or do you want to let it in a C89 style (but then why mention C99 comments?)? --Asteba (discuss • contribs) 22:11, 4 November 2013 (UTC)

Indentation Wars

To indent with spaces or with tabs seems to be one of those issues that cause programmers to go to war with one another - much like the emacs vs vi battles or the OS battles. I don't want to fan that fire, but having been a programmer for some 25 years now, I have adopted an indentation style that I believe strikes a fair compromise.

The reason people support tabs is because then they can change the indentation from 4 to 2, or from 2 to 3, or to whatever they like. The problem with tabs is that in a lot of cases, unless they have the same setting that the original programmer used, things go all whacky and nothing lines up.

The reason people support spaces over tabs is because it doesn't matter what the tab stops are set to, the code always looks the same. I was in this camp for a long time. The problem with spaces is that the person reading the code cannot easily change it to the way he likes it, and it makes for bigger files (though the latter argument is pretty weak in these days of terabyte hard drives).

Here's what I do. I use tabs to indent to the level that the code needs to be indented, and then I use spaces to line things up. Start with tabs, followed by lining up with spaces. An example would be this chunk-o-code:

 1 void foo(void)  2 {  3 int i;  4  5 for(i=0; i<12; i++)  6 {  7 printf("This is a very long line of stuff to print out, because I'm printing a variable: 0x%x\n",  8 some_struct[i].with.sub_elements;   9 }  10 } 

Here, lines 3, 5, 6, and 9 would have a single leading tab, because they are indented one level. Lines 7 and 8 would have two leading tabs, but line 8 would have 7 spaces following the two leading tabs. The spaces are there to line up the second argument to the printf with the opening parenthesis of the printf. If tabs were used for this, then the alignment would be dependent on the tab settings. Here's the same code again, but I'm representing tabs with \t and spaces with @ signs:

 1 void foo(void)  2 {  3 \tint i;  4  5 \tfor(i=0; i<12; i++)  6 \t{  7 \t\tprintf("This is a very long line of stuff to print out, because I'm printing a variable: 0x%x\n",  8 \t\t@@@@@@@some_struct[i].with.sub_elements;   9 \t}  10 } 

No matter what the tabs stops are set to, line 8 will always align the arguments of the printf as desired. In case anyone cares. The problem with adding any indentation approach (including this one) ito a book like this is that it tends to excite religious pogroms. Pogroms from programs so to speak. So I don't necessarily think this should be added to the chapter. I just like to put it out there.

--Jomegat (talk) 03:09, 27 March 2009 (UTC)

I'm not sure that the inability for a programmer to change the code indentation to the way he (or she) likes it is a reason to mix tabs and spaces. In-house styles are usually adopted so that code is easy to read and maintain. If a coder wants to change that to a personal preference that really is an issue s/he has to address. Tabs do not work. Try printing out code for review and prefixing each line with a line number, and see what happens to your tabbed code. Remember that editors that insert line numbers can separate the number from the code with a tab. Our company has forbidden the use of tabs unless the IDE is set to 4 spaces and 'insert spaces instead of tabs' is activated. This is not a whim. Far too much code was affected by tabs and experience has shown all coders abide by the rule because it works. Mickraus (talk) 18:15, 2 October 2009 (UTC)

Mixing tabs and spaces are acceptable within that context. The main issue is that IDEs form their own context on whether or not a tab should exist, and make it difficult to switch between the two; if you want to see an example where incorrect tabbing can prevent compilation or proper execution, see either Python or Whitespace. Also, if prefixing lines with line numbers messed up printing, then there's a problem with how you are adding line numbers. These line numbers should be located within the margin, and should not disrupt the tabbing within the program. --Sigma 7 (talk) 21:38, 2 October 2009 (UTC)

The notion of a margin does not exist when printing source code as plain text. My coders simply tick a box 'Display line numbers' then print out the file. I'm not sure I understand what you mean by "within that context". Within which context? Mickraus (talk) 22:49, 3 October 2009 (UTC)

If you're printing as plaintext, then you're using default margins as decided by the printer, print driver or operating system. If the editor you are using prepends line numbers without manually managing either margins or tabs, you code will experience indentation issues. My IDE handles it perfectly, regardless of tab size and inclusion of line numbers; there may still be a setting that needs to be applies before printing (or a filter you could use that auto-converts tabs into the correct number of spaces.)

The context I was referring to was the example that showed mixing tabs and spaces for a person's in-house style to align parameters within a multi-line function call. --Sigma 7 (talk) 23:35, 3 October 2009 (UTC)

Confusion about "Blank Lines"

Based on these two rules, there should now be at least two line breaks added. *After line 1, because line 1 has a preprocessor directive. *After line 5, because line 5 contains a variable declaration.

#include <stdio.h>  int main(void) {  int revenue = 80; int cost = 50;  int roi;  roi = (100 * (revenue - cost)) / cost; 

There's no blank line inserted after line 5. There's obviously some mistake here, but how should i insert a blank line, then? After line 6, as showed in the snippet, or after line 7, thus removing the blank line sitting there? Something more like this:

#include <stdio.h>  int main(void) {  int revenue = 80; int cost = 50; int roi;  roi = (100 * (revenue - cost)) / cost; 

Or maybe this..?

#include <stdio.h>  int main(void) {  int revenue = 80;  int cost = 50;  int roi;  roi = (100 * (revenue - cost)) / cost; 

The proposition with all three variables written in block seems to be the more lisible. OdysseusWiki (discuss • contribs) 07:31, 22 July 2023 (UTC)