It’s an amazing feeling when you see your app is coming to life and more features and decorations are added to it every day to make it better, and we are very close to the first fully functional version of the app.
Last week Islam and Hind decided to get rid of the RecyclerView that we were using in the app and extract all code from it to normal classes, and sure that what we did. That aroused a couple of problems that the RecyclerView has solved out of the box but after a pair programming session with Islam we solved many of these problems except for one that I had to solve it on my own, I couldn’t figure out the solution yet, but I am very confident that I am gonna find it soon.
A couple of weeks ago Islam told me about a book called “Clean Code” by Robert C. Martin, he told me to check it out because it will teach me lots of things. If you remember I mentioned clean code in a previous post. I didn’t have any chance to check the book until this weekend. So this week post will be a small peek into the book introduction and the first chapter that named “Clean Code”.
The book introduction starts with the comic above, and besides it’s very funny and accurate I think we all know that we need to write a good and clean code and keep a low rate of “WTFs/minute” for our code reviewers :].
The author mentioned many reasons for why writing bad code is a bad thing and what the cost of a messy code. He mentioned a story of a company in the late 80s that had a very popular app, lots of professionals used it, but after a couple of releases, users start abandoning their app because the app became sucks. An old employee of the company met the author after many years and told him that they rushed to put the product to the market, and their code was a mess and they continue developing and add more features in that mess to the minute they couldn’t manage that mess anymore. And the company brought down because of that bad code.
The author said that we probably come across bad code and be impeded by it, and we probably wrote a bad code ourselves trying going fast to meet the deadline and not to make our boss angry when you took times to clean up your code. So you say to yourself “it’s working now why we bother ourselves trying to clean it up the code now and let’s do that later”.
I learned there is a law called LeBlanc’s law, and no it’s not Matt LeBlanc, it’s another LeBlanc. The law says “Later equal never”. I personally knew this law is true, lots of times I had to modify some parts of the code or rename some variables or functions and deal with some issues, and I say to myself “I will do that later”, and as LeBlanc’s law suggested I never did, and because there are so much new code to write and more features to add, the “I will do that later” list will increase and you will miss track after a while and it will turn up to a huge mess. The same story with cleaning your code.
The author mentioned that the messy code can cost you a lot, if you start very fast at the beginning of the project you will force to slow down along the way and your productivity level will decrease and it may actually reach zero. So taking the necessary time to keep your code clean is not just a matter of cost-effectiveness, it’s a matter of, and I quote the author words “it’s a matter of professional survival”.
The next part I had to quote because he describes it way better than I will ever do “Have you ever waded through a mess so grave that it took weeks to do what should have taken hours? Have you seen what should have been a one-line change, made instead in hundreds of different modules? These symptoms are all too common. Why does this happen to code? Why does good code rot so quickly into bad code?”
The author said that new developers(with experience less than a few years) know bad code will slow them down but they do it anyway to meet the deadline , but true professionals know that with a messy code you will not make the deadline, and you have to keep your code as clean as possible all the times, because this is the only way to make the deadline.
So What is the Clean Code?
The author asked many of well-known and deeply experienced programmer about what they think about clean code, you may recognize some of them. I will quote two of these programmers.
Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language said “I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”
Michael Feathers, author of Working Effectively with Legacy Code said “I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft.”
I think now you want to know what the author himself thinks clean code is?. Here I quote his words “What about me (Uncle Bob)? What do I think clean code is? This book will tell you, in hideous detail, what I and my compatriots think about clean code.”
So that’s mean we need to continue reading the book, till now for me this book is very promising and I will keep you updated while I go through different chapters. Now I will leave you with this question “Do you now appreciate the value of writing clean code?”. Share with us your thoughts in comments, but for now, that’s it for this week.
Till next week.
