Professional Documents
Culture Documents
Hints that the code you're reading is a mess Source Code Structure Objects VS Data Structures
Rigidity Use vertical formatting to separate your Data structures exposes data and have no
code and different concepts, you should read behavior.
No change is trivial, every change in the
your code from top to bottom without So, procedural code makes it easy to add new
code add more twists and tangles.
"jumping" over functions function without changing the existing data
Complexity
Variables should be declared as close to structures.
As above, no change is trivial and requires a
their usage as possible Objects expose behavior and hide data.
lot of research.
Instance variables should be declared at the Object Oriented code makes it easy to add
Fragility new classes without changing existing
top of the class
Changes breaking other parts of the code. functions
Put statics methods on top of the package
Avoid hybrids (half object and half data
Immobility Similar and dependent functions should be
structure)
You cannot reuse part of the existing code close vertically
Balance between vertical openness and The Law of Demeter : A class should not know
General Rules vertical density. Same rules apply for
about the innards of the objects it manipulates.
horizontal density Objects should not expose theirs internals.
Follow the Boy Scout Rule : Leave the code
cleaner than when you found it Do not align your code horizontally Same as functions : they should do one thing
Follow the Principle of Least Surprise Use consistent indentation and they should be small
Follow Standard Conventions, both langage Avoid and split Train Wrecks :
Naming Rules objectA.getB().getC().getD();
related and team related
Keep it simple stupid Use descriptive and intention-revealing Keep the number of instance variables low, if
variable names your class have too many instance variable,
Don't repeat yourself
then it is probably doing more than one
Make meaningful distinctions
Be consistent thing
Use pronounceable and searchable names
Do not override safeties
Avoid disinformation and encoded names Error handling
Design Rules Avoid member prefixes or types information
Error handling is one thing, don't mix error
(Hungarian Notation)
Functions should descend only one level of handling and code
Avoid mental mapping
abstraction, and statements in a function Use Exceptions instead of returning error
should be at the same level of abstraction Replace Magic Numbers with Constants
codes
Use dependency injection Write the try-catch-finally statement first, it will
Functions
Keep your boundaries clean help you structure your code
Functions should do one thing and they Don't return null, don't pass null either
Encapsulate conditionals, try to avoid
should do it well
negative conditionals Throw exceptions with context
Functions should be relatively small
Make logical dependencies physical
Functions should have descriptives names Tests
Use polymorphism instead of if / else or
switch / case Functions should have as few arguments as F.I.R.S.T : Fast, Independent, Repeatable,
possible (no more than 3 if possible) Self-Validating, Timely
Avoid hidden temporal couplings
Functions should have no side effects One assert per test
Keep configurable data (ie: constants) at high
levels, they should be easy to change Use explanatory variables to explain your Keep your tests as clean as your production
Use Enums over constants intent / algorithm code, they should be easily readable
Don't use flag arguments Use a coverage tool
Avoid output arguments, they're misleading
Tests should be easy to run
TDD
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 count as failing
You may not write production code that is sufficient to pass the
currently failing test
Comments
Comment-out code ?
DELETE IT
Avoid using more than one langage in a single source file (Html
comments, Javadoc for nonplublic code)
Credits
By Coste Maxime