Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
cs-236:style-guide [2017/01/19 16:23]
egm [Test Cases]
cs-236:style-guide [2017/07/11 14:59] (current)
pdiddy [Summary]
Line 25: Line 25:
 #* Are test cases documented with justification and expected output? #* Are test cases documented with justification and expected output?
 # Variables and Constants # Variables and Constants
-#* Are the variables [https://​en.wikipedia.org/​wiki/​Camel_case camelCase] (with the first letter ​lower‐case) or with [https://​en.wikipedia.org/​wiki/​Naming_convention_(programming)#​Multiple-word_identifiers delimiter-separated words] that use lower case letters and underscores as delimiters?+#* Are the variables [https://​en.wikipedia.org/​wiki/​Camel_case camelCase] (with the first letter ​lowercase) or with [https://​en.wikipedia.org/​wiki/​Naming_convention_(programming)#​Multiple-word_identifiers delimiter-separated words] that use lowercase ​letters and underscores as delimiters?
 #* Are the constants all caps with underscores between words? #* Are the constants all caps with underscores between words?
 #* Are variables and constants initialized when they are declared? #* Are variables and constants initialized when they are declared?
Line 33: Line 33:
 #* Are all numbers in the code constants or fit reasonable exceptions? #* Are all numbers in the code constants or fit reasonable exceptions?
 # Functions and Methods # Functions and Methods
-#* Are the names [https://​en.wikipedia.org/​wiki/​Camel_case camelCase] (with the first letter ​lower‐case) or with [https://​en.wikipedia.org/​wiki/​Naming_convention_(programming)#​Multiple-word_identifiers delimiter-separated words] that use lower case letters and underscores as delimiters?+#* Are the names [https://​en.wikipedia.org/​wiki/​Camel_case camelCase] (with the first letter ​lowercase) or with [https://​en.wikipedia.org/​wiki/​Naming_convention_(programming)#​Multiple-word_identifiers delimiter-separated words] that use lowercase ​letters and underscores as delimiters?
 #* Are the parameter names descriptive?​ #* Are the parameter names descriptive?​
 #* Do the functions or methods only do task? #* Do the functions or methods only do task?
Line 40: Line 40:
 #* Are parameters declared as const-references where appropriate to avoid needless copying? #* Are parameters declared as const-references where appropriate to avoid needless copying?
 # Objects and Classes # Objects and Classes
-#* Are class names [https://​en.wikipedia.org/​wiki/​Camel_case camelCase] (with the first letter ​lower‐case)?+#* Are class names [https://​en.wikipedia.org/​wiki/​Camel_case camelCase] (with the first letter ​uppercase for class names)?
 #* Are the names descriptive?​ #* Are the names descriptive?​
 #* Does each class have a default constructor?​ #* Does each class have a default constructor?​
Line 324: Line 324:
 * If passing a large data structure, prefer passing by reference, and if that structure is not intended to be updated, then prefer passing by const reference. Using standard variable naming conventions for const parameters (e.g., these are not constants in the code and should not be named in all caps). ​ * If passing a large data structure, prefer passing by reference, and if that structure is not intended to be updated, then prefer passing by const reference. Using standard variable naming conventions for const parameters (e.g., these are not constants in the code and should not be named in all caps). ​
 * Variables and constants should be declared at the beginning of the scope in which they are used.  * Variables and constants should be declared at the beginning of the scope in which they are used. 
 +* Functions and methods should assert assumption on parameters. For example, if there is an assumption that a pointer is not null, such an assumption should be asserted: ''​assert (boxPointer != NULL);''​. Or as another example, if an integer parameters is assumed to be positive in the code, such an assumption should be asserted: ''​assert(numCars > 0);''​. Asserting assumptions is another form of self-documenting code and helps others use the code as it was intended by the original author. ​
  
 The size limit and one-task requirement affect the complexity of the code. Generally shorter code is simpler to write, easier to understand, and less likely to have defect than longer code. Like any guideline though, it is just a guideline. The ability to read and maintain the code is the high-order bit that overrides these guidelines. If something a bit longer or that does multiple things is easier to understand, maintain, and test, then do it.  The size limit and one-task requirement affect the complexity of the code. Generally shorter code is simpler to write, easier to understand, and less likely to have defect than longer code. Like any guideline though, it is just a guideline. The ability to read and maintain the code is the high-order bit that overrides these guidelines. If something a bit longer or that does multiple things is easier to understand, maintain, and test, then do it. 
cs-236/style-guide.1484868212.txt.gz · Last modified: 2017/01/19 16:23 by egm
Back to top
CC Attribution-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0