Clean Code Words Flashcards
DRY
Don’t repeat youself.
If you need to copy code create a function for it.
KISS
Keep it simple stupid.
Create functions/classes as simple as possible
Beware of Premature Optimization
Optimize only when its necessary and required.
Rules of Optimization:
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.
FCoI
Favour Composition over Inheritance
„Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that ‚inheritance breaks encapsulation„. (Gang of Four 1995:19)
IOSP
Integration Operation Segregation Principle
IOSP uses a clear separation for function logic.
- A method (called Operation) contains only logic Transformationen, Controllstructures, I/O- or API-calls.
- A method (called Integration) contains no logic only method calls of the same code base
Boy Scout Rule
Every time you work on some code it may get a little bit better. Without bureaucratic planning.
Clean code developers leave code in a better state than they found it. So after work accomplished code shall apply more to CCD values than before.
Root Cause Analysis
knowing the root cause, clean-up tends to be less effert than curing symptoms
Root Cause Analysis is also known as “Five Why’s”.
This term origins from the Toyota Production System (TPS) stating the basic idea to ask “Why?” five times.
Version Control
Being afraid of damaging a running system paralyzes software development. Using version control that fear is obsolete and development can progress quickly and bravely.
Simple Refactoring Patterns
Improving code is easier if you know typical improvement patterns. Their usage scenarios sensitize for weaknesses in self-written code. As accepted patterns they encourage to be applied.
Daily Reflection
There is no improvement, no progress, no learning without Reflection. But only if reflection is on the schedule, it will happen under daily business pressure.
SLA
Single Level of Abstraction
Within one method you should use only one level of abstraction. Otherwise the reader will find it hard to differentiate essentials from details. So if you need to fiddle with bits, don’t combine it with method calls.
Lines of code may have different levels of abstraction. Assigning a value to a variable is on a lower level than let’s say a method call.
SRP
Single Responsibility Principle
A class having exactly one task is easier to understand than a convenience store
SoC
Separation of Concerns
If a code unit does not have a clear purpose, it will be difficult to understand, difficult to use, difficult to enhance and difficult to correct.
You should not combine multiple concerns in one class. What is a concern?
Concerns a “completely different” purposes.
Concern are considered to be orthogonal to each other and especially orthogonal to the main functionality of a functional unit. Samples for typical concerns are: Tracing, logging, transaction handling, caching. If you follow SoC principle, you will extract these concerns into specialized functional units.
Source Code Conventions
Code is more frequently read than written. Accordingly conventions are important to support reading and conceive code quickly.
Issue Tracking
Only written issues are not forgotten and can be efficiently followed-up or delegated.
Automatized Integration Tests
Integration tests ensure the code does what it shall do
Read, Read, Read
Reading educates!
Reviews
Four eyes will see more than two eyes. Explaining own code to a fellow developer frequently reveals details which were not considered yet.
ISP
Interface Segregation Principle
It states that a client shall not depend on service details which the client does not use. The leaner the service interface is the smaller is the coupling of both components.
DIP
Dependency Inversion Principle
Class isolation is a prerequisite for testing to the point. Isolation is when classes receive no more implementation dependencies neither at compile time nor at runtime.
Concrete dependencies shall be decided on as late as possible. Ideally at runtime.
LSP
Liskov Substitution Principle
Avoid surprises with the heirs if you are familiar with the testator.
It claims that subtypes have to behave like their base type
Generally speaking the principle states that a subtype may only extend base type functionality but must not reduce it. A subtype can keep or extend a value range defined in a base type but never limit it.
PoLA
Principle of Least Astonishment
If a component behaves surprisingly different than expected, your application will become unnecessarily complex and error prone.
IHP
Information Hiding Principle
Hiding details in an interface reduces dependencies.
Interface design should consider which details need to be visible to the outside world. “Interface” not only in its object oriented meaning but also implicit interfaces.
Automatized Unit Tests
Only automatized tests are really executed in a consequent manner. The more accurate unit test verify code the better.
Mockups
Mockups make controllable tests possible.
Code Coverage Analysis
Only believe in tests you know they really cover the test area.
Attend professional events
Discussing regularly to other software developers and exchanging experiences prevents stewing in one’s own juice. To get new views that exchange should happen with developers outside of the team, apart from daily routine, e. g. in user groups.
Complex Refactorings
It is not possible to write code in an ultimate form.
Dividing simple from complex refactorings make sense because complex refactorings will only be efficient and riskless with automatized tests at hand.
Without tests you wouldn’t know if the code is still correct.
Open Closed Principle
Keep the risk as low as possible to destabilize a system by adding new features.
Claims to keep a class open for enhancements but closed against modifications
Tell, Don’t Ask
High cohesion and loose coupling are virtues. Public state details in a class contradict those.
Law of Demeter
Object dependencies over multiple service chain elements lead to unpleasantly close coupling.
The Law of Demeter is about limiting the interplay of objects to a healthy extent. Simplified it means “Don’t talk to strangers”.
Continuous Integration
Automatization of centralization of software production increase productivity and reduce risk
Metrics
Static Code Analysis
Trust, but verify.
Inversion of Control Container
It is easier to configure things which are not hard-wired.
Share Experience
Sharing your experience helps others and yourself.
Error Measurement
You will only be able to reduce the error rate, if you first-hand know how many errors occur and adopt your approach accordingly.
Design and Implementation don’t overlap
Design papers provide more damage than benefit if they have nothing in common with the implementation. Hence minimize risks for inconsistencies.
Implementation reflects Design
Implementation deviating from design as you chose leads to no longer maintainable software. Implementation needs a physical frame given by design.
YAGNI
You Ain’t Gonna Need It
Stuff which not used by anyone has no value. Do not spend any time on it.
Continuous Delivery
Make sure the product becomes installed correctly.
Iterative Development
As customer requirements can change software development would be wise to be able to adopt its course.
Component Orientation
Software needs black-box-building-blocks which can be developed and tested in parallel.
Test First
Customer is king and defines the shape of a service. Service implementations will fit only well, if these are driven by a client.
