Development Team/Coding Standards/new - Revision history

Admin at 14:17, 16 July 2010

Admin — Fri, 16 Jul 2010 14:17:42 GMT

← Older revision		Revision as of 14:17, 16 July 2010
Line 87:		Line 87:
	Another measure of the function is the number of local variables. They shouldn't exceed 5-10, or you're doing something wrong. Re-think the function, and split it into smaller pieces. A human brain can generally easily keep track of about 7 different things,		Another measure of the function is the number of local variables. They shouldn't exceed 5-10, or you're doing something wrong. Re-think the function, and split it into smaller pieces. A human brain can generally easily keep track of about 7 different things,
	anything more and it gets confused. You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.		anything more and it gets confused. You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.
		+
		+	== Commenting ==
		+
		+	C-style comments only.
		+
		+	Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the ''working'' is obvious, and it's a waste of time to explain badly written code.
		+
		+	Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to section 4 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it.

Admin at 14:14, 16 July 2010

Admin — Fri, 16 Jul 2010 14:14:51 GMT

← Older revision		Revision as of 14:14, 16 July 2010
Line 76:		Line 76:

	If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See next section.		If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See next section.
		+
		+	== Functions ==
		+
		+	Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80×24, as we all know), and do one thing and do that well.
		+
		+	The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's ok to have a longer function.
		+
		+	However, if you have a complex function, and you suspect that a less-than-gifted first year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance critical, and it will probably do a better job of it that you would have done).
		+
		+	Another measure of the function is the number of local variables. They shouldn't exceed 5-10, or you're doing something wrong. Re-think the function, and split it into smaller pieces. A human brain can generally easily keep track of about 7 different things,
		+	anything more and it gets confused. You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.

Admin: /* Naming */

Admin — Fri, 16 Jul 2010 14:12:35 GMT

Naming

← Older revision		Revision as of 14:12, 16 July 2010
Line 65:		Line 65:
	== Naming ==		== 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 <code>ThisVariableIsATemporaryCounter</code>. A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand.	+	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 <code>ThisVariableIsATemporaryCounter</code>. A C programmer would call that variable <code>tmp</code>, 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 <code>foo</code> is a shooting offense.		''However'', while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function <code>foo</code> is a shooting offense.

Admin at 14:12, 16 July 2010

Admin — Fri, 16 Jul 2010 14:12:01 GMT

← Older revision		Revision as of 14:12, 16 July 2010
Line 14:		Line 14:
	* Never use C++ style // single line comments.		* Never use C++ style // single line comments.

-	== ~~Code lay-out~~ ==	+	== Indentation ==

-	* Tabs, tabs, ONLY tabs. Use ~~a single~~ tab for each level of indentation.	+	Tabs, tabs, ONLY tabs. Use one tab for each level of indentation. Spaces should ONLY be used for alignment, not indentation.

-	* No line should be longer than 80 characters~~. If this~~ and ~~the previous rule together don't give you enough room to code (e~~.~~g., most of us have our editors configured~~ to ~~render one tab as four spaces~~), ~~your code~~ is ~~too complicated -- consider using subroutines~~.	+	Preference: Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

-	* No line should end in whitespace. If you ~~think you need significant trailing whitespace~~, ~~think again -- somebody~~'~~s editor might delete~~ it as a ~~matter of routine~~.	+	Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.

-	* Function definition style: function name in column 1, ~~outermost curly braces in column 1~~, ~~blank line after local variable declerations~~. ~~For example:~~	+	Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

-	~~<c>~~	+	In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.
-	~~static void~~	+
-	~~engine_set_events(struct Socket *sock~~, ~~unsigned new_events)~~	+
-	{	+
-	~~struct epoll_event evt;~~	+

-	~~assert(0 !~~= ~~sock);~~	+	== Braces ==
-	~~set_events(sock~~, ~~s_state(sock)~~, ~~new_events~~, ~~&evt~~);	+
-	~~...~~	+	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:
		+
		+	<c>if (x is true) {
		+	we do y
	}</c>		}</c>

-	* Code structure: one ~~space between keywords like 'if'~~, ~~'for' and~~ the ~~following left paren; no spaces inside~~ the ~~paren; braces as shown~~:	+	However, there is one special case, namely functions: they have the opening brace at the beginning of the next line, thus:

-	<c>if (~~mro != NULL~~) {	+	<c> int function(int x)
-	~~...~~	+	{
-	}	+	body of function
-	~~else~~ {	+
-	~~...~~	+
	}</c>		}</c>

-	* The return statement should ''not'' ~~get redundant parentheses:~~	+	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).
		+
		+	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, i.e. a "while" in a do-statement or an "else" in an if-statement, like this:
		+
		+	<c>do {
		+	body of do-loop
		+	} while (condition);</c>
		+
		+	and
		+
		+	<c>if (x == y) {
		+	..
		+	} else if (x > y) {
		+	...
		+	} else {
		+	....
		+	}</c>
		+
		+	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 (think 25-line terminal screens here), you have more empty lines to put comments on.
		+
		+	== 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 <code>ThisVariableIsATemporaryCounter</code>. 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 <code>foo</code> 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 <code>count_active_users()</code> or similar, you should ''not'' call it <code>cntusr()</code>.

-	~~<c>return result; /* correct */~~	+	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. No wonder Microsoft makes buggy programs.
-	~~return~~ (~~result~~)~~; /* incorrect */</c>~~	+

-	* Function and ~~macro call style: foo(a, b, c) -- no space before~~ the ~~open paren~~, ~~no spaces inside the parens~~, no ~~spaces before commas~~, ~~one space after each comma~~.	+	''Local'' variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called <code>i</code>. Calling it <code>loop_counter</code> is counterproductive, if there is no chance of it being mis-understood. Similarly, <code>tmp</code> can be just about any type of variable that is used to hold a temporary value.

