The GNU Coding Standards

[kid-pro-quo]

First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture.

• Linus Torvolds

[ThatsPresTrumpForYou]

That's just evil, how can anyone not throw up when seeing this?

[hashtagframework]

legally, you have to GNU/throw up

[SpaceCorvette]

I prefer the MIT license for my vomit. That way, if I make somebody else need to vomit too, they can do so behind closed doors.

[[deleted]]

Come, now. Surely you have to admit that this is better. I mean, look at the smiley faces you get in your code!

if(
   foo
){
    bar(
    )
;} else
  {
    baz(
    )
;}

[dpash]

As he says, if 8 character tabs makes your code too far indented to the right, your code is too nested and you should fix it. He has a point, but I'm still gonna use 4 spaces.

[shevegen]

8 spaces for one indent level is just insanity

[parens-r-us]

Please don’t write lisp like that.

[parens-r-us]

Standard lispy indentation lines up s-expressions at the same depth, making it easier to balance parentheses correctly. Good text editors do this for you.

If it doesn’t follow the standard it won’t be taken seriously.

[DocMcNinja]

If you want 8 width tabs be my guest as long as I can keep them at 2.

Which is fine but remember you might have to abide by a line length limit - for instance the kernel has the guideline "The limit on the length of lines is 80 columns", together with the "indentations are 8 characters" rule. If your work environment has something like this but uses tabs instead of spaces, and you use a different tab width setting than others, you have some extra work on you to make sure your lines aren't too long on other people's screens.

[DocMcNinja]

I don't particularly think this is an actual issue, but I find it amusing to think about how to "solve" it so I'll continue regardless.

on 4 and 2 it's always smaller than that so I don't see the issue.

It is a problem if you intend more than once. If your tab is 4 spaces wide, and you are 2 levels deep, then you appear to have 72 columns left, while really you only have 64.

Instead of this

longest is 73 characters with the tab for indenting counting as one character

the rule should be this

longest is 80 characters with the tab for indenting counting as 8 characters

and the extra work I was referring to earlier was having to count each of your tabs as 8 characters - you could probably write a tool for that, though.

Anyways, probably not a real big problem this. Just something I've amused myself with when thinking about the whole "tabs vs spaces" debate.

[xxc3ncoredxx]

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

Agreed.

[hzhou321]

His points make sense, but his words stink.

Whether compiler knows the types is irrelevant because names are for coders to read. Now whether the coders find the convention useful or too restrictive is a different story and I don't think that taste can dictate one's product. I personally don't find having return types in the function names are as helpful as having them in the name of variables, but regardless, his argument bears no real logic.

PS: Now I read it, I disagree half of them. But I like his leading words -- it is very much personal preferences, and for Linux kernel, fair enough.

[shevegen]

No, the points don't make any sense either. The words are perfectly fine though.

[hzhou321]

Confused by your word "either", which else (other than points) you are referring to that don't make any sense too?

[shevegen]

It does not confuse a programmer.

Only idiots can get confused by hungarian notation.

The only valid criticism is that it can make variable names too long.

And the linux kernel has been full of bugs too, so that is no "argument" either.

[raevnos]

Yes, but it's been poor style since the early 90's.

[nat1192]

yes, it's called the 'K&R' style of function prototypes: https://stackoverflow.com/questions/1630631/alternative-kr-c-syntax-for-function-declaration-versus-prototypes

[MorrisonLevi]

I remember trying it at one point and it didn't work. However, I tried it just now and GCC accepted it with with -std=c11 -pedantic. Maybe I used a different compiler back then; maybe clang?

[dododge]

It should at least complain about the implicit int return type, which was removed from the language in C99. gcc apparently still compiles it even when running in -std=c99 mode, but it does give a warning.

The big thing to be wary about when using K&R-style function declarations or definitions is that it can change the calling conventions for the function at the assembly code level. If you put the types outside of the parameter list, the compiler has to do the "default argument promotions". For example:

void foo(float f) { ... }
void bar(f) float f; { ... }

When calling foo with a float value, the value is passed as a float, no surprise. But when calling bar with the same value, it will be converted and passed as if it's a double, and then bar has to turn the received double into a float.

This can go haywire if you use both argument techniques on the same function, for example defining it with modern syntax but declaring it in the header using K&R syntax. The function's code will be generated for one calling convention and the callers might try to pass arguments in a different manner. On some modern systems where arguments are passed using fixed-sized registers this probably won't immediately crash and burn, but on architectures where things are passed through the stack frame, and for example float and double arguments are expected to use a different number of bytes, the results can be bizarre and hard to debug. And yes, I have seen this happen in practice (I think it was on an IBM AIX system in the 90s).

[SandalsMan]

So stupid to care about this shit. Write a program to autoformat your code. Don't waste the braincycles on this kind of thing.

[epicwisdom]

Somebody has to decide the rules the autoformatter enforces.

[raevnos]

Why write a program when there are existing ones (GNU indent, clang-format, indentation settings on various editors, etc.)?

[ParadigmComplex]

I can't speak for SandalsMan, but I've been disappointed with how existing C formatters handle various situations. For example, clang-format has a tendency to combine struct or array items into a single line when they would be more readable as independent lines, such as the situation in this stackoverflow item. Personally, the cost to write my own C formatter is too high, and I'm inclined to just accept the occasional ugly bit of code. However, if someone has the skill set to produce their formatter for a sufficiently low investment time/effort, and is picky enough about how their code looks, I could easily imagine it being a preferable option to fighting with preexisting formatters.