Clean Code Words

Question 1

DRY

Answer 1

Don’t repeat youself.

If you need to copy code create a function for it.

Question 2

KISS

Answer 2

Keep it simple stupid.

Create functions/classes as simple as possible

Question 3

Beware of Premature Optimization

Answer 3

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.

Question 4

FCoI

Answer 4

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)

Question 5

IOSP

Answer 5

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

Question 6

Boy Scout Rule

Answer 6

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.

Question 7

Root Cause Analysis

Answer 7

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.

Question 8

Version Control

Answer 8

Being afraid of damaging a running system paralyzes software development. Using version control that fear is obsolete and development can progress quickly and bravely.

Question 9

Simple Refactoring Patterns

Answer 9

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.

Question 10

Daily Reflection

Answer 10

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.

Question 11

SLA

Answer 11

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.

Question 12

SRP

Answer 12

Single Responsibility Principle

A class having exactly one task is easier to understand than a convenience store

Question 13

SoC

Answer 13

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.

Question 14

Source Code Conventions

Answer 14

Code is more frequently read than written. Accordingly conventions are important to support reading and conceive code quickly.

Question 15

Issue Tracking

Answer 15

Only written issues are not forgotten and can be efficiently followed-up or delegated.

Question 16

Automatized Integration Tests

Answer 16

Integration tests ensure the code does what it shall do

Question 17

Read, Read, Read

Answer 17

Reading educates!

Question 18

Reviews

Answer 18

Four eyes will see more than two eyes. Explaining own code to a fellow developer frequently reveals details which were not considered yet.

Question 19

ISP

Answer 19

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.

Question 20

DIP

Answer 20

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.

Question 21

LSP

Answer 21

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.

Question 22

PoLA

Answer 22

Principle of Least Astonishment

If a component behaves surprisingly different than expected, your application will become unnecessarily complex and error prone.

Question 23

IHP

Answer 23

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.

Question 24

Automatized Unit Tests

Answer 24

Only automatized tests are really executed in a consequent manner. The more accurate unit test verify code the better.

Question 25

Mockups

Answer 25

Mockups make controllable tests possible.

Question 26

Code Coverage Analysis

Answer 26

Only believe in tests you know they really cover the test area.

Question 27

Attend professional events

Answer 27

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.

Question 28

Complex Refactorings

Answer 28

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.

Question 29

Open Closed Principle

Answer 29

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

Question 30

Tell, Don’t Ask

Answer 30

High cohesion and loose coupling are virtues. Public state details in a class contradict those.

Question 31

Law of Demeter

Answer 31

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”.

Question 32

Continuous Integration

Answer 32

Automatization of centralization of software production increase productivity and reduce risk

Question 33

Metrics

Answer 33

Static Code Analysis

Trust, but verify.

Question 34

Inversion of Control Container

Answer 34

It is easier to configure things which are not hard-wired.

Question 35

Share Experience

Answer 35

Sharing your experience helps others and yourself.

Question 36

Error Measurement

Answer 36

You will only be able to reduce the error rate, if you first-hand know how many errors occur and adopt your approach accordingly.

Question 37

Design and Implementation don’t overlap

Answer 37

Design papers provide more damage than benefit if they have nothing in common with the implementation. Hence minimize risks for inconsistencies.

Question 38

Implementation reflects Design

Answer 38

Implementation deviating from design as you chose leads to no longer maintainable software. Implementation needs a physical frame given by design.

Question 39

YAGNI

Answer 39

You Ain’t Gonna Need It

Stuff which not used by anyone has no value. Do not spend any time on it.

Question 40

Continuous Delivery

Answer 40

Make sure the product becomes installed correctly.

Question 41

Iterative Development

Answer 41

As customer requirements can change software development would be wise to be able to adopt its course.

Question 42

Component Orientation

Answer 42

Software needs black-box-building-blocks which can be developed and tested in parallel.

Question 43

Test First

Answer 43

Customer is king and defines the shape of a service. Service implementations will fit only well, if these are driven by a client.