diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 962207de..575808e1 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -1,101 +1,27 @@
-If you start a new file, you get to choose the style.
-If you change an existing file, follow the existing style.
+Most developers find Linux coding style easy to read, and there is
+really no reason to reinvent this practise, so procps-ng goes along
+with others.
 
-Hard tabs are OK, as long as you consider the tab stops to
-be every 8 characters. You can also use 2, 3, or 4 spaces.
-Tabs are kind of yucky, since cut-and-paste mangles them
-sometimes and they make "diff -Naurd old new" output less
-readable.
+http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/CodingStyle
 
-Spaces within a line don't matter much, and won't be
-considered part of the style. Just make it readable:
+In addtion to Linux coding style this project has few addtional
+wishes to contributors.
 
-if(x){            // OK
-if( x ){           // OK
-if (x) {            // OK
-if(x==y && a==b){     // OK
-if(x == y && a == b){ // poor
-if(x==y&&a==b){       // poor
+* Many small patches are favoured over one big. Break down is done on
+  basis of logical functionality; for example #endif mark ups,
+  compiler warning and exit codes fixes all should be individual
+  small patches.
 
-This is evil:
+* Use 'FIXME: ' in code comments, manual pages, autotools files,
+  scripts and so on to indicate something is wrong.  The reason we do
+  is as simple as being able to find easily where problem areas are.
 
-szWinStallman
-FoulCodingStyle (int iInsanity)
-  {
-     if (iInsanity)
-       {
-          GoHackEmacs () ;
-       }
-          else
-       {
-          SeekHelpForYourLisp () ;
-       }
-  }
+* In writing arithmetic comparisons, use "<" and "<=" rather than
+  ">" and ">=".  For some justification, read this:
+  http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
 
-
-Curly braces belong at the end of a line. If you must, go ahead
-and make function bodies an exception to that rule. (as Linus does)
-
-Big fprintf() calls and similar go like this:
-
-fprintf(fd, "%d %d %d %d %d %d\n",
-  sdfsdf_sdfsdf + sdfs_iii,     // not an example of good names!
-  iijjij,
-  kjfkkj_sdfssss_sfff,
-  sdflkjfdskj + sdf - sfds,
-  jksss,
-  sfssss + wwwwfwfw
-);
-
-Keep these distinct: NULL, '\0', 0, 0.0
-
-Command-line parsers need to be bomb-proof. It is not acceptable
-to crash due to a messed up command-line. For an option "-x" that
-takes an argument, accept both "-x arg" and "-xarg". Remember to
-support "--" and "--version".
-
-Be extremely careful when handling data from other users.
-For example, it is a security hole if /proc/123/cmdline can
-overflow an array. It is often a security hole if you allow
-non-ASCII characters to be printed. Assuming the console is
-not in UTF-8 mode, all of these are bad: "\b\e\f\n\r\t\v\x9b".
-(the "\x9b" is valid in UTF-8 mode, but equivalent to "\e["
-when not in UTF-8 mode -- which gives control of terminal
-settings) It's best if you consider user-supplied data to
-be unsafe, since this makes for less work in case the code
-ends up needing to run setuid. Termcap data is user-supplied.
-Except for the above security issues, don't bother to check
-for something you can't handle... like printf() failing.
-It is expected that /dev exists and so on.
-
-Remember that a read() may return early, with partial data
-or with -1 and errno set to EINTR. You then must try again.
-
-char:      may be signed or unsigned by default
-int:       always 32-bit
-long long: always 64-bit
-pointer:   either 32-bit or 64-bit
-long:      same size as a pointer
-KLONG:     same size as a pointer or long IN THE KERNEL
-
-Functions used in just one file must be marked static.
-Use the "const" and "restrict" keywords wherever you can.
-
-Put main() at the bottom of a file so you don't need all
-those ugly forward declarations.
-
-Avoid the strcat() function. It is slow. For some odd
-reason, snprintf() is faster than sprintf().
-
-Reuse memory allocations when you can. When using realloc(),
-do your increments by more than one. 25% is a nice amount.
-
-Avoid compile-time choices. They make documentation difficult,
-and they are not friendly to binary distribution.
-
-Write programs that can handle a million processes without
-getting hopelessly slow. Allow for /proc/123/cmdline to
-be at least 128 kB.
-
-The LGPL license is strongly preferred. This allows use of
-the code in the library.
+* Be nice to translators. Don't change translatable strings if you
+  can avoid it.  If you must rearrange individual lines (e.g., in
+  multi-line --help strings), extract and create new strings, rather
+  than extracting and moving into existing blocks.  This avoids
+  making unnecessary work for translators.