-	* Always put spaces around assignment, ~~Boolean and comparison operators. In expressions using a lot of operators~~, ~~add spaces around~~ the ~~outermost (lowest~~-~~priority) operators~~.	+	If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See next section.

Admin: /* Code lay-out */

Admin — Thu, 10 Jun 2010 11:50:04 GMT

Code lay-out

← Older revision		Revision as of 11:50, 10 June 2010
Line 20:		Line 20:
	* No line should be longer than 80 characters. If this and the previous rule together don't give you enough room to code (e.g., most of us have our editors configured to render one tab as four spaces), your code is too complicated -- consider using subroutines.		* No line should be longer than 80 characters. If this and the previous rule together don't give you enough room to code (e.g., most of us have our editors configured to render one tab as four spaces), your code is too complicated -- consider using subroutines.

-	* No line should end in whitespace. If you think you need significant trailing whitespace, ~~thing~~ again -- somebody's editor might delete it as a matter of routine.	+	* No line should end in whitespace. If you think you need significant trailing whitespace, think again -- somebody's editor might delete it as a matter of routine.

	* Function definition style: function name in column 1, outermost curly braces in column 1, blank line after local variable declerations. For example:		* Function definition style: function name in column 1, outermost curly braces in column 1, blank line after local variable declerations. For example:

Admin at 11:48, 10 June 2010

Admin — Thu, 10 Jun 2010 11:48:44 GMT

Show changes

Admin: /* Structure fields */ correct typo

Admin — Tue, 11 May 2010 08:35:27 GMT

Structure fields: correct typo

← Older revision		Revision as of 08:35, 11 May 2010
Line 107:		Line 107:
	=== Structure fields ===		=== Structure fields ===

-	Declare each field of a structure on a line by itself. Take time to think about the order of the fields. Try to keep related fields grouped. Within groups of related fields, try and pick some uniform scheme for organizing them (e.g., alphabetically or by frequency of use). When all other considerations are ~~equals~~, place larger fields first, as C's alignment rules may then permit the compiler to save space by not introducing "holes" in the structure layout.	+	Declare each field of a structure on a line by itself. Take time to think about the order of the fields. Try to keep related fields grouped. Within groups of related fields, try and pick some uniform scheme for organizing them (e.g., alphabetically or by frequency of use). When all other considerations are equal, place larger fields first, as C's alignment rules may then permit the compiler to save space by not introducing "holes" in the structure layout.

Admin: /* Declarations and Types */

Admin — Tue, 11 May 2010 08:34:51 GMT

Declarations and Types

← Older revision		Revision as of 08:34, 11 May 2010
Line 90:		Line 90:

	but cannot access the contents of Foo. In addition, the user cannot declare a plain (non pointer) Foo, and so is forced to go through whatever allocation routines you provide. We encourage this modularity technique.		but cannot access the contents of Foo. In addition, the user cannot declare a plain (non pointer) Foo, and so is forced to go through whatever allocation routines you provide. We encourage this modularity technique.
		+
		+	Don't mix declarations with type definitions; i.e., don't do:
		+
		+	<c>struct Foo {
		+	int x;
		+	} object;
		+
		+	or
		+
		+	typedef struct {
		+	int x;
		+	} type;</c>
		+
		+	All typedefs should stand out by themselves.
		+
		+	=== Structure fields ===
		+
		+	Declare each field of a structure on a line by itself. Take time to think about the order of the fields. Try to keep related fields grouped. Within groups of related fields, try and pick some uniform scheme for organizing them (e.g., alphabetically or by frequency of use). When all other considerations are equals, place larger fields first, as C's alignment rules may then permit the compiler to save space by not introducing "holes" in the structure layout.

Admin: /* Declarations and Types */ correct typo

Admin — Tue, 11 May 2010 08:26:26 GMT

Declarations and Types: correct typo

← Older revision		Revision as of 08:26, 11 May 2010
Line 85:		Line 85:
	struct Foo { .. };</c>		struct Foo { .. };</c>

-	Then a user of <code>header.h</c> can declare:	+	Then a user of <code>header.h</code> can declare:

	<c>Foo *foo;</c>		<c>Foo *foo;</c>

	but cannot access the contents of Foo. In addition, the user cannot declare a plain (non pointer) Foo, and so is forced to go through whatever allocation routines you provide. We encourage this modularity technique.		but cannot access the contents of Foo. In addition, the user cannot declare a plain (non pointer) Foo, and so is forced to go through whatever allocation routines you provide. We encourage this modularity technique.

Admin: /* Declarations and Types */

Admin — Tue, 11 May 2010 08:25:52 GMT

Declarations and Types

← Older revision		Revision as of 08:25, 11 May 2010
Line 72:		Line 72:
	Foo *foo;		Foo *foo;
	};</c>		};</c>
		+
		+	This gives a particularly nice scheme of exporting opaque objects in header files.
		+
		+	In <code>header.h</code>:
		+
		+	<c>typedef struct Foo Foo;</c>
		+
		+	In <code>source.c</code>:
		+
		+	<c>#include "header.h"
		+
		+	struct Foo { .. };</c>
		+
		+	Then a user of <code>header.h</c> can declare:
		+
		+	<c>Foo *foo;</c>
		+
		+	but cannot access the contents of Foo. In addition, the user cannot declare a plain (non pointer) Foo, and so is forced to go through whatever allocation routines you provide. We encourage this modularity technique.