Declarative vs Imperative Programming
John is an enthusiastic developer who joined the company as a fresher, six months back. He wanted to be a successful developer. He delivered his first assignment on time and was proud about it. Thinking back, he had learned a lot, faced lots of obstacles and overcame them, put in loads of extra-time at work and delivered the product as per clients specifications.
But while reviewing the code, John’s supervisor was not very happy with his work. All he said was: You have to write your code declarative not imperative! John was disappointed. And moreover, he had no idea about what his supervisor just said.
John googled and got some information about Imperative and Declarative programming, but he couldn’t figure out why it was important. The gist of John’s understanding is:
Declarative — the focus is on what is being done by the code
Imperative — the focus is on how the code works.
We write code, so that the computer can understand it and execute it. But that is not enough. The code should not only be machine readable but also human readable. The code should read like a story. Not like solving a complicated puzzle.
John’s supervisor was interested only in knowing what the code does. But all he got was how the code works, and from that he had to figure out correctly or wrongly what the code does. He was reading imperative code. He had to go through each and every line. He need to hold a lot of information in his temporary memory. He virtually runs the program in his mind in order to understand, what the code does. There is a lot of mental strain involved while reading the imperative code.
Any software product development has two stages:
- The development stage — when we create the product and deliver to the client.
- Then maintenance stage — when we provide support to the delivered product.
But truth being told, for a developer, more than 70% of work, even in development stage itself is maintenance. Though we develop the application for an year, we still need to maintain the code on day 2, what we wrote on day 1. Simply put, we write our code once and we read it many times in future. Apart from self reading, our co-developers and supervisors will read and work on our code. And to top it all, the worth of the product highly depends upon the maintainability (read: readability) of the product.
Function is one great tool for writing declarative programming in any modern languages. For example , I can write a function formatDataAndSave(). The body of the function may contain 100 lines. Anyone who read the code, immediately understand what the code does. They don’t have to read the 100 lines of ‘how’ the code works, in order to figure out ‘what’ the code does. Just reading the function name is enough. This helps the reader to quickly narrow down and reach their area of concern. Here even the 100 line body is a concern. It can further be splitted into more functions for better readability and less mental strain.
Years ago, adding a lot of comments to the code, was considered the best practice. But now, many experts frown upon this idea due to the problems it created. Very often, developer who changed the code, will forget to change the comment. And the comment would mislead the future readers. And more over, your code should tell on its own what it does, and it should not rely on external help through comments. Experts advice to comment your code sparingly, just to convey things what we can never convey through code. Comments are also used to create auto generated end-user documentation. The bottomline is, don’t use comments as excuse to write imperative code. Always write declarative.