|
What's source?
|
|
|
What is destination?
|
|
Write names out!
|
|
Longer names trumps short Names
|
|
Searchable names trumps a constant in Code
|
|
Avoid Encodings
|
|
Make names pronouncable
|
|
Dirty:
|
|
// Name not changed when type changed
|
|
PhoneNumber phoneString;
|
|
Use
|
verbs, phrases like PostPayment, deletePage or SavePage
|
|
Constructor Overload use
|
Static factory Methods, with names, that describe the arguments
|
|
//Historic => Old Code or old Coder
|
|
private String m_dsc;
|
|
Dirty
|
Clean
|
|
interface IShapeFactory
|
class ShapeFactoryImpl
|
|
interface Shapefactory
|
|
Refactor
|
Clone
|
|
Copy & Paste
|
|
verb/noun Pair:
|
|
(to)writeField(name);
|
|
assertExpectedEqualsActual(expected, actual);
|
|
The Sequence should tell a Story:
|
|
includeSetup-AndTeardownPages();
|
|
includeSuiteSetupPage();
|
|
includeSetupPages();
|
|
AccountVisitor
|
VisitorPattern
|
|
Dirty
|
Clean
|
|
holyHandGrenade()
|
deleteItems()
|
|
eatMyShorts()
|
abort()
|
|
intermediate Level
|
String pagePathName = PathParser.render(pagePath);
|
|
low Level
|
.append(”\n”).
|
|
addressFirstName
|
|
addressLastName
|
|
addressState
|
|
If you must have a temporal coupling, you should make it clear in the name of the function
|
|
checkPasswordAndInitializeSession()
|
|
Clean:
|
loop Counter only: i, j, k
|
|
Dirty:
|
k and l because One (1)
=> too much |
|
Passing a boolean into a funciton is a truly terrible practise
|
|
render(boolean isSuite)
|
|
Use
|
* occasional multiple return,
|
|
* break and
|
|
|
* continue statement does no harm
|
|
|
Don't USE
|
never, ever, any goto statements
|
|
but
|
only in special languages. Be careful, you can destroy or control flow
|
|
Useless:
|
|
Niladic(0) best Solution:
|
|
includeSetupPage()
|
|
Polyadic ( More then three Arguments):
|
|
ResponseEntity<Map> responseEntity1 = restTemplate.exchange (REST_SERVICE_URI+"/contract/"+ID, HttpMethod.PUT, entity, Map.class)
|
|
Usable
|
|
Monadic:
|
|
boolean fileExists(“MyFile”)
|
|
Dyadic:
|
|
assertExpectedEqualsActual(expected, actual);
|
|
Triadic:
|
|
assertEquals(1.0, amount, .001);
|
|
You need:
|
|
* descriptive Skills
|
|
* shared cultural backround
|
|
* Don't be afraid of Renaming
|
|
* Use Refactoring Tools
-> IntelliJ |
|
The indent level of a function should not be greater then
|
|
one or two
|
|
We want every function to be followed by those at the next level of abstraction so that we can read the program, descending one level of abstraction at a time as we read down the list of functions.
|
|
To say this differently, we want to be able to read the program as though it were a set of TO paragraphs, each of which is describing the current level of abstraction and referencing subsequent TO paragraphs at the next level down.
|
|
MethodHeader:
To include the setups, Code: we include the suite setup if this is a suite, then we include the regular setup. |
|
Use:
|
|
insert(), append()
|
|
Instead of
|
|
add()
|
|
Either your function should change the state of an object, or it should return some information about that object:
|
|
public boolean set(String attribute, String value);
|
|
Clean:
|
|
if (attributeExists(”username”)) {setAttribute(”username”, ”unclebob”); … }
|
|
Dirty:
|
|
if (set(”username”, ”unclebob”)){...}
|
|
loop Counter only:
|
i, j, k
|
|
Never
|
l because One(1)
|
|
Functions should do one thing. They should do it well. They should do it only
|
|
* Aids the Reader
|
|
* Promote Reuse
|
|
*Eases Naming & Testing
|
|
*Avoid Sideeffects
|
No comments yet.
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.