Home > design, programming > Code Smells After Reading “Clean Code”

Code Smells After Reading “Clean Code”

I created projects that I don’t want to look at any more, because of complexity and total mess. You probably heard about “Clean Code” by Robert C. Martin, if not I encourage you to buy this book and read it.

I thought that having technical knowledge is enough to create great applications. It’s not true. Source code is written by developers for developers. Having clean code is one of the most important things in software development. It’s very wide idea but I will write the most important (for me) code smells that I will try to use in my all projects.

  • Names
    • use meaningful names for variables, classes, methods, … everything
    • use names at the same abstraction level
    • don’t use hungarian notation
  • Functions
    • create ONLY small functions
    • one function – one action/functionality
    • one level of abstraction within each function
    • try to use as small number of function arguments as possible
    • don’t repeat yourself (DRY)
    • don’t use output arguments
    • remove unused functions
  • Comments
    • clean code doesn’t need comments!
    • comments should only describe business logic
    • don’t left TODO/FIXME comments in the code, just do the job
    • use proper function name or simplify algorithm instead of commenting it
    • don’t left commented code, you have SVC to keep track of history
  • Formatting
    • use vertical breaks between code segments
    • use indentions properly and uniformly (decide between tabs and spaces)
  • Objects and Data Structures
    • modules shouldn’t know about objects implementations (Law of Demeter)
  • Unit Tests
    • try to use TDD as much as possible, it will simplify your design
    • keep test as clean as your production source code
    • one test verifies only one functionality (only one assertion)
    • test success and error paths
    • always test boarder conditions
    • follow F.I.R.S.T. rules when writing unit tests:
      • fast
      • independent
      • repeatable
      • self-validating
      • timely
  • Classes
    • classes should be small
    • make every class consistent and compact
    • use polymorphism instead of if-else or switch statements
    • follow S.O.L.I.D. principles when creating classes:
      • single responsibility
      • open/close
      • Liskov substitution
      • interface segregation
      • dependency inversion
  • Simple Project Principles
    • all tests are passing
    • no repetitions
    • code do what the developer intended
    • minimal number of classes and methods
  • Environment
    • one click to build project
    • one click to run all unit tests
  • General
    • don’t use magic numbers and magic strings
    • extract long conditional statements to functions
    • don’t use double negative conditional statements

Above statements can make you proud of your code. Try to use it!

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: