Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Letzte Überarbeitung Beide Seiten der Revision
private:codingstyle [2013/04/19 00:05]
Patrick Wacker first statements taken place 		private:codingstyle [2013/04/19 13:27]
Patrick Wacker weitere überarbeitung
Zeile 12: Zeile 12:
 ====== Coding Style ====== ====== Coding Style ======
  
-==== Indroduction ​====+==== Introduction ​====
  
-This documents ​discribes ​the coding style I prefer in the most cases+This documents ​describes ​the coding style I prefer in the most cases
 and most other situations as well. and most other situations as well.
  
Zeile 22: Zeile 22:
 === Editing this document === === Editing this document ===
  
-The text for this docuemnt ​is written with the syntax that dokuwiki supports.+The text for this document ​is written with the syntax that dokuwiki supports.
 See https://​www.dokuwiki.org for more details. See https://​www.dokuwiki.org for more details.
  
-But this document should be easy readable as plain text as well. So do not+But this document should be easily ​readable as plain text as well. So do not
 use any fancy looking html outputs. use any fancy looking html outputs.
  
Zeile 36: Zeile 36:
 </​code>​ </​code>​
  
-each code expample ​must be intented ​with a tabulator! (not spaces!) +each code example ​must be indented ​with a tabulator! (not spaces!)\\  
-[This is automaticaly ​displayed as code examples!]+[This is automatically ​displayed as code examples!] 
  
  
Zeile 43: Zeile 44:
  
  
---------------------------------------------------------------------------+----- 
  
  
Zeile 49: Zeile 49:
 ===== Coding style ===== ===== Coding style =====
  
-This documents ​discripes ​the coding style I prefer. Coding style is very +This documents ​describes ​the coding style I prefer. Coding style is very 
-personal, and I won't force my views on onybody, but this is what goes for+personal, and I won't force my views on anybody, but this is what goes for
 anything that I have to be able to maintain, and I'd prefer it for most anything that I have to be able to maintain, and I'd prefer it for most
 other things too. other things too.
  
 Please at least consider the points made here. Please at least consider the points made here.
- 
-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. 
- 
-Anyway, here goes: 
  
  
Zeile 106: Zeile 101:
 something to hide: something to hide:
  
- if (condition) do_this; + if (condition) do_this; 
-   ​do_something_everytime;​+   ​do_something_everytime;​
  
-Don't put multiple assignments on a single line either. ​ ​Kernel coding style +Don't put multiple assignments on a single line either. Avoid  
-is super simple.  ​Avoid tricky expressions.+tricky expressions.
  
-Outside of comments, documentation ​and except in Kconfig, spaces are never +Outside of comments ​and documentation,​ spaces are never used for 
-used for indentation,​ and the above example is deliberately broken.+indentation,​ and the above example is deliberately broken.
  
 Get a decent editor and don't leave whitespace at the end of lines. Get a decent editor and don't leave whitespace at the end of lines.
