I get the point the author is coming from. When I was teaching first year engineering students programming, the one on the left is how everyone would write, it’s simply how human intuitively think about a process.
However, the one on the right feels more robust to me. For non trivial processes with multiple branches, it can ugly real quick if you haven’t isolated functionalities into smaller functions. The issue is never when you are first writing the function, but when you’re debugging or coming back to make changes.
What if you’re told the new Italian chef wants to have 15 different toppings, not just 2. He also got 3 new steps that must be done to prepare the dough before you can bake the pizza, and the heat of the oven will now depend on the different dough used. My first instinct if my code was the one on the left, would be to refactor it to make room for the new functionality. With the one on the right, the framework is already set and you can easily add new functions for preparing the dough and make a few changes to addToppings() and bake()
If I feel too lazy to write “proper” code and just make one big function for a process, I often end up regretting it and refactoring it into smaller, more manageable functions once I get back to the project the next day. It’s simply easier to wrap your head around
bakePizza()
box()```
than reading the entire function and look for comments to mark each important step. The pizza got burned? Better take a look at `bakePizza()` then.
Might as well start with a solid foundation from the start though. The extra work is minimal so there isn’t much of a time cost to it. I wouldn’t call it overengineering, it’s just a different way to write code, and the way many naturally default to without really thinking about it.
Maybe it’s just me being bad at programming, but I used to do the right-hand style of programming and usually ended with wrong abstractions that were holding back development as requirements changed.
I get the point the author is coming from. When I was teaching first year engineering students programming, the one on the left is how everyone would write, it’s simply how human intuitively think about a process.
However, the one on the right feels more robust to me. For non trivial processes with multiple branches, it can ugly real quick if you haven’t isolated functionalities into smaller functions. The issue is never when you are first writing the function, but when you’re debugging or coming back to make changes.
What if you’re told the new Italian chef wants to have 15 different toppings, not just 2. He also got 3 new steps that must be done to prepare the dough before you can bake the pizza, and the heat of the oven will now depend on the different dough used. My first instinct if my code was the one on the left, would be to refactor it to make room for the new functionality. With the one on the right, the framework is already set and you can easily add new functions for preparing the dough and make a few changes to
addToppings()andbake()If I feel too lazy to write “proper” code and just make one big function for a process, I often end up regretting it and refactoring it into smaller, more manageable functions once I get back to the project the next day. It’s simply easier to wrap your head around
If the chef wants 15 toppings, then you start abstracting it. There’s no point in overengineering.
Might as well start with a solid foundation from the start though. The extra work is minimal so there isn’t much of a time cost to it. I wouldn’t call it overengineering, it’s just a different way to write code, and the way many naturally default to without really thinking about it.
Maybe it’s just me being bad at programming, but I used to do the right-hand style of programming and usually ended with wrong abstractions that were holding back development as requirements changed.