The left side (linear) looks like the code I write while I’m trying to figure out whether I understand the problem or I’m not quite sure what all I need to do prove that I can (or cannot!) solve the problem.

The code on the right, with all the “abstractions” looks like the code I end up with after I’ve got everything sorted out and want to make things easier to read, find, and maintain.

I actually find the code on the right easier to read. I treat it like a well written technical manual. For me, understanding starts with time spent on the table of contents just to get a sense of the domain. That is followed by reading the opening and closing sections of each chapter, and finally digging into the details. I stop at any level that meets my needs, including just picking and choosing based on the table of contents if there is no clear need to understand the entire domain in order to accomplish my goal.

I’ve preferred code written in that “abstracted” style since discovering the joy of GOSUB and JSR on my VIC-20.

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.

The right example is poorly executed. The left example is fine, but has one crucial deficiency: it’s not very modular, which makes it difficult to test and scale. Big problems need to be broken down and managed in discrete steps, and this is also true of computer code.

The left example is like running a pizza shop where you explain all the steps to everyone and then let everyone loose at the same time to make a pizza. The right example is like creating stations and delegating specific responsabilities to one person at a time.

The former creates redundancy and is manageable at small scale. But as you grow, you find that the added redundancy is of no additional value, while you end up with chaos, as people argue and fight over the process.

Can you imagine five developers working on the monolithic pizza code all at the same time? Total chaos. Better to have one developper assigned to baking, another assigned to prep, etc.

This is exactly the point made in this 2010 article that’s probably one of the things I link to most often in online discussions.

https://whatheco.de/2010/12/07/function-hell/

Also, the real problem with code on the right in OP is all the state mutations made to the arguments passed into the functions.

Not too familiar with golang, but this really could use some sort of builder pattern or something, if you’re going to mutate the object. Or a more functional style with just a pure function mapping an input “order” to output “toppings”, etc.

There are plenty of ways to make the bad design on the right better without stuffing everything into a single function, so the whole premise is a bit of a false dichotomy.

People have already mentioned testing and abstraction, but what about other developers and security?

Spaghetti code all you like in solo projects. But if someone else is coming along to debug a problem in their toppings, why would you make them remember anything about baking or the box when it’s completely irrelevant?

And why should the Box object be able to access anything about the Oven’s functionality or properties? Enjoy your oven fire and spam orders when someone works out they can trigger the bake function or access an Order’s payment details from a security hole in the Box object implementation.

It’s not just about readability as a narrative, even if that feels intuitive. It’s also about memory management, collaboration and security.

The author’s primary gripe, IMHO, has legs: the question about the oven’s relationship to baking is buried as part of bake() and is weird. But the solution here is not the left-hand code, but rather to port some good, old-fashioned OOP patterns: dependency injection. Pass a reference to an Oven in createPizza() and the problem is solved.

Doing so also addresses the other concern about whether an Oven should be a singleton (yes, that’s good for a reality-oriented contrived code sample) or manufactured new for each pizza (yes, that’s good for a cloud runtime where each shard/node/core will need to factory its own Oven). The logic for cloud-oven (maybe like ghost kitchens?) or singleton-oven is settled outside of the narrative frame of createPizza(). Again, the joy of dependency injection.

To their other point, shouldn’t the internals of preheating be enclosed in the oven’s logic…why yes that’s probably the case as well. And so, for a second time, this code seems to recommend OOP. In Sandi Metz style OOP in Ruby (or pretty much any other OOP language) this would be beautiful and rational. Heck, if the question of to preheat or no is sufficiently complex, then that logic can itself be made a class.

As I write, I thought: “How is golang so bad at abstraction?” I’m not sure that that is the case, but as a writer of engineering education, I think the examples chosen by the Google Testing Blog don’t serve well. Real-world examples work really well with OOP languages, fast execution and “systems thinking” examples work great with golang or C. Perhaps the real problem here is that the contrived example caters to showing off the strengths of OOP, but uses a procedural/imperative-style-loving language. Perhaps the Testing Blog folks assumed that everyone was on-board with the “small factored methods approach is best” as an article of faith and could accept the modeled domain as a hand wave to whatever idea it was they were presenting.

