C99 mixed declarations and code in open source projects?

Why is still C99 mixed declarations and code not us开发者_如何学Ced in open source C projects like the Linux kernel or GNOME?

I really like mixed declarations and code since it makes the code more readable and prevents hard to see bugs by restricting the scope of the variables to the narrowest possible. This is recommended by Google for C++.

For example, Linux requires at least GCC 3.2 and GCC 3.1 has support for C99 mixed declarations and code

You don't need mixed declaration and code to limit scope. You can do:

{
  int c;
  c = 1;
  {
    int d = c + 1;
  }
}

in C89. As for why these projects haven't used mixed declarations (assuming this is true), it's most likely a case of "If it ain't broke don't fix it."

This is an old question but I'm going to suggest that inertia is the reason that most of these projects still use ANSI C declarations rules.

However there are a number of other possibilities, ranging from valid to ridiculous:

• Portability. Many open source projects work under the assumption that pedantic ANSI C is the most portable way to write software.

• Age. Many of these projects predate the C99 spec and the authors may prefer a consistent coding style.

• Ignorance. The programmers submitting predate C99 and are unaware of the benefits of mixed declarations and code. (Alternate interpretation: Developers are fully aware of the potential tradeoffs and decide that mixed declarations and statements are not worth the effort. I highly disagree, but it's rare that two programmers will agree on anything.)

• FUD. Programmers view mixed declarations and code as a "C++ism" and dislike it for that reason.

There is little reason to rewrite the Linux kernel to make cosmetic changes that offer no performance gains.

If the code base is working, so why change it for cosmetic reasons?

There is no benefit. Declaring all variables at the beginning of the function (pascal like) is much more clear, in C89 you can also declare variables at the beginning of each scope (inside loops example) which is both practical and concise.

I don't remember any interdictions against this in the style guide for kernel code. However, it does say that functions should be as small as possible, and only do one thing. This would explain why a mixture of declarations and code is rare.

In a small function, declaring variables at the start of scope acts as a sort of Introit, telling you something about what's coming soon after. In this case the movement of the variable declaration is so limited that it would likely either have no effect, or serve to hide some information about the functionality by pushing the barker into the crowd, so to speak. There is a reason that the arrival of a king was declared before he entered a room.

OTOH, a function which must mix variables and code to be readable is probably too big. This is one of the signs (along with too-nested blocks, inline comments and other things) that some sections of a function need to be abstracted into separate functions (and declared static, so the optimizer can inline them).

Another reason to keep declarations at the beginning of the functions: should you need to reorder the execution of statements in the code, you may move a variable out of its scope without realizing it, since the scope of a variable declared in the middle of code is not evident in the indentation (unless you use a block to show the scope). This is easily fixed, so it's just an annoyance, but new code often undergoes this kind of transformation, and annoyance can be cumulative.

And another reason: you might be tempted to declare a variable to take the error return code from a function, like so:

void_func();
int ret = func_may_fail();
if (ret) { handle_fail(ret) }

Perfectly reasonable thing to do. But:

void_func();
int ret = func_may_fail();
if (ret) { handle_fail(ret) }
....
int ret = another_func_may_fail();
if (ret) { handle_other_fail(ret); }

Ooops! ret is defined twice. "So? Remove the second declaration." you say. But this makes the code asymmetric, and you end up with more refactoring limitations.

Of course, I mix declarations and code myself; no reason to be dogmatic about it (or else your karma may run over your dogma :-). But you should know what the concomitant problems are.

Maybe it's not needed, maybe the separation is good? I do it in C++, which has this feature as well.

There is no reason to change the code away like this, and C99 is still not widely supported by compilers. It is mostly about portability.