The code on the left is more readable. It is easy to follow and see what is happening at each step.
That being said, the code on the right is easier to maintain. If the requirement comes down the pipe that we now need to support a new pizza topping it is easy to jump to the add toppings method using the IDE instead of scanning the entire monolith procedural function. Or if we now need to add support for take-and-bake, we can just modify the small entry method.
This also assumes that we are not needing to reuse any of these methods. If you want to add toppings to a sandwich or a salad, better write another huge method like the one on the left, or add a ton of nested if/else or switch statements. If you use the style on the right you can reuse the add toppings method without worrying about if you should preheat the oven for a salad.
The author chose a very simplistic requirement for an example and it is all well and good until you let it fester in a code base for ten years, with multiple interns maintaining it and end up with a huge spaghetti code monster to deal with.
That being said, the code on the right is easier to maintain
That depends if you guessed how it is going to change correctly. All too often you don't and some weird requirement comes in that your abstraction does not account for and makes the whole thing really awkward. Which tends to lead to spaghetti abstractions that are just as bad to maintain as spaghetti code.
For the context of the code he has given the code on the left is easier to maintain. At least at the start. Once it becomes more complex and more requirements are added and start to make it less maintainable that is the point abstractions should be added. Linear code is far easier to find and add abstractions to that already highly abstracted code.
The problem most of these examples and counter examples make is only showing simple code and assuming that you always want to apply the patterns of abstracting things or not. In both cases the code becomes a mess over time as too many abstractions are equally as bad as not enough abstractions. And where those lines are depends on the code you have in front of you. There are no good rules out there ATM for all cases. Just some that sometimes work, and others that work in different situations. Better to learn all of them and when they are most useful to apply. And don't be afraid to rip out some bad abstraction (that may have once made sense).
Personally I would do something in the middle of both those solutions. Why is the oven preheat not a method on the oven object? Makes the overall method simpler and still linear. No need to abstract every part of the function into methods, but some do many good candidates for that.
The problem most of these examples and counter examples make is only showing simple code and assuming that you always want to apply the patterns of abstracting things or not.
This is the real problem. Without context of what the project is for we can only speculate on what the "best practice" is. If my problem is that I have a directory with 2000 videos in it, and I need to process all the ones with an English language track, I am going to write a one-off bash script, and not a huge C# project filled with the OO concepts.
But if the method is one of 10,000 needed in a huge project, then sticking with the coding guidelines of the whole project is more important for maintainability. A dev coming in 36 months later who is familiar with the code base would have less problems going through an abstracted setup, just because they have experience with the project and can make assumptions from that.
then sticking with the coding guidelines of the whole project is more important for maintainability
This can also be a sticky point. When they make sense sure, but sticking to them no matter what can cause more problems. Far too often I have seen some people try to stick with they style/way something was written before because they want to respect the code that was there before or don't understand why it was done that way. Only to squeeze their solution into it in an awkward way and bend over backwards to get it working right. But if they were to ask the original developer why it was done that way the answer is often just could not think of a better way at the time or I cannot remember any more or seemed like a good idea at the time, but it has not aged well.
Large projects are often layers of changes layered on other changes in additive ways that eventually lead to some very weird and convoluted structures. In those situations I do actually find undoing the layers of abstraction and just inlining all the function calls lets you make some massive simplifications and lets you better see new more robust abstractions you can then apply - things that would never be obvious from the original overly abstract code.
It is worth asking other devs though. Occasionally there is a legitimate reason for some jank in the code that cannot be gotten rid of some external reasons (ideally if you find these you should add a comment to explain this though).
The right is also easier to write tests for, which is crucially important to me.
Do not solve maintenance problems that you don’t face.
On the other hand, not anticipating and preparing for eventualities can be just as bad.
Nothing quite so permanent as a temporary solution, especially those difficult to maintain.
Preventing is better than suffering through high technical debt after a mistake (but don't get too paranoid, either)
The code on the left is more readable. It is easy to follow and see what is happening at each step.
That being said, the code on the right is easier to maintain. If the requirement comes down the pipe that we now need to support a new pizza topping it is easy to jump to the add toppings method using the IDE instead of scanning the entire monolith procedural function. Or if we now need to add support for take-and-bake, we can just modify the small entry method.
This also assumes that we are not needing to reuse any of these methods. If you want to add toppings to a sandwich or a salad, better write another huge method like the one on the left, or add a ton of nested if/else or switch statements. If you use the style on the right you can reuse the add toppings method without worrying about if you should preheat the oven for a salad.
The author chose a very simplistic requirement for an example and it is all well and good until you let it fester in a code base for ten years, with multiple interns maintaining it and end up with a huge spaghetti code monster to deal with.
That depends if you guessed how it is going to change correctly. All too often you don't and some weird requirement comes in that your abstraction does not account for and makes the whole thing really awkward. Which tends to lead to spaghetti abstractions that are just as bad to maintain as spaghetti code.
For the context of the code he has given the code on the left is easier to maintain. At least at the start. Once it becomes more complex and more requirements are added and start to make it less maintainable that is the point abstractions should be added. Linear code is far easier to find and add abstractions to that already highly abstracted code.
The problem most of these examples and counter examples make is only showing simple code and assuming that you always want to apply the patterns of abstracting things or not. In both cases the code becomes a mess over time as too many abstractions are equally as bad as not enough abstractions. And where those lines are depends on the code you have in front of you. There are no good rules out there ATM for all cases. Just some that sometimes work, and others that work in different situations. Better to learn all of them and when they are most useful to apply. And don't be afraid to rip out some bad abstraction (that may have once made sense).
Personally I would do something in the middle of both those solutions. Why is the oven preheat not a method on the oven object? Makes the overall method simpler and still linear. No need to abstract every part of the function into methods, but some do many good candidates for that.
This is the real problem. Without context of what the project is for we can only speculate on what the "best practice" is. If my problem is that I have a directory with 2000 videos in it, and I need to process all the ones with an English language track, I am going to write a one-off bash script, and not a huge C# project filled with the OO concepts.
But if the method is one of 10,000 needed in a huge project, then sticking with the coding guidelines of the whole project is more important for maintainability. A dev coming in 36 months later who is familiar with the code base would have less problems going through an abstracted setup, just because they have experience with the project and can make assumptions from that.
This can also be a sticky point. When they make sense sure, but sticking to them no matter what can cause more problems. Far too often I have seen some people try to stick with they style/way something was written before because they want to respect the code that was there before or don't understand why it was done that way. Only to squeeze their solution into it in an awkward way and bend over backwards to get it working right. But if they were to ask the original developer why it was done that way the answer is often just could not think of a better way at the time or I cannot remember any more or seemed like a good idea at the time, but it has not aged well.
Large projects are often layers of changes layered on other changes in additive ways that eventually lead to some very weird and convoluted structures. In those situations I do actually find undoing the layers of abstraction and just inlining all the function calls lets you make some massive simplifications and lets you better see new more robust abstractions you can then apply - things that would never be obvious from the original overly abstract code.
It is worth asking other devs though. Occasionally there is a legitimate reason for some jank in the code that cannot be gotten rid of some external reasons (ideally if you find these you should add a comment to explain this though).
The right is also easier to write tests for, which is crucially important to me.
Do not solve maintenance problems that you don’t face.
On the other hand, not anticipating and preparing for eventualities can be just as bad.
Nothing quite so permanent as a temporary solution, especially those difficult to maintain.
Preventing is better than suffering through high technical debt after a mistake (but don't get too paranoid, either)