I’ve worked in a company that used linear code most of the time. And at first it felt really easy to read and work with. If you wanted to know what happened, just jump to the entry point, then read over the next 200 lines of code, done. No events, no jumping around between 10 different interfaces, it worked at first.

But over time it became a total mess. A new feature gets added, now those 200 lines get another if/else at several spots, turns into 250 lines. Then a new option is added that needs to be used for several spots, 300 lines. 400 lines. 500 lines… things just escalate.

You can’t test that function and bugs sneak in far too easily. If you want to split it up later into new functions it’s going to be a major hassle. There also was no dependency injection or using interfaces, other classes were often directly called or instantiated on the spot. Code reuse was spotty and the reused functions often got 5+ parameters for different behavior.

It was horror after a while.

The company I work for now uses interfaces, dependency injection, unit tests, but all the way down a function might still have 50 lines tops or so. It’s slightly tougher to find out where things happen, but then much easier to work with. You need a certain balance either way.

Both styles have advantages and disadvantages. Fully procedural code actually breaks down in readability after a certain length, some poeple suggest 100 or maybe 200 lines, depending on how much is going on in the function.

Blanket maxims tend to to have large spaces where they don’t apply.

Additionally, the place where the code on the right is more likely to cause bugs and maintainability issues is the mutation of the pizza argument in the functions. Argument mutation is important for execution time and memory performance, but is also a strong source of bugs, and should be considered carefully in each situation. We don’t know what the requirements for this code are, but in general we should recomend against universal use of argument mutation (and mutability in general).

One downside with the code on the right is that it’s not obvious where the different functions might be called from. In the example on the left, we know that we’re not, say, adding toppings to a pizza that we’ve already baked. If we notice a bug in the topping adding function on the right, we might get tempted to reason about adding toppings as a general process that needs to handle all kinds of situations when in practice is doesn’t.

When you have single use functions like this it’s good to limit the scope of the function using whatever language features are available so that you can more easily reason about where it’s being called from

I sit somewhere tangential on this - I think Bret Victor’s thoughts are valid here, or my interpretation of them - that we need to start revisiting our tooling. Our IDEs should be doing a lot more heavy lifting to suit our needs and reduce the amount of cognitive load that’s better suited for the computer anyways. I get it’s not as valid here as other use cases, but there’s some room for improvements.

Having it in separate functions is more testable and maintainable and more readable when we’re thinking about control flow. Sometimes we want to look at a function and understand the nuts and bolts and sometimes we just want to know the overall flow. Why can’t we swap between views and inline the functions in our IDE when we want to see the full flow? In fact, why can’t we see the function inline but with the parameter variables replaced by passed values to get a feel for how the function will flow and compute what can be easily computed (assuming no global state)?

I could be completely off base, but more and more recently - especially after years of teaching introductory programming - I’m leaning more toward the idea that our IDEs should be doubling down on taking advantage of language features, live computation, and co-operating with our coding style… and not just OOP. I’d love to hear some places that I might be overlooking. Maybe this is all a moot point, but I think code design and tooling should go hand in hand.

The code on the right is better (though perhaps taken to an extreme) and what it comes down to is the code on the right makes you think in terms of the layers of the function when you make a change.

Linear functions provide very little friction to changes that (when you see the interaction through all the layers) are actually quite bad. The code on the left will – without extreme discipline – become spaghetti as the years pass. Even with extreme discipline as the lines of code in the function grow, and other comments are added, the actual flow of the function will be harder to see and harder to grok because it can’t all be put up on the screen at the same time.

It’s ultimately the same idea as minimizing side state/side effects. You want a bunch of small pieces that can be independently verified as doing their job, rather than one large thing that you can’t understand at a glance.

Learner here. I don’t like nesting single use functions. The moment I follow a function and it’s just another abstraction for more functions I start feeling dread. Also I can’t help but feel bad for cluttering the name space by breaking out single use functions in general, even if they’re private. Seeing the sentiment here, guess I gotta get used to it

I generally prefer a mix of the two, you have a chain of linear logic that pulls out clean chunks into methods when they get two complex or need repetition/recursion etc. I would rarely have a method that is just a list of function calls.

As with everything, there isn’t a one size fits all ideal solution, it depends on the exact code.