Notes from Bob Martin's Clean code book. Basically it's the index page.
Clean Code
There will be code: Code always exitst
Bad Code has effects
Wade through bad code
Le Blancs Law :: Later equals never
Cost of bad code
Grand redesigns
Attitude of devs for clean code matter
The art is nknowing clean code and being able to make it.
Clean code is elegant, simple, direct, readable, enhancable, does what is expected
There are many schools of though regarding clean code.
Authors of code are responsible and must promote readaiblity
The Boy Scout Rule
Prequel and Principles
Book:: Agile Software Development: Principles, Patterns and Practices
Principles of Design
Single Responsibility Priciple
Open/Closed Principle
Dependancy Inversion Principle
Meaningful names
Intention Revealing Names
Avoid Disinformation
Make meaningful distunctions
Use pronouncable names
Use searchable names
Avoid encodings
Hungarian Notations (type)
Member prefixes (mxxx)
Interface and Implementations (Iinterface)
Class names should be Nouns & Noun phrases
Method Names should be Verb and Verb phrases
Don't be cute
One word per concept
Don't pun
Use Solution Domain Names
Use Problem Domain Names
Add meaningful context
Don't add gratuitous context
Rename as needed
Functions
Keep functions small (limit indenting)
Do one thing onlyt (section using functions)
Use one level of abstraction per functions
Use The Stepdown Rule to manage layers (TO… == a level of abstractions)
for `switch` statements, Avoid or, abstract into an AbstractFactory
Use descriptive names
Function Arguments
Use common Monadic Forms
Dydadic FUnctions
Triads should be avoided if possible
Use Options Arguments
Arguments list are an option
Verbs and Keywords can be used in method name
Have no side effets
Avoid `out`, `this` is intended as an output argument
Use Command Query Separation
Prefer Exceptions to returning Error Codes
Extract try-catches
Error handling is one thing
An Error code class becomes a dependancy magnet through the project
DRY
Structured programming is an option
1 enter and 1 exit for each block and function.
Comments
Comments do not makeu-p for Bad Code
Explain yourself in code
Good Comments
Legal Comments
Informative Comments
Explanation of Intent
Clarification
Warning of Consequences
TODO Comments
Amplification Comments
Doc generation comments
Bad Comments
Mumbling Comments
Redundancy Comments
Misleading Comments
Mandated Comments
Journal Comments
Noise & Scary noise
Don't use comments when symbol names will work
Position Markers
Closing Braces Comments
Attribution and Bylines
Commented out code
Non-local comments
Too much information
Inobvious Connections
Function Headers
Doc generations in non-public code
Formatting
Vertical Formatting
Newspaper Metaphor
Vertical Openness between concepts
Vertical density
Vertical Distance
Vertical Distance
Vertical Ordering
Horizontal Formatting
Horizontal Openness and Density
Horizontal Alignment
Indentation
Dummy Scopes
Team Rules
Objects and Data Structures
Data Abstraction
Data/Object Anti-symmetry
Data has fields, Object has methods
Laws of Delimiter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Records are best as a Data Object
Error Handling
Use Exceptions over return codes
Write trry-catch-finally first
Use Unchecked exzceptions (don't define throws)
Provide context with exceptions
Define exceptions class in terms of caller's needs
Defined the normal form
Don't return null
Don't pass null
Boundaries
Using 3rd party code
Explaining and learnings from 3rd party boundaries should be clear
Test to learn the boundaries are better that free
Use code that doesn't exist yet with wish interface now, and an adapter later
Keep clean boundaries
Unit Tests
Laws of TDD
Must have failihng test
Test must small and possible
Code must pass the ptest only
Keep test clean for: flexibility, maintainability, reusability
Clean Tests
build-operate-check
Use domain specific testing language
There is a dual standard for test code ve production code
Single concept per test/ One assert per test
Test should be F.I.R.S.T
fast, independant, repeatable, self-validating, timely
Classes
Class Organization
Exnasulate but not at the cost of the tests
Classes should be small
Single Responsibility Priciple
Cohesion
Maintaining cohesion results in many small classes
Organizating of change
Isolate for change
Systems
Separate construction of a system from using it
Separate from `main`
Factories
Dependancy Injection
Scaling Up
Cross cutting concerns
Use a proxy object to test functionality
AOP to test a system
Test drive the System Architecture
Optimize desision making, pospone them
Use standards wisely, when they would add demonstratable value
System need domains specific language
Emergence
Getting clean by emergence with 4 rules
- Runs all the tests
- No Duplication
- Expressiveness
- Minimal Classes and Methods
Concurrency
Why concurrency?
Myths and Misconceptions
Concurrency always improves perfrormance
Design doesn't change when writing concurrent programs
Understanding concurrency issues is not iomportant when working with containers
Concurrency incuyrs some overhead
Correct concurrency is complex
Concurrency bugs aren't ussually repeatable
Concurrency often requires a fundamental change in design strategy
Some thread paths create challenges, some don't
Concurrency Defense Principles
- Single Responsibility Priciple
- Limit the scope of data
- Use copies of data
- Threads should be as inmdependant as possible