2 min to read (297 words)

Notes from "Clean Code", Chapter 2

Tags: algorithms

At work, I am part of a developer book club. This is a great idea because all professionals should be in the habit of getting better. My homework was to read Chapter 2 from Clean Code, which is about naming.

Clean Code is a well-argued work, which may be why it remains a classic. The rules seem so simple -- why focus an entire early chapter on naming? Because it's the foundation to our code work, and developers who think they have a handle on it could still learn more.

Sprinkled throughout the chapters is the theme that our code has to be handed down to newer colleagues, as well as future versions of ourselves. Names are one way we communicate -- more so than comments themselves. With effective names, we need fewer comments.

Quoted from Chapter 2:

We have to process so much when reading code. Names need to help us understand. Bad names do worse than not help us -- they prevent us from understanding, or lead us to misunderstanding. Surely ZYXXY is meaningless, but what if you saw a variable named productIdsList that was actually a mapping of product ids to their respective descriptions? (True story, by the way!) Not only does the name not help you, it actively encourages you to misunderstand it!

posted 2015-04-22 20:09:27 -0700 by Belda


Recommended from Stack Overflow:

rake assets:precompile misses jquery-ui-rails files , tagged: ["ruby-on-rails", "asset-pipeline", "activeadmin"]

Rails - how to run a cmd line script and display the output in real time? , tagged: ["ruby-on-rails", "ruby"]

How to get localized values from Facebook Open Graph API through Koala? , tagged: ["facebook-graph-api", "translation", "koala-gem"]

Why does Active Record use module_eval internally for certain features? , tagged: ["ruby-on-rails", "ruby", "activerecord", "ruby-on-rails-4"]