Update style guide.

CodingStyleGuide.txt

@@ -1,12 +1,44 @@
-Coding Style Guide
-==================
+QuakeForge Coding Style
+~~~~~~~~~~~~~~~~~~~~~~~
+
+You /WILL/ indent with hard tabs, or you will be harmed. :) You can format for
+whatever tab spacing you like, but if you indent with spaces you will be hurt
+and you will have deserved it. :)
 
-You _WILL_ indent with hard tabs, or you will be harmed. :)
-You can format for whatever tab spacing you like, but if you indent with spaces 
-you will be hurt, and you will have deserved it. :)
 For best results, use 4-space tabs, because that's what id used and what most 
 of us use.
 
+Atop each function you write, attach a /* */ comment heading, containing the
+name and a short, DESCRIPTIVE summary of the function's purpose. Indent both of
+these with one or more tabs. The function is to immediately follow the heading,
+with no space between.
+
+The return type should be located on the line previous to the function's name.
+This is to facilitate easy searches for a function using the simple regular
+expression "^FuncName".
+
+Functions that do not take a value should be explicitly declared to accept void,
+not simply ().
+
+Please use the SECTION_ prefix for new functions.
+
+Cross-target prefixes:
+IN_	Input
+JOY_	Joystick (called by IN_* functions)
+R_	Rendering
+S_	Sound
+VID_	Low-level video
+
+Target-specific prefixes:
+
+CL_	Client
+GL_	OpenGL rendering
+QFGL_	OpenGL portability aids
+SNDDMA_	DMA Sound (called from S_*)
+SV_	Server
+SW_	Software rendering
+x11_	X11R6-specific window handling
+
 /*
 	SECTION_FunctionName
 
@@ -17,8 +49,23 @@ SECTION_FunctionName (args)
 {
 	type	var;
 
-	for (stuff) {	// do something silly
+	for (var = 0; var; var++) {	// do something silly
 		:
 		:
 	}
 }
+
+For switch statements:
+
+switch (expr) {
+	case X:		// foo
+		:
+		:
+		break;
+	case Y:		// bar
+		:
+		:
+		break;
+	default:	// fallthrough
+		whatever;
+}