Introducing Tombstones for PHP

Earlier this year I took over that project at my new company. A project, that existed for many years and has been continuously growing. My first impression, it was missing some love recently. The repository was cluttered by many files, that could assumed to be dead code. Unfortunately, you never know. Although I felt the urgent need of removing stuff, I was able to keep myself from blindly deleting files and breaking everything ;). The mission was clear: Cleaning up the project, without breaking things.

Read more

Books: Clean Code

I want to start a new series of posts, where I want to present some books. They’re books that I can recommend to developers and people working in the field of software development.

Let’s start with a book, that every software developer should have read. It is “Clean Code” by Robert C. “Uncle Bob” Martin.

"Clean Code" by Robert C. Martin
“Clean Code” by Robert C. Martin

As the title might tell you, it is about techniques and rules to help you to writing high quality code in such a manner, that it becomes easy to understand and and easy to maintain. The book has a chapter for each aspect of software – naming, formatting, structuring, error handling – to name some of them. After defining a set of dos and don’ts, the following two chapters demonstrate how to apply them by refactoring a piece of software step-by-step.

I consider myself having a pretty good “code sense”, which means that I naturally know, how to structure things and write good code. Therefore most the book wasn’t such a surprise for me, but I discoverd some aspects, that I haven’t thought about before. Instead I just did it. The book helped to understand, why it is a good idea to do certain things, instead of just doing it because it feels right.

Why should you read it: You’re creating software, especially together with other people in a team. You care about the quality of your work and you want to improve your sense for good code.

5 years later (2020-08-17): I’ve found this blog post, which is taking a critical view on the recommendations from the book. I have to say, I do agree with the arguments made in the blog post, but I still believe there’s some usful advice in the book that can help you improve your code. So my advice would be: Read it, but be critical about it. You don’t have to follow everything by heart to produce better code. If some rules don’t make sense to you, don’t do it. The important thing to take away is: be critical about your own code. Imagine someone else reading it without the knowledge you have (right now) and write your code in a way to help them understand your intention and what’s going on.