3 min to read (397 words)

Clean Code: Comments, Formatting, Objects and Data Structures

Tags: javascript | rails | ruby

On Friday, we discussed Clean Code for developers' book club at the office.

Here are my thoughts on chapters 4, 5, 6:

Chapter 4: Comments

The best comment is one that is not written. With scripting languages like Ruby and Python, writing readable code is easy. People often say that they like writing Ruby code because it is so readable.

However, just as there are good writers and writers who need improvement, there are clean coders (like the book is trying to promote) and coders who need improvement. I am realizing that there is a difference between knowing a lot about computers/technology and actually organizing code for your fellow human colleagues to reuse/understand.

Chapter 5: Formatting

This chapter discusses another technique for code organization, via formatting. There is mention about horizontal space (< 120 characters across) and vertical space (file length in lines). And most importantly, agreeing on a formatting style within the workplace.

At this point, I asked about editing the code style to match in a file. We do not have a company-wide agreement on code style, and file by file we may have single quotes, double quotes, no space after a brace {, 1 space after a brace, etc. The conclusion was that we should have a meeting at a later date to determine.

Chapter 6: Objects and Data Structure

This was a higher-level chapter. It discusses the Law of Demeter, which can be summarized: a method should touch friends' variables, not strangers'.

I will also quote an interesting observation from this chapter:

[T]he fundamental dichotomy between objects and data structures:

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

The complement is also true:

Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.

What a lot to think about! I think that if you are working in an existing codebase (with all its strengths and faults/needs-improvements), implementing these newly-learned processes one-by-one -- even as new code is written -- should improve both your codebase and your coding style. A codebase is a living thing, so it's never too late to make the code cleaner!

posted 2015-08-02 00:35:07 -0700 by Belda

Recommended from Stack Overflow:

HTTP:No &#39;Access-Control-Allow-Origin&#39; header is present on the requested resource , tagged: ["ruby-on-rails", "angularjs"]

dotenv and linked_files with capistrano 3 , tagged: ["ruby-on-rails", "ruby", "capistrano"]

Videos not uploading with Paperclip Gem - ffmpeg in Rails , tagged: ["ruby", "video", "ruby-on-rails-4", "migration", "paperclip"]

ERROR: While executing gem ... (Errno::EINVAL) Invalid argument - ./ActionDispatch/Routing/Mapper/Scoping/: , tagged: ["ruby-on-rails", "ruby"]