Sometimes you're on a team and you can ask co-workers to explain the code that they wrote. But it also includes people who you don't currently know: future collaborators, or people who will be maintaining your code long after you might be gone from your position or role. This includes your co-workers and collaborators who will be reviewing your code in the immediate future. It's a gift of time and convenience because it will help you get back into the code faster and spend less time trying to figure out what's going on.Īside from being a gift to your future self, it's also a gift to anyone else who will be reading your code. Making your code readable is a gift to your future self. But the reality is that we forget quickly. You might have all the context about the code in your mind right now, and you might think you're going to understand it in the future.
In some cases, the person who will be reading it is your future self. When you're putting effort into making code readable, who are you doing it for? In fact, it can you help achieve all of the other priorities: it makes it easier to write faster code, it makes bugs more discoverable, and it allows you to ship faster.
But I'm making the case that readability can be a number one priority, too. It's easier to make the case that code should be fast, bug-free, and shipped quickly. There are many competing priorities when developing software, and readability can sometimes become a second thought. The reality is that code readability is a big deal with significant consequences.
It's a reference to the fact that code can be impossible to read, and that the only moment when it can be understood is at the moment of writing. There's a joke in programming that some code is write-only.
0 kommentar(er)
