Technotes, HowTo Series C # Coding Style Guide Version 0.3

Technotes, HowTo Series C ? Coding Style Guide Version 0.3 by Mike Krüger, mike@icsharpcode.net Contents 1 About the C# Coding Style Guide …
About the C# Coding Style Guide This document may be read as a guide to writing robust and reliable programs. It focuses on programs written in C ? , but many of the rules and principles are useful even if you write in another programming language. 2 File Organization 2.1 C ? Sourcefiles Keep your classes/files short, don’t exceed 2000 LOC, divide your code up, make structures clearer. Put every class in a separate file and name the file like the class name (with .cs as extension of course). This convention makes things much easier. 2.2 Directory Layout Create a directory for every namespace. (For MyProject.TestSuite. TestTier use MyProject/ TestSuite/TestTier as the path, do not use the namespace name with dots.) This makes it easier to map namespaces to the directory layout.
4 Comments 4.1 Block Comments Block comments should usually be avoided. For descriptions use of the /// comments to give C ? standard descriptions is recommended. When you wish to use block comments you should use the following style : /* Line 1 * Line 2 * Line 3 */ As this will set off the block visually from code for the (human) reader. Alternatively you might use this oldfashioned C style for single line comments, even though it is not recommended. In case you use this style, a line break should follow the comment, as it is hard to see code preceeded by comments in the same line: /* blah blah blah */ Block comments may be useful in rare cases, refer to the TechNote ‘The fine Art of Commenting’ for an example. Generally block comments are useful for comment out large sections of code. 4.2 Single Line Comments You should use the // comment style to “comment out” code (SharpDevelop has a key for it, Alt+/) . It may be used for commenting sections of code too. Single line comments must be indented to the indent level when they are used for code documentation. Commented out code should be commented out in the first line to enhance the visibility of commented out code. A rule of thumb says that generally, the length of a comment should not exceed the length of the code explained by too much, as this is an indication of too complicated, potentially buggy, code. 4.3 Documentation Comments In the .net framework, Microsoft has introduced a documentation generation system based on XML comments. These comments are formally single line C ? comments containing XML tags. They follow this pattern for single line comments: ….
Download Technotes, HowTo Series C ? Coding Style Guide Version 0.3.Pdf