login
Search
"Is it your argument that consistent coding style is bad? That argument has been settled long ago with the creation of Documentation/CodingStyle. All kernel code is supposed to follow that style, unless the resulting line of code looks clearly _wrong_. Your arguments seem to center around ''hey, my way it looks similarly good so i'll do that instead because i'm the maintainer'' - and that argument does not fly. CodingStyle is definitely not gospel and common sense should be applied, but _arbitrarily_ and _intentionally_ deviating from it is considered bad manners and hurts Linux as a whole."
Two-dimensional indentation
For complicated expressions, I like to use an indentation style which gives a two-dimensional layout, e.g.
!defined($best_result) || !defined($providing->{"op"}) || $providing->{"op"} eq "=" && ( defined($providing->{"version"}) && !defined($best_version) || compare_rpm_versions ( $providing->{"version"}, $best_version ) > 0 )This makes the structure clearer.
Coding style for better automated source text processing
I absolutely detest having
I absolutely detest having if/while/for and the opening brace on the same line.. breaking the line after the return type and the function body sucks as well :-)
The BSDs do this to the extreme and even leave an empty line between the brace and the first statement, for example (sys/kern/vfs_bio.c)
static __inline
void
bd_speedup(void)
{
bd_wakeup(1);
}
That indeed is ugly I can
That indeed is ugly
I can understand static __inline in one line
but splitting
void
bd_speedup(void)
to two lines SUCKS
Practical
I hated having the return type and function name on two lines, but once you get used to it it's pretty nice. You just have to get over the aesthetic barrier ;-) Now I think it looks good, and it's also much easier to grep for function names.
I don't know what the deal with splitting static __inline void bd_speedup (void) on three lines, though *shrugs*
I could venture a guess
With static __inline on its own line, it becomes easier to comment out, particularly if you use a C++ style // comment. This can become important when you want to debug something that's normally inlined and/or its name is not exported. (Or, at least, rule the function out of suspicion.)
An alternative approach, of course, is to wrap these in a macro and modulate that, but then that modulates all occurrences of "static inline" in a given translation unit.
That said, I'm not a big fan of the style. I like to be able to yoink all my prototypes into the header and have the columns line up. And the way I usually do that is to read the C file in and delete the function bodies (and sometimes the argument names). I end up with headers that look like this one or this one.
--
Program Intellivision and play Space Patrol!
Well, you are wrong. It
Well, you are wrong. It allows you to _easly_ grep sources for '^bd_speedup' and find body of this function.
BSD KNF style
The BSD KNF style is pretty nice.
http://en.wikipedia.org/wiki/Indent_style#BSD_KNF_style
Everyone should follow the kernel style though, and not use their own style. To keep it from becoming a mess.
Absolutely
It's pretty close to my personal coding style (I use 3-space indentation and a space separating function names from the argument list).
Absolutely, even though I think their coding style is sort of ugly. There are worse, however (GNU anyone?). The point is that everyone should use the coding style used in the project they're contributing to. How "nice" it would be if everyone where allowed to use their own personal style ;-)