Table of Contents | ||
---|---|---|
|
...
- list series naming (a1, a2, … aN)
- noise words (ProductInfo or ProductData; what purpose do “Info” or “Data” serve?)
"People are also afraid of renaming things for fear that some other developers will object. We do not share that fear and find that we are actually grateful when names change (for the better). Most of the time we don’t really memorize the names of classes and methods"
What is noise?
- "Manager" in a name is useless in practice
- Might sometimes be necessary to use?
...
- Start with introduction about why we want to have clean code best practices (Nimisha Asthagiri (Deactivated) - 1 minute)
- Comments (Alexander Dusenbery)
- C1 - C5
- TODO comments (including ticket #, expiration date)
- Descriptive Code versus difficult conditational and comments (Jeremy Bowman (Deactivated))
- G19 - Use explanatory variables, G28 - Encapsulate conditionals, G29 - Avoid negative conditionals
- Naming (Alessandro Roux (Deactivated))
- G20 - Function names should say what they do, N1 - Choose descriptive names, N5 - Use long names for long scopes
- Arguments (Alessandro Roux (Deactivated))
- F1 - Too many arguments
- F3 - Flag arguments, G15 - Selector arguments
- Constants (Sofiya Semenova (Deactivated))
- G25 - Replace magic numbers with named constants
- Dead Code (Sofiya Semenova (Deactivated))
- F4 - Dead function, G9 - Dead code, G12 - Clutter
- Least surprise (Jeremy Bowman (Deactivated))
- G2 - (Non)Obvious behavior is unimplemented
- Encapsulation , Interfaces and levels of Abstraction Interfaces (Nimisha Asthagiri (Deactivated))
- G36 - Avoid transitive navigation
Mock Trials (15 min each, total 30 min)
Goals
- To remind folks that things aren't always clear-cut and it's important for folks to think for themselves as each context is different - even though there's a well-respected published book on this topic.
- To remind folks that sometimes things can get subjective and be conscious of our own righteous/religious POVs when reviewing people's code.
- To have fun as we explore these topics further in edX engineering with light-hearted debates.
Roles
- Judge: Adam Palay (Deactivated)
- Clerk: ??
Trials
(Defendants: Uncle Bob's position on these)
- G5 - Duplication/DRY (Bill DeRusha (Deactivated) vs. Julia Eskew (Deactivated))
- G30 - Functions should do one thing, G34 - Functions should only descend one level of abstraction (Sofiya Semenova (Deactivated), Alexander Dusenbery, Brian Beggs)
pp 10-11 Returning and Passing None vs. Raising an Exception (Ned Batchelder (Deactivated) vs. Brian Beggs)