This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Libxenlight Coding Style

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Libxenlight Coding Style
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Mon, 4 Apr 2011 15:05:32 +0100
Delivery-date: Mon, 04 Apr 2011 07:06:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
We posted a draft coding style document in September but failed to
actually commit it :-/.  I have now done so.

The most relevant thing is the line length.  Lines are supposed to be
no more than 75-80 characters long.  We've been seeing lots of new
patches coming in with long lines.

Longer lines make patches harder to review in an 80-column MUA as well
as making the code harder to read in an 80-column source editor.

Lots of libxl is unfortunately already full of long lines; we will
deal with this at some later point, or if it bothers anyone now, _pure
formatting_ patches to fix it will be accepted right away.

In the meantime patches which introduce new long lines will be
bounced, or perhaps - if I'm feeling generous :-) - fixed up.

Thanks for your attention,

# HG changeset patch
# User Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
# Date 1301925286 -3600
# Node ID 9fcfa0ca31419e7988804863694a13977906f65f
# Parent  777aaa2172c8cccffb31e59fcf43aa35e1727cf1
libxl: add CODING_STYLE

libxenlight and xl grew enough to need a CODING_STYLE, that I blatantly
copied from qemu and linux, just adding few specific modifications.
The result should be as less controversial as possible, mostly
documenting what we are already doing.

[ Message and document originally posted to xen-devel on 2010-09-01 ]

Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

diff -r 777aaa2172c8 -r 9fcfa0ca3141 tools/libxl/CODING_STYLE
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/CODING_STYLE  Mon Apr 04 14:54:46 2011 +0100
@@ -0,0 +1,135 @@
+Libxenlight Coding Style
+Blatantly copied from qemu and linux with few modifications.
+1. Whitespace
+Of course, the most important aspect in any coding style is whitespace.
+Crusty old coders who have trouble spotting the glasses on their noses
+can tell the difference between a tab and eight spaces from a distance
+of approximately fifteen parsecs.  Many a flamewar have been fought and
+lost on this issue.
+Libxenlight indents are four spaces.  Tabs are never used, except in
+Makefiles where they have been irreversibly coded into the syntax.
+Spaces of course are superior to tabs because:
+ - You have just one way to specify whitespace, not two.  Ambiguity breeds
+   mistakes.
+ - The confusion surrounding 'use tabs to indent, spaces to justify' is gone.
+ - Tab indents push your code to the right, making your screen seriously
+   unbalanced.
+ - Tabs will be rendered incorrectly on editors who are misconfigured not
+   to use tab stops of eight positions.
+ - Tabs are rendered badly in patches, causing off-by-one errors in almost
+   every line.
+ - It is the libxenlight coding style.
+Do not leave whitespace dangling off the ends of lines.
+2. Line width
+Lines are limited to 75-80 characters.
+ - Some people like to tile their 24" screens with a 6x4 matrix of 80x24
+   xterms and use vi in all of them.  The best way to punish them is to
+   let them keep doing it.
+ - Code and especially patches is much more readable if limited to a sane
+   line length.  Eighty is traditional.
+ - It is the libxenlight coding style.
+3. Naming
+C is a Spartan language, and so should your naming be.  Unlike Modula-2
+and Pascal programmers, C programmers do not use cute names like
+ThisVariableIsATemporaryCounter.  A C programmer would call that
+variable "tmp", which is much easier to write, and not the least more
+difficult to understand.
+HOWEVER, while mixed-case names are frowned upon, descriptive names for
+global variables are a must.  To call a global function "foo" is a
+shooting offense.
+GLOBAL variables (to be used only if you _really_ need them) need to
+have descriptive names, as do global functions.  If you have a function
+that counts the number of active users, you should call that
+"count_active_users()" or similar, you should _not_ call it "cntusr()".
+Encoding the type of a function into the name (so-called Hungarian
+notation) is brain damaged - the compiler knows the types anyway and can
+check those, and it only confuses the programmer.
+LOCAL variable names should be short, and to the point.  If you have
+some random integer loop counter, it should probably be called "i".
+Calling it "loop_counter" is non-productive, if there is no chance of it
+being mis-understood.  Similarly, "tmp" can be just about any type of
+variable that is used to hold a temporary value.
+Local variables used to store return values should have descriptive name
+like "rc" or "ret". Following the same reasoning the label used as exit
+path should be called "out" or "error".
+Variables, type names and function names are
+Type names and function names use the prefix libxl__ when internal to
+libxenlight and libxl_ when exported in libxl.h.
+Xl should avoid using libxl_ and libxl__ as prefix for its own function
+When wrapping standard library functions, use the prefix libxl_ to alert
+readers that they are seeing a wrapped version; otherwise avoid this prefix.
+Typedefs are used to eliminate the redundant 'struct' keyword.
+It is the libxenlight coding style.
+4. Statements
+Don't put multiple statements on a single line.
+Don't put multiple assignments on a single line either.
+Error code paths with an if statement and a goto or a return on the same
+line are allowed. Examples:
+    if (rc) goto out;
+    if (rc < 0) return;
+Libxenlight coding style is super simple.  Avoid tricky expressions.
+5. Block structure
+Every indented statement is braced apart from blocks that contain just
+one statement.
+The opening brace is on the line that contains the control flow
+statement that introduces the new block; the closing brace is on the
+same line as the else keyword, or on a line by itself if there is no
+else keyword.  Examples:
+    if (a == 5) {
+        printf("a was 5.\n");
+    } else if (a == 6) {
+        printf("a was 6.\n");
+    } else {
+        printf("a was something else entirely.\n");
+    }
+    if (a == 5)
+        printf("a was 5.\n");
+An exception is the opening brace for a function; for reasons of tradition
+and clarity it comes on a line by itself:
+    void a_function(void)
+    {
+        do_something();
+    }
+Rationale: a consistent (except for functions...) bracing style reduces
+ambiguity and avoids needless churn when lines are added or removed.
+Furthermore, it is the libxenlight coding style.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Libxenlight Coding Style, Ian Jackson <=