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
Rails 4 fingerprinting causing 404 for bootstrap assets in production environment , tagged: ["ruby-on-rails-4", "asset-pipeline", "bootstrap-sass", "asset-finger-printing", "precompile-assets"]
How to run spec for a gem in your path , tagged: ["ruby-on-rails", "ruby", "rspec", "gem", "rails-engines"]
How to test module using concerns and associations, via dummy ActiveRecord model in specs , tagged: ["ruby-on-rails", "ruby", "activerecord"]