View php code specifications from linuxkernelcodingstyle

Linux kernel encoding is an extreme situation. Developers around the world need to learn and modify code clearly and clearly, which requires a high quality of code. I believe that linus will become more grumpy after a long term of contact with various types of code. for example, some time ago in a forum, I had to kill C ++... Excerpt, remove not SyntaxHighlighter. all ();

Linux kernel encoding is an extreme situation.

Developers around the world need to learn and modify code clearly and clearly, which requires a high quality of code.

I believe that linus will become more grumpy after a long term of contact with various types of code. for example, some time ago in a forum, I had to kill C ++...

Excerpt to remove parts that are not suitable for PHP programmers.

If you develop the core code of the PHP program, such as the framework, you are advised to think carefully.

Although it conflicts with some authoritative code specifications such as discuz and zend, it can still benefit from it.

Linux kernel coding style (excerpt for PHPer)

Linux kernel coding style:

Chinese maintainer: Zhang Lezhang Le

Translator: Zhang Le

Wang Cong

Wheelz

Guan Xudong Guan

Li Zefan

Wang Chen

Chapter 1: Indent

The tab is 8 characters, so the indentation is also 8 characters. Some heristic movements attempt to change indentation to 4 (or even 2) characters, which is almost equivalent to trying to define the value of the circumference rate as 3.

Reason: the full meaning of indentation lies in clearly defining the starting and ending points of a control block. Especially after you stare at your screen for 20 hours, you will find that a large indentation makes it easier for you to distinguish indentation.

Now, some people complain that the 8-character indent will make the code move too far to the right, so it is difficult to read such code on the 80-character terminal screen. The answer to this question is, if you need more than three levels of indentation, no matter how you use your code to have problems, you should correct your program.

In a switch statement, the preferred way to eliminate multi-level indentation is to align the "switch" and its "case" labels to the same column, instead of "two indentations" and "case" labels. For example:

C ++ code

Switch (suffix ){

Case G:

Case g:

Mem <= 30;

Break;

Case M:

Case m:

Mem <= 20;

Break;

Case K:

Case k:

Mem <= 10;

/* Fall through */

Default:

Break;

}

Do not put multiple statements in one line unless you have something to hide:

C ++ code

If (condition) do_this;

Do_something_everytime;

Do not add multiple value assignment statements in a row. The kernel code style is super simple. It is to avoid expressions that may cause misunderstandings.

In addition to comments, documents, and Kconfig, do not use spaces for indentation. the previous example is an exception and is intended.

Select a good editor and do not leave spaces at the end of the line.

Chapter 2: break down long lines and strings

The significance of the code style lies in the use of common tools to maintain the readability and maintainability of the code.

The length of each row is limited to 80 columns. we strongly recommend that you follow this convention.

Statements longer than 80 columns need to be split into meaningful fragments. Each segment must be significantly shorter than the original statement, and the placement position is also obviously right-aligned. The same rule applies to function headers with a long parameter list. Long strings must also be split into short strings. The only exception is that more than 80 columns can greatly improve readability and do not hide information.

C ++ code

Void fun (int a, int B, int c)

{

If (condition)

Printk (KERN_WARNING "Warning this is a long"

"3 parameters a: % u B: % u"

"C: % u", a, B, c );

Else

Next_statement;

}

Chapter 3: placing braces and spaces

Another common problem in the C language style is the placement of braces. Unlike the indentation size, there are not many technical reasons to choose or discard a placement policy, but the preferred method is as shown in Kernighan and Ritchie, the starting braces are placed at the end of the line, and the ending braces are placed at the beginning of the line. therefore:

C ++ code

If (x is true ){

We do y

}

This applies to all non-function statement blocks (if, switch, for, while, do ). For example:

C ++ code

Switch (action ){

Case KOBJ_ADD:

Return "add ";

Case KOBJ_REMOVE:

Return "remove ";

Case KOBJ_CHANGE:

Return "change ";

Default:

Return NULL;

}

However, there is an exception, that is, the function: The starting braces of the function are placed at the beginning of the next line, so:

C ++ code

Int function (int x)

{

Body of function

}

The world may complain about this inconsistency ...... Er ...... Inconsistent, but all well-thinking people know that (a) K & R is _ correct _, and (B) K & R is correct. In addition, functions are special (in C, functions cannot be nested ).

Note that the ending braces occupy only one row, unless it is followed by the rest of the same statement, that is, the "while" or the "else" in the if statement in the do statement, as shown in the following code:

C ++ code

Do {

Body of do-loop

} While (condition );

And

C ++ code

If (x = y ){

..

} Else if (x> y ){

...

} Else {

....

}

Reason: K & R.

Note that this way of placing braces can also minimize the number of blank (or almost empty) rows without losing readability. Therefore, because the new lines on your screen are non-renewable resources (think about 25 rows of terminal screens), you will have more blank lines to place comments.

When there is only one separate statement, no unnecessary braces are added.

C ++ code

If (condition)

Action ();

This is not applicable to a separate statement that is a branch of a condition statement. In this case, braces must be used in both branches.

C ++ code

If (condition ){

Do_this ();

Do_that ();

} Else {

Otherwise ();

}

3.1: space

The space usage of Linux kernel depends on whether it is used for functions or keywords. (Most) add a space after the keyword. The notable exceptions are sizeof, typeof, alignof, and _ attribute __. these keywords look more like functions to some extent (they are often used with parentheses in Linux, although such parentheses are not required in C, they are like the "sizeof info" after "struct fileinfo info" is declared ").

Therefore, place a space after these keywords:

If, switch, case, for, do, while

However, do not place spaces after the keywords sizeof, typeof, alignof, or _ attribute. For example,

C ++ code

S = sizeof (struct file );

Do not add spaces on both sides of the expression in parentheses. This is a counterexample:

C ++ code

S = sizeof (struct file );

When declaring a pointer type or returning a pointer type function, the preferred method of "*" is to bring it closer to the variable name or function.

Rather than the type name. Example:

C ++ code

Char * linux_banner;

Unsigned long memparse (char * ptr, char ** retptr );

Char * match_strdup (substring_t * s );

Use a space on both sides of most binary and ternary operators, for example, all of the following operators:

C ++ code

= +-<> */% | & ^ <= >==! =? :

But do not add spaces after the unary operator:

C ++ code

& * + -~ ! Sizeof typeof alignof _ attribute _ defined

No space is added before the suffix auto-increment and auto-increment unary operators:

++ --

The prefix Auto-increment and auto-increment unary operators are not followed by spaces:

++ --

"." And "->" struct member operators are not preceded by spaces.

Do not leave blank spaces at the end of the row. Some editors that can be automatically indented will add a proper amount of white space at the beginning of the line of the new line, and then you can directly enter code in that line. However, if you didn't enter code in that line at last, some editors won't remove the added blank, just as you intentionally leave a blank line. A blank row at the end of the row is generated.

When git finds that the patch contains a blank line at the end of the line, it will warn you, and you can remove the line at your request. However, if you are applying a series of patches, this will cause subsequent patch failure because you have changed the patch context.

Chapter 4: naming

C is a simple language, so should you name it. Unlike Modula-2 and Pascal programmers, C programmers do not use gorgeous names like ThisVariableIsATemporaryCounter. C programmers call the variable "tmp", which is easier to write and at least not difficult to understand.

However, although case-insensitive names are not recommended, global variables still need a descriptive name. Calling a global function "foo" is an unforgivable error.

Global variables (only when you really need them) need a descriptive name, just like a global function. If you have a function that can calculate the number of active users, you should call it "count_active_users ()" or a similar name. you should not call it "cntuser ()".

The inclusion of function types in function names (the so-called Hungarian naming method) is a brain problem-the compiler knows those types and can check those types. this can only confuse programmers. No wonder Microsoft always creates problematic programs.

The local variable name should be short and can express relevant meanings. If you have some random integer cyclic counters, it should be called "I ". Calling it "loop_counter" is not helpful, if it is not possible to be misunderstood. Similarly, "tmp" can be used to call any type of temporary variables.

For example