Clean Code Words Flashcards
(43 cards)
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.
