Technology Cafe

This is review of the 3rd chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin

A class is nothing but a collection of functions. Functions are what your program is.

In this chapter- Functions are discussed-how they improve your code and how they can push you – I mean your program over the cliff.

Rules regarding responsibility, error handling, size of the functions, naming conventions, arguments,side affects ,repetition are discussed.

When we write code – we of course communicate with the processor – telling it what to do- but we also hold a dialogue with fellow programmers who will come in after you – as to what you are trying to achieve. Functions are integral to a good communication between you and others. Processor wouldn’t mind if you have named your function as doit() . But it does matter to your fellow programmers.

Function signature reveals intent of what you are doing and the body explains how you are doing. You should be able to take one quick glance at the signature and know what the function does.

A good function would be small in size, does one thing and one does it well, has a meaningful name, doesn’t mix error handling and  core logic in one place, has 0-3 arguments, offers no surprise, no side affects.

For other chapters- please see this post.

This is review of the 1st chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)” by Robert C. Martin

In this chapter, Robert sets grounds about what to expect in the rest of the book.

He puts the focus on back the code as being the most important ingredient in Software. There are three factors to this-
A) Knowing what is good code vs bad code
B) Know how to write good code and
C) Professionalism which inspires discipline to write good code and nothing else

He quotes views of greats like Bjarne Stroustrup and Grady Booch on what is good code. Everyone had their own way of describing what good code is- but finally it comes down to one thing code which is – “Simple to read”.

On the most famous excuse on writing bad code- “we didn’t have time”- Robert presents an excellent analogy about a doctor who washes his hands before doing a procedure. He is not going to stop doing so – if the patient thinks that its a waste of time. No one knows more than the doctor how important washing hands is. Similarly it would be unprofessional for us to write anything but good code.

For other chapters- please see this post.