Revealing names Avoid Disinformation (ex: paymentStat) Meaningful Distinct (same name on one place, make other bad) Pronouncable Searchable Class Must noun, But Method must Verb Don’t be cute Pick one word per concept Don’t Joke Konsisten Mental Mapping = a, b == I,j,k
Single Responsibilty Principle Open/Close Principle
Niliadic, monadic, dyadic, triadic, polyadic (requires very special justification)
DRY -> duplication may be the root of all evil in software
ClarificationassertTrue(a.compareTo(b)==-1) ; // a < b
Journal comment Noise comment Construct The day of month : private int dayOfMonth Scary comment private string name; // the name Private byte age; // the age
To much information!!
There is a well-known heuristic called the Law of Demeter2 that says a module should not know about the innards of the objects it manipulates. As we saw in the last section, objects hide their data and expose operations. This means that an object should not expose its internal structure through accessors because to do so is to expose, rather than to hide, its internal structure.
Readable code is understandable code Naming Class names Context specific Method names Say exactly what they do The don’ts Don’t confuse Don’t hide Don’t joke Don’t be informal Tell a story! ---------------------------------------------------------------- Making it testable, is making it clean Isolation Decoupling Separation of concerns TDD Design Clean is the side effect of testable ----------------------------------------------------------------- Easy to extend A change requires one change, not ten Easy to understand Unbrittle Test coverage Spreads optimism Importance level: Readable > maintainable
Are You Ready For Clean Code?
Whisnu | Vox Teneo Indonesia
• We Are Programmer
• We Want to be a Better Programmer
A = 1
B = A
Print BA = 1
C = A
B = C
Print B - Same Task
- Same Effort
- Same Test Result
- No BUG’s
• You Will Have To Go Back
• Someone Else Will Have To Go Back
• They Don’t Teach That in School
• Good Code Matter
• Degrees of Bad
• The Netscape Fallacy
• Why Write Good Code
• But Doesn't Good Code Cost More Up Front?
Boy Scout Rule
Leave the campground cleaner than you found it.
Objects and Data Structures
int d; // elapsed time in days
string htmlOutput; // form configuration html
• Small and Should be smaller than that
• Do One Thing
• One Level of Abstraction
• String pagePathName = PathParser.render(path);
• Switch Statement (break it for SRP/OCP reason)
• Ideal number of arguments is ZERO
• Object Argument (hidden dependency, inject dependency, SRP)
• Have No Side Effect (setAndCheckIfExists())
• Don’t Comment Bad Code!
• Explain on Code
• Legal comment, TODO comment, JavaDoc, PHPDocumenter
• Warning of Consequences
• No Mumbling
• Redudant Comment
• Position Marker
• Closing Brace comment
• Attributes and ByLine
• Comment Out Code (your note code)
• The Purpose of Formatting?
• Vertical Matter, Horizontal Alignment
• Breaking Identation
• Team Rules
Object and Data Structures*
• The Law Of Demeter (Train Wrecks)
* lol + m/ =
The Three Laws of TDD:
• First Law You may not write production code until you have written a
failing unit test.
• Second Law You may not write more of a unit test than is sufficient to
fail, and not compiling is failing.
• Third Law You may not write more production code than is sufficient
to pass the currently failing test.