Comments

Oh yes, at least I remember I used to struggle with these definitions when I had less experience writing code. Like, ‘small functions are easier to read, split them up if they go over n lines’. You might get carried away with that kind of rules. Who am I kidding, I still struggle with these.

I like the practicality and a bit more higher level definition of bad code. More often than not these kind of definitions go way too deeply into the details, listing things such as how long a function should be, that are also very much context dependent. Giving these kind of definitions might even be unproductive when they are followed too literally.

I like the practical nature of this definition of bad code: It takes the focus to outcomes. Farley is also conscious about the fact that what qualities the code should have is somewhat context dependent. Same as with processes, it’s too easy to start arguing about the details with very limited practical utility.

Naturally this is my view based on my experiences. Did anything sound surprising or ‘wrong’ in this article to others?