Clean Code

Tuesday, October 8, 2013

Writing code is easy, reading code is hard

Avoid technical debt

Put extra care in the code up front so it's easier to work with later

Building Blocks:

  1. Clean code is readable and maintainable
  2. SOLID Principles
  3. Legacy code is any code that is not under test
  4. Automated Testing
  5. Refactoring
  6. Domain Driven Design
  7. Test Driven Development
  8. Design Patterns

Resources to read

  • Code Complete - Steve McConnell
  • Clean Code - Robert C. Martin
  • The Pragmatic Programmer - Andrew Hunt, Dave Thomas
"If your code comes with tests, you should sacrifice a small animal in gratitude." Pragmatic Programmer

Stay Native

  • Keep HTML, JS, CSS, C# code in their respective files and boundaries
  • Cached, Code Colored, Syntax checked, Separation of Concerns, Reusable, Avoid string parsing
  • Minification and obfuscation
  • One language per file, leverage libraries

Every technology has its limitations

  • Linq To Sql powerful data access technology. Massive queries and outer joins disaster
  • Flash/Silverlight can be matched with native video and audio tags among others
  • Javascript great for rich browser interactions, however validation and proprietary algorithms on client are unsafe

Increase signal, decrease noise, improve the ratio

  • Signals should be terse, expressive and do one thing and do it right
  • Reduce noise: cyclomatic complexity, excessive indentation, zombie code, unnecessary comments, poorly named structures, huge classes, long methods, repetition, no whitespace, overly verbose
  • Rule of 7, humans can retain 7 items +/- 2

Dry Principle

  • Don't repeat yourself
  • Relational DB Normalization applies many of the same principles
  • Copy and paste is a design problem
  • Duplication: every line of code is a liability
  • Stay light, minimize lines of code in code base
  • Fewer lines of code, correlated with fewer bugs
  • Look for patterns, repetitious shapes, opportunities for simplification

Self Documenting Code

  • Understanding the original programmer's intent is the most difficult problem
  • Express intent clearly
  • Layer of abstractions
  • Format for readability
  • Favor code over comments

Proper Naming


Naming classes, well defined class has a single responsibility, the name should reflect that

  1. Noun
  2. Specific
  3. Single Responsibility
  4. Avoid Generic Suffixes

Watch out for Side Effects

  • CheckPassword shouldn't create a session
  • ValidateSubmission shouldn't send an email
  • ChargeCreditCard shouldn't log user out

Avoid Abbreviations

  • In the 80's storage was limited and expensive, every byte counted
  • Nowadays select long descriptive names
  • Name the class RegisterUser instead of RgUsr

Naming Booleans

  • Well named booleans sound like asking a true false question
  • Dirty examples: open, start, status, login
  • Clean examples: isOpen, isStarted, isActive, loggedIn

Symmetry when naming variables

  • Dirty examples: on/disable, quick/slow, lock/open, slow/max
  • Clean examples: on/off, fast/slow, open/close, min/max

Conditionals

  • Express clear intent
  • Use the right tool
  • Byte-size logic that finite minds can easily comprehense at once
  • Code is sometimes not the answer

Boolean Comparisons


Boolean Assignments


Positive Conditionals


Ternary Elegance, DRY, YAGNI


Avoid stringly typed


Magic Numbers


Complex Conditionals, use intermediate variables, encapsulate via functions


Encapsulation

Default Success Warning Important Info Inverse
B S W I ? O