Please enable JavaScript.
Coggle requires JavaScript to display documents.
Clean code A HandBook of Agile Software Craftmanship. (:smiley:13…
Clean code A HandBook of Agile
Software Craftmanship.
:smiley:01_CleanCode
:smiley:teams that were moving fast at the beginning of a project can find themselves moving at a nail's pace.
Spending time keeping your code clean is not just cost effective; it's a matter of professional survival.
:smiley: It is unprofessional for programmers to bend to the will of managers who don't understand the risks of making messes.
:smiley:The only way to go fast - is to keep the code as clean as possible at all times.
:smiley:"
Bjarne Stroustrup
" I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.
Leave the campground cleaner than you found it
:smiley:02_Meaningful_Names
:smiley: Using intention-Revealing names
Why the name exists, what it does, and how it is used
If a name requires a comment, then the name does not reveal its intent.
public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell in gameBoard) {
if (cell.isFlagged()) {
flaggedCells.add(cell);
}
}
return flaggedCells;
}
:smiley:Using inconsistent spellings is disinformation.
:smiley:Make meaningful distinction.
:smiley:If names must be different, then they should also mean something different.
:smiley:Noise words are redundants.
:smiley:customerInfor is indistinguishable from customer, accountData is indistinguishable from customer.
=> Distinguish names in such a way that the reader knows what the differences offer.
:smiley:Using searchable name.
:smiley:Hungarian Notation.
:smiley:Member prefixes.
=> no need to use prefix because of having editing environment that highlight.
:smiley:Interfaces and implementations.
:smiley:Avoid mental mapping:
=> the professional programmer understands that clarify is king and they use their powers for good and write code that others can understand.
:smiley:Class Name.
=> having noun or noun phrases. like Customer, WikiPage
:smiley:Method Names.
=> Having verbs or verb phrase like postPayment, deletePage.
=> When constructors are overloaded, use static factory methods with names that describe arguments.
Ex: Complex fulCrumPoint = Complex.FromRealNumber(23.0);
:smiley:Don't be cute. => Choose clarify over entertainment value.
:smiley:Pick one word per concept.
=> A consistent lexicon is a great boon to the programmers who must use your code.
:smiley:Do not pun.
=> Using the same term for two different ideas is essentially a pun.
:smiley:Add meaningful context.
:smiley:Use solution domain names.
1 Choosing technical names for those things is usually the most appropriate course.
Separating solution and problem domain concepts is part of the job of a good programmer.
:smiley:Don't add Gratuitous Context.
:smiley:03_function.
:smiley:Small!
:smiley:Do one thing.
=> Functions should do one thing. They should do it well. They should do it only.
:smiley:Reading Code from Top to Bottom.
:smiley:Using abstract factory to replace if statement.
:smiley:Using descriptive names.
:smiley: Argument objects
:smiley:Prefer exceptions to Returning error codes
:smiley:04_Comment
:smiley:Explain yourself in code.
It's simply a matter of creating a function that says the same thing as the comment you want to write.
:smiley:Good comment.
Legal comment: ex: copyright and authorship statements.
Informative comment:
Warning of consequences.
TODO comments.
Amplification.
:smiley:Bad Comments.
Mumbling.
Redundant comments.
Misleading comments.
Noise comment.
Don't use a comment when you can use a function or a variable.
:smiley:05_Formatting.
:smiley:Blank lines that separates the package declaration, the import of each function.
:smiley:Variables should be declared as close their usage as possible
:smiley:Instance variable should be declared at the top of class.
:smiley:Dependent functions:
If one function calls another, they should be vertically close.
:smiley:unaligned declaration and assignment.
:smiley:06_Objects and Data Structure
:smiley:Data Transfer Objects.
:smiley:The law of demeter.
:smiley:07_Error_handling.
:smiley:use exceptions rather than return codes.
:smiley:Define exception class in terms of a caller's needs.
:smiley:Do not return null.
if you are tempted to return null from a method, consider throwing an exception or returning a special case object instead.
:smiley:Do not pass null.
:smiley:08_Boundaries.
:smiley:Explore and learning boundaries.
Write some tests to explore our understanding of the third-party code.
:smiley:Learning tests are better than free.
:smiley:09_Unit Tests
:smiley: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.
Their law
: You may not write more production code than is sufficient to pass the currently failing test.
:smiley:Keeping tests clean.
Readability: clarity, simplicity, and density of expression.
:smiley:Clean tests.
Fast.
Independent.
Repeatable. (in any environment).
Self-validating (Should have a boolean output).
Timely (should be written just before the production code makes them pass).
:smiley:10_Classes.
:smiley:Classes should be small.
A single responsibility: we want our systems to be composed of many small classes, not a few large ones.
:smiley: Naming is probably the first way of helping determine class size.
:smiley: Organizing for change.
:smiley:11_System.
:smiley::Separate constructing a System from Using it.
:smiley:Dependency injection.
:smiley:
Aspect oriented programming
.
:smiley:Use standard wisely.
:smiley:12_Emergence.
:smiley: Simple Design Rule 1: Run all the tests.
:smiley:Simple design rules 2 - 4: Refactoring.
No duplication.
Ex: Using polymorphism instead of two class for two objects.
Spend a little time with each of your functions and classes => choose better names, split large functions into smaller function, and generally just take care of what you've created.
:smiley: Minimal classes and methods.
:smiley:13_Concurrency.
:smiley: Myths and Misconceptions.
Concurrency always improve performance.
Design does not change when writing concurrent programs.
Understanding concurrency issues is not important when working in a container such as a Web or EJB container.
Concurrency incurs some overhead.
Correct concurrency is complex.
:smiley: Single responsibility.
A given method/class/component should have a single reason to change.
=>
Recommendation
: Keep your concurrency related code separate from other code.
:smiley:Limit the scope of data.
=>
Recommendation
: take data encapsulation to heart; severely limit the access of any data that may be shared.
:smiley: Use copies of data.
:smiley: Threads should be as independent as possible.
Attempted to partition data into dependent subsets than can be operated on by independent threads, possibly in different processor.
:smiley: Know your library.
:smiley: Know your execution models.
Learn the basic algorithms and understand their solutions.
:smiley:Beware dependencies between synchronized methods.
Recommendation
: avoid using more than one method on a shared object.
:smiley: Keep synchronized sections small.
Recommendation
: keep your synchronized sections as small as possible.
:smiley:Writing correct shut-down code is hard.
Recommendation
: think about shut-down early and get it working early. It's going to take longer than you expect. Review existing algorithms because this is probably harder than you think.
:smiley:Testing threaded code.
Treat spurious failures as candidate threading issues.
Do not ignore system failures as one-offs.
Get your nonthreaded code working first.
Make sure your code works outside of threads.
Make your threaded code pluggable.
Make your threaded code tunable.
Run with more threads than processors.
Run on different platforms.
Instrument your code to try and force failures.
:smiley:Hand-Coded.
:smiley:Automated.
:smiley:14_Successive Refinement.
The rough draft(Need to read code creafully).
Need to read code.
:
:smiley:15_JUnit(Testing).
private Map<Character, **ArgumentMarshaler**> marshaler = new HashMap<Character, **ArgumentMarshaler**>(); #ArgumentMarshaler as an interface.
private void parseBooleanSchemaElement(char elementId) {
booleanArgs.put(elementId, new
BooleanArugmentMarshaler());
}
private void setBooleanArg(char argChar, boolean value) {
booleanArgs.get(argChar).setBoolean(value);
}
public boolean getBoolean(char arg) {
return falseIfNull(booleanArgs.get(arg).getBoolean();
}
:smiley:16_Refactoring_SerialDate
:smiley:First, make it work.
:smiley:Then, make it rights.
:smiley: Smells and Heuristics.
:smiley:Comments.
:smiley:Inappropriate informations.
:smiley:Obsolete comment.
:smiley:Redundant comments.
:smiley:Poorly written comments.
:smiley:Commented-Out code.
:smiley:Environment.
:smiley:Build requires more than one steps.
:smiley:Test require more than one steps.(run all tests by one click or command).
:smiley:Functions.
:smiley:Too many arguments.
:smiley:Output argumenets
:smiley:Flag arguments.
:smiley:Dead funtions.
:smiley:General.
:smiley:Multiple language in one source files.
:smiley:Obvious behaviour is unimplemented.
:smiley:Incorrect behavior at the boundaries.
:smiley:Overridden safeties.
:smiley:Duplication.
should use polymorphism.
:smiley:Code at Wrong Level of Abstraction.
:smiley:Base classes depending on their derivatives.
:smiley:Too much information.
:smiley:Dead Code.
:smiley:Vertical separation.
:smiley:Inconsistency.
:smiley:Clutter.
:smiley:Artificial coupling.
:smiley:Feature envy
:smiley:Selector arguments.
:smiley:Obscured intent.
:smiley:Misplaced responsibility.
:smiley:Inappropriate static. (cannot behave polymorphiscally).
:smiley:Use explanatory variables.
:smiley:Function names should say what they do.
:smile:Understand the algorithm.
:smiley:Make logical dependencies physical.
:smiley:Prefer polymorphism to If/Else or Switch/Case
:smiley:Follow standard conventions.
:smiley:Replace magic numbers with named constants.
:smiley:Be precise.'
:smiley:Structure over convention.
:smiley:Functions should do one things.
:smiley:Hidden Temporal couplings.
:smiley:Avoid negative conditionals.
:smiley:Don't be arbitrary.
:smiley:Encapsulate boundary conditions.
:smiley:Functions should descend only one level of abstraction.
:smiley:Keep configurable data at high levels.
:smiley:Avoid trainsitive navigation.
:smiley:Names.
:smiley:Choose descriptive names.
:smiley:Choose names at the appropriate level of abstraction.
:smiley:Use standard nomenclature where possible.
:smiley:Unambiguous names.
:smiley: Use long names from long scopes.
:smiley:Test
:smiley:Insuficient tests.
:smiley:Use a coverage tools.
:smiley:Don't skip trivial tests.
:smiley:An ignored test is a question about an ambiguity.
:smiley:Test boundary conditions.
:smiley:Exhaustively test near bugs.
:smiley:Patterns of failure are revealing.
:smiley:Thread problems
:smiley:Mutual exclusion.
Using resouces that allow simultaneous use.
Increase the number of resources such that it equals or exceeds the number of competing threads.
Checking all that your resources are free before seizing any.
:smiley:Cannot be used by multiple threads at the same time.
:smiley:Are limited in number.
:smiley:Lock & wait.
Starvation: one threads keeps being unable to acquire the resources it needs.
Livelock. Several threads might get into lockstep and all acquire one resource and the release one resource, over and over again.
:smiley:No preemption.
Another strategy for avoiding deadlock is to allow threads to take resources away from other threads.
:smiley:Circular wait.
:smiley:The order of acquisition might not correspond to the order of use; thus a resource acquired at the start might not be used until the end.
:smiley:Sometimes you cannot impose an order on the acquisition of resources.