What is “The Boy Scout Rule”?
Leave the campground cleaner than you found it.
Variable naming conventions
- intention revealing names (make sure it does not require comments to reveal its intents)
- avoid disinformation (don’t name a group of thins xxxList unless it is really implemented as a List)
- make meaningful distinction (instead of a1 and a2, name them “source” and “destination”)
- pronouncable name
- searchable names (single lettern variables as local variables only)
- avoid encodings (type prefixes, m_, etc.)
Function coding conventions
- make them small
- functions should do one and only one thing
- one level of abstraction per page
- use descriptive names
- use at most 3 arguments (the smaller is the better). More than 3 requires special justification. Try using parameter objects.
- avoid flag arguments (often indicates the function does more than one thing) -> split it to two functions
- should have no sideeffects
- either command or query function
- prefer exceptions to error codes
How should long switch statements in business logic be fixed?
- use polymorphism (descandent classes implementing specific cases of business logic)
- move switch statements to an abstract factory that creates different instances based on a condition (the difference between the original and this solution is that switch is not used in the decision in a complex business logic, but during the creation of the object)
What are the problems with comments?
- hard to maintain (code is refactored, but comment left unmodified)
- indicates coding failure (you just comment, because your code does not reflect your intentions)
- inaccurate comment are misleading
When are comments good?
- TODO comments
- warning comments (“XY class is not thread safe! We need to create a new instance every time!”)
- using 3rd party libraries that you cannot modify and its intent is not clear by reading the code
- javadocs in public APIs
What are the problems with boolean parameters?
The usually indicate that the method is doing more than one thing, thus it should be split into two independent methods.
What are some of the most importand error handling rules?
- Use exceptions instead of error codes
- Use unchecked exceptions
- Define exception classes in terms of a caller’s needs
- Do not return nulls (thow exception or use special case objects)
5.
What are the three laws of unit testing?
- You may not write production code until you have written a failing unit test.
- You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
- You may not write more production code than is sufficient to pass the currenet failing test.
What are some of the best practices of unit testing?
- One assert per test
- single concept per test
What is the F.I.R.S.T. rule?
- Fast
- Independent
- Repeatable
- Self-Validating (you should not have to read a log file to determine, whether the test result is good or not. It should have boolean output, good or bad; no manual validation)
- Timely (write test before production code, not after)
Best practices of writing classes.
- Classes should be small (in terms of responsibilities -> Single Responsibility Principle)
- High cohesion
What is cohesion in a class?
Cohesion indicates how many variables of a class is being manipulated by its methods. A class is maximally cohesive if its variable is used by all its methods. In practice it is usually not possible and advisable to create a maximally cohesive class.