Zeile 121: Zeile 116:
  
  
 +==== Breaking long lines and strings ====
  
 +Coding style is all about readability and maintainability using commonly
 +available tools.
  
 +The limit on the length of lines is 80 columns but this is not a strong
 +limit.
  
 +Statements longer than 80 columns should be broken into sensible chunks.
 +Descendants are always substantially shorter than the parent and are placed
 +aligned to the opening brace of the previous line. The same applies to 
 +function headers with a long argument list. Long strings are as well broken
 +into shorter strings. The exception to this is where exceeding 80 columns
 +significantly increases readability and does not hide information.
  
 + void fun(int a, int b, int c)
 + {
 + if (condition)
 + qWarning("​This is a long Warning message with 3 "
 + "​parameters a: %u b: %u and c: %u",
 + a, b, c);
 + else
 + next_statement;​
 + }
  
 +
  
  
 +==== Placing Braces and Spaces ====
  
 +The other issue that always comes up in C styling is the placement of
 +braces. Unlike the indent size, there are few technical reasons to
 +choose one placement strategy over the other, but the preferred way, as
 +shown to us by the prophets Kernighan and Ritchie, is to put the opening
 +brace last on the line, and put the closing brace first, thusly:
  
 + if (x is true) {
 + we do y
 + }
  
 +This applies to all non-function statement blocks (if, switch, for,
 +while, do).  E.g.:
 +
 + switch (action) {
 + case ADD:
 + return "​add";​
 + case REMOVE:
 + return "​remove";​
 + case CHANGE:
 + return "​change";​
 + default:
 + return NULL;
 + }
 +
 +However, there is one special case, namely functions: they have the
 +opening brace at the beginning of the next line, thus:
 +
 + int function(int x)
 + {
 + body of function
 + }
 +
 +Heretic people all over the world have claimed that this inconsistency
 +is ...  well ...  inconsistent,​ but all right-thinking people know that
 +(a) K&R are __right__ and (b) K&R are right. Besides, functions are
 +special anyway (you can't nest them in C/C++).
 +
 +Note that the closing brace is empty on a line of its own, __except__ in
 +the cases where it is followed by a continuation of the same statement,
 +ie a "​while"​ in a do-statement or an "​else"​ in an if-statement,​ like
 +this:
 +
 + do {
 + body of do-loop
 + } while (condition);​
 +
 +and
 +
 + if (x == y) {
 + ..
 + } else if (x > y) {
 + ...
 + } else {
 + ....
 + }
 +
 +Rationale: K&R.
 +
 +Also, note that this brace-placement also minimizes the number of empty
 +(or almost empty) lines, without any loss of readability. Thus, as the
 +supply of new-lines on your screen is not a renewable resource, you have
 +more empty lines to put comments on.
 +
 +Do not unnecessarily use braces where a single statement will do.
 +
 + if (condition)
 + action();
 +
 +and
 +
 + if (condition)
 + do_this();​
 + else
 + do_that();​
 +
 +This does not apply if one branch of a conditional statement is not a 
 +single statement. Use braces in both branches.
 +
 + if (condition) {
 + do_this();​
 + do_that();​
 + } else {
 + otherwise();​
 + }
 +
 +
 +=== Spaces ===
 +
 +Use of spaces depends (mostly) on function-versus-keyword usage. Use a space
 +after (most) keywords. The notable exceptions are sizeof, typeof, alignof, ​
 +and __attribute__,​ which look somewhat like functions (and are usually used
 +with parentheses in Linux, although they are not required in the language, ​
 +as in: "​sizeof info" after "​struct fileinfo info;" is declared).
 +
 +So use a space after these keywords:
 +
 + if, switch, case, for, do, while
 +
 +but not with sizeof, typeof, alignof. E.g.:
 +
 + s = sizeof(struct file);
 +
 +Do not add spaces around (inside) parenthesized expressions.
 +This example is **bad**:
 +
 + s = sizeof( struct file );
 +
 +When declaring pointer data or a function that returns a pointer type, the
 +preferred use of '​*'​ is adjacent to the data name or function name and not
 +adjacent to the type name. Examples:
 +
 + char *banner;
 + unsigned long long memparse(char *ptr, char **retptr);
 + char *match_strdup(substring_t *s);
 +
 +Use one space around (on each side of) most binary and ternary operators,
 +such as any of these:
 + =  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :
 +
 +but no space after unary operators:
 + & ​ *  +  -  ~  !  sizeof ​ typeof ​ alignof ​ defined
 +
 +no space before the postfix increment & decrement unary operators:
 + ++  --
 +
 +no space after the prefix increment & decrement unary operators:
 + ++  --
 +
 +and no space around the '​.'​ and "​->"​ structure member operators.
 +
 +Do not leave trailing whitespace at the ends of lines. Some editors with
 +"​smart"​ indentation will insert whitespace at the beginning of new lines as
 +appropriate,​ so you can start typing the next line of code right away.
 +However, some such editors do not remove the whitespace if you end up not
 +putting a line of code there, such as if you leave a blank line. As a result,
 +you end up with lines containing trailing whitespace.
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +--------------------------------------------------------------------------+-----
  
  

Zuletzt angesehen:

Projektwerkzeuge