Declare a variable as locally as possible

Question

I am new to Linux kernel development.

One thing that bothers me is the way that variables are declared and initialized.

I got the impression that the code uses C89 / ANSI C variable declaration rules (variables are declared at the beginning of the block), and C99 relaxes the rule.

My background is C ++, and there are many tips from "very smart people" to declare a variable as locally as possible - it is better to declare and initialize in the same instruction:

• Google C ++ Style Guide
• C ++ Coding Standards: 101 Rules, Recommendations, and Best Practices - Clause 18
• Good discussion about this here .

What is an acceptable way to initialize variables in the Linux kernel?

Answer 1

I could not find the appropriate excerpt from the Linux kernel coding style . So, follow the standard used in existing code - declare variables at the beginning of the block, or risk making your code look out of place.

The reasons why variables at the beginning of a block is a good thing:

• target architecture may not have C99 compiler
• ... can't think of more reasons.

Answer 2

You should always try to declare variables as locally as possible. If you use C ++ or C99, it will usually be right before the first use.
In older C, this does not fall under the "possible", and there the place for declaring these variables will usually be the beginning of the current block.

(I say “usually” because of some cases with functions and loops, where it is better to make them more global ...)

Answer 3

In most normal cases, declare them at the beginning of the function in which you use them. There are exceptions, but they are rare.

if your function is short enough, the slowdown is far from the first use anyway. If your function is longer, then this is a good sign that your function is too long.

The reason many C ++ coding standards recommend declaring that they are close to use is because C ++ data types can be much "thicker" (for example, a class object with multiple inheritance, etc. ), and therefore take up much more space. If you define such an instance at the beginning of the function, but use it much later (and possibly not at all), you spend a lot of RAM. This is usually much less of a problem in C, and for it, only data types of the type.

Answer 4

There is an oblique link in the Coding Style document. It says:

Another measure of a function is the number of local variables. They should not exceed 5-10, or you are doing something wrong. Rethink the function and break it into smaller pieces. The human brain can usually easily track about 7 different things, something else and it gets confused. You know that you are brilliant, but you might like to understand what you did in 2 weeks.

Thus, while C99-style styles are in place, in some cases convenient, the first thing you should probably ask yourself is why it is hard for them to find everyone at the top of the function. This does not stop you from declaring material inside block markers, for example, for intranet computing.

Answer 5

In earlier C, you can declare them locally by creating a block inside a function. Blocks can be added even without ifs / for / while:

int foo(void) { int a; int b; .... a = 5 + b; { int c; .... } } 

Although it does not look very neat, it is still possible even in earlier versions of C.

Answer 6

I can’t say why they did one thing in the Linux kernel, but on the systems we are developing, we tend not to use C99-specific functions in the main code. In separate applications, as a rule, there are things written for C99, because they will usually be placed on one well-known platform, and the implementation of gcc C99 is well known.

But the core code must be deployed on any platform that the client requires (within reason). We supply systems on AIX, Solaris, Informix, Linux, Tru-64, OpenVMS (!), And the availability of C99-compatible compilers is not always guaranteed.

The Linux kernel should be significantly more portable - and especially to small embedded systems. I assume the function is simply not important to override these considerations.