Hacker News Reader

Comment by dzdt | Hacker News Reader

I have had the pleasure to work with lots of other people's code of varying styles and quality. Nothing is harder to read and understand than code which is deeply nested calls from one little helper (or wrapper) function to another. Nothing is easier to read and understand than code which just flows straight through from top to bottom of a big function.

There are other tradeoffs of code reuse and speed and worst-case-speed and probability of introducing bugs. If you haven't read the article, do, its worth it.

I love that Carmack tries to measure which styles introduce more bugs! Who else does that? Seriously, I would love to see more of that.

View on HN

I don't think I can agree with "Nothing is easier to read and understand than code which just flows straight through from top to bottom of a big function" in the general case.

I will agree that if you are coding in the kind of environment Carmack is talking about, where you are writing code which interacts with massive shared global state, that purely procedural structured code is easiest to understand, because you can be sure that you can see all interactions with global data structures in one place.

But if you don't have massive shared global state, I'd argue that calling subfunctions is a hugely valuable aid to understanding, since it allows you to reason much more about the way data dependencies flow through code when you can be sure that a call to a function means that that function can only act on the data structures passed in to it and is guaranteed not to affect anything else. I would much rather in that case see:

   a = subOperationA(arg)
   b = subOperationB(a)
   c = subOperationC(a, b)
   d = subOperationD(b, c)
   return d

than see those three suboperations inlined and have to figure out for myself how the data dependencies flow through the code.

Decomposition into functions and routines can make some sort of conceptual sense. This can be like the "chunking" that advanced chess players do, allowing them to remember entire board positions. Often, programs that are a pleasure to read have a structure which makes internal sense or which can be attached to an outside concept. Doing this optimizes for programmer reading time.

Isn't this a bit of a strawman, though? All too often, you instead get the likes of:

    a = subOperationA(a, b, c, d, e, f, g, h, i)
    b = subOperationB(a, d, e, f, g, h, i, j, k)
    c = subOperationC(d, e, f, g, h, i, j, k, l)
    return c

And then some poor fool breaks each of those up into about 8 functions each. So, you click into subOperationA to find it is subOperationAa chaining to subOperationAb,....

My gripe is when we argue against having the full solution in your mind as you work the pieces. Logically, it makes sense to reduce everything down to named things. Cognitively, that is expensive.

And yes, I'm responding with an equally opposing strawman. I am beginning to reject that there is a "one true answer."

> I am beginning to reject that there is a "one true answer."

There are basically no guidelines that always apply. Novices should stick to them, and people with more experience can recognize when they don't apply.

It's usually very safe and convenient to not inline pure functions. At least while debugging.

This is not really about subroutines, it's about abstractions. Good abstractions decrease cognitive load, bad ones increase it. The one true answer is to aim for good abstractions, and not factor code into subroutines at arbitrary boundaries.

For example, adding two n-length vectors is a good abstraction ("vector_add"). Adding two n-length vectors then multiplying the magnitude of the result by 3 is a bad abstraction.

The sooner you learn that there are no hard and fast rules, the easier life will be for your teammates and for anyone you try to lead. Most of the conflicts I have with my lead boil down to him wanting to resolve a decision using a hard always/never dichotomy, and me wanting to use my best judgement.

Does any language have as a feature blocks that you must pass variables to? I tend to prefer larger functions but agree with your point. If I ever write (or extend) a language I am going include huge numbers of ways to make assertions or explicit limitations of various forms.

I like Jens Gustedt's proposal for annonymous functions in C (at the end of Modern C[1]) by extending the syntax for compound literals. That would in a way give parameterized blocks, except that what you pass would be at the end (although if you name the parameters the same as what you pass it should work).

I think the main point is that it is helpful to be able to easily follow all the code that executes from point A to point B (at least up to the point of whatever portability layer you use). If you can reasonably structure it so that you just need to hit page down to read that code (without duplicated code) then that will often be easier to read IMO. I don't find one or two levels of function calls to be hard to follow, but after that it quickly gets more difficult. I suspect preferences here may to some extent be influenced by how good your short term memory is (and how good your IDE is). But I suspect there are also significant differences in how often different programmers try to step through code.

[1] http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

You could do something like that with C++ lambdas and explicit capture.

    int a,b,c;
    // ...
    [a, &b]() {
      // do stuff
    }();

Good Lord yes. When I was working on point of sale machines for Toshiba, there was this unbelievable depth of inheritance and ridiculously deep callstack constantly, and it made fixing any minor bug take weeks.

* abstract class Connection would have maybe 3 or 4 methods;

* DataConnection would extend Connection and add a couple more methods that were specific to some proprietary protocol.

* POSDataConnection would extend DataConnection and wrap this proprietary protocol for POS machines

* ControllerDataConnection would extend POSDataConnection because a Point of Sale controller is technically a POS machine with a bit more functionality (Really just a couple flags turned on).

* There was plenty more in between; it's been so long now that I've forgotten it all.

It's just like we all learned in college! Object Oriented programming is supposed to model real-life! Except no, it's not. That's stupid and complicated.

Now the part of the OS that was C/C++ was absolutely beautiful. It took the UNIX style of programming / applications seriously; every little piece was its own program, and it worked flawlessly. Anyone could jump in and get to work immediately because it was so well written. You could follow any program top to bottom and it just... made sense!

> it made fixing any minor bug take weeks.

My god.

A lot of these fancy language features sound good on paper but can be so abused that even just coming to understand the code takes up too much space in your head.

https://twitter.com/davidcrawshaw/status/507268175256231936

This is part of why I am so in love with Go. I have never read Go I couldn't understand. It's very clear at heart. I have read through much of the standard library and it all makes sense.

Do you think that's that's because the language inherently makes things readable, or is it simply because the language is too new to have popular anti-patterns?

The simplicity of the language and some of its choices really force you to do things a certain way that comes out almost universally legible instead of going with what may feel easier or "clever" to write. This is why it's so widely criticized (which doesn't mean that some of its criticism isn't fair).

Also gofmt having the last word on what code is acceptable and what isn't helps kill a lot of arguments that aren't worth having.

In a way, it's like the Go team chose to write something that has some of the coder UX of Smalltalk, but in a C-like statically compiled language. There is a useful region of language design space around the "simple language" concept, and they seem to be making the most of that particular design space maxima.

The team promotes heavily dead simple code over PL abstractions. Taken from some golang con slides where they said there would be nothing new in go, only perf and bug removal for a while.

It's an active choice of the language to not allow many syntactic sugars that make the code have a much higher learning curve.

https://www.youtube.com/watch?v=rFejpH_tAHM is a good overview.

Emphasis belongs on abused. Interfaces are swell. Subclasses of classes which implement an Interface are swell too, when they extend simply by altering the way said interface is achieved. When you subclass to "add more stuff", however, you get the kind of nonsense described.

The problem, in my opinion, is that the Java community (generalizing, I know) decided to bless that abuse as a best practice.

In many ways I'm terrified by Java programmers who have never heard of pattern abuse.

This is definitely not what you learn on college. If you use inheritance instead of composition it is your problem, not OOP problem. You can do the same mess with procedures and structs. OOP is not here to magically solve programmers bad design decisions.

> This is definitely not what you learn on college.

That is definitely the way I was taught OOP in college. I came out thinking it as a steaming, overcomplicated pile of shit. I have since learned better. Of course, there is a whole world of enterprise programmers for whom what was described is "proper" OOP.

Did you attend an "encapsulation, polymorphism, inheritance are our holy buzzwords" (yuck!) kind of technical college or a "focus on messaging patterns" (yay!) kind of technical college? The former kind tends to do that to people.

I actually got this out of a College of Engineering at an actual university. It was mostly the former.

When I learned OOP it was all about inheritance. Only later I realized that aggregation is much easier to handle and that functions that take well defined input and return a value without side effects are easier to maintain.

It's never been all about inheritance, they just forgot to tell that to Stroustrup and Gosling. ;)

Maybe I didn't go to a good enough college, but this is what I was taught. Either way though, this is not how I do OOP.

It is what I had to deal with, though.

After working on some "enterprise" systems myself, I came to the cynical conclusion that Java/C++/C# were never meant to actually solve problems, but to introduce unnecessary complexity and brittle-ness which eventually, inevitably, leads to the hiring of "consultants" for support or new features at exorbitant prices.

These languages, as well as things like WSDL/SOAP, are the late 90's/early 00's snake oil designed to woo clueless manager-types into funneling money to consultants and 'architects'.

I worked a lot with those types and saw the futility of suggesting 'simple' solutions to simple problems - everything had to be over-complicated to justify their salaries.

It left me pretty bitter towards that whole business model. Then again, there's lots of money to be made there....

Ugh, yes. The inheritance tree is just a line, of 4 or more segments.

  interface -> abstract -> base -> TheOnlyImplementationInstantiated

Repeat for a couple more chains, and one line bug fixes require visiting a dozen files to figure out.

"It's just like we all learned in college! Object Oriented programming is supposed to model real-life!"

It is - in execution (message passing), not in taxonomies. You can't model the taxonomies because all set-in-stone languages are inadequate for that (see SICP, for example). Also, it sounds like someone had an inheritance mania on your project. That's an instant loss right there. (But maybe the language used didn't allow for anything better? C++ is notoriously bad in this respect, for example.)

While I agree deeply nested calls are bad, I've also had the pleasure of inheriting a an application with several, muti-thousand line functions and those are not fun either.

In code as in life, all in moderation.

Couldn't agree with you more. I get the impression that a lot of people in this thread have never worked on behemoth, million-line enterprise code bases. Cognitively speaking, 4 nested thousand-line function calls is equally as bad as 15 nested 10-line function calls.

> In code as in life, all in moderation.

Beautifully said. Both methods (procedural vs. object oriented) give you different ways to shoot yourself in the foot. Instead of picking one or the other, it's more important to manage the scope at which your project grows. You have to avoid falling into the traps of each style.

Wait, you are comparing 4000 lines of code to 150 lines of code? How does that make sense?

If you modify your example to 400 nested 10-line function calls, how does that change your comparison?

Sometimes that is just inherent in the problem. If a a few thousand lines are actually needed to solve the problem, it will be somewhat hard to deal with whether they are all in one big function or broken up into many functions. One option may be marginally less annoying than the other, depending on what you are doing, or preference perhaps.

But sometimes it is just a "Such is life" situation.

I think it depends on whether the problem lends itself to abstraction or not. If I have a problem that requires 1000 lines to solve several large system of linear equations, I'm absolutely going to be separating that out. On the other hand, if I have 1000 lines of "if in country A, apply this tax rate", then I'm not going to separate it, because there is no underlying abstraction to use.

That's actually one of the more reasonable uses for OO; have an interface that defines 'apply_tax_rate', and a bunch of implementations for each, so you only have a single line in your function (instance).apply_tax_rate. Of course, that leads to your actual implementing code being scattered in different classes, and that can be a pain, too.

If a functional language, I'd prefer each being its own function, with the case matching in a single, standalone file that returns the appropriate function based on whatever. That way you still get just apply_tax_rate(type, amount) in your main calculation function.

A problem that genuinely takes a few thousand lines to solve doesn't sound "hard to deal with". It sounds just the right size for a module or tool that solves a problem big enough to be non-trivial, but small enough to be solved well.

However you end up solving it, it is way to big for a single function. On the other hand, a moderate bunch of functions can do it nicely -- and at that scale you don't need big complicated object-oriented abstractions other than the external interface itself.

You are saying something I highly doubt you want to be saying.

My "problem" is an online store. It is about 75,000 lines of code. It needs all 75,000 to solve the problem. What you are saying is that it would be "somewhat" hard to deal with whether it is all in one big function or many functions.

But in reality, one big function would be incomprehensible. It is vastly easier to deal with broken out into many functions.

The worst example of this I ever saw was an old macOS helpdesk application (@1995) that had a 14,000 line main event loop and the entire application was a single 29,000 line C file. Just typing at the bottom of the file was agonizing. We tore the whole thing apart and put it back together as a real app with include files and everything.

I was thinking about the issue of nested code the other day -- isn't it (mostly) an editing environment problem? I mean, if my IDE can detect that a method is pure, couldn't it do a little magic (e.g. provide a different coloured background, some dotted boxes, etc.) and show me the inlined code right there? It doesn't seem wise to architect your codebase around the deficiencies in your tools, since one is (hopefully) going to long outlive the other.

[1]: https://dubroy.com/blog/method-length-are-short-methods-actu...

Oh, i like this idea. Imagine your IDE just being able to substitute method calls that are just calling single line methods, for viewing only. Or even being able to refactor them in-line, but keep them in private methods?

Particularly if the editor can do things like constant folding and branch elimination based on constants that are being passed at that point.

That's just the editor doing the compiler's work at edit time, though. I know that Chuck Moore has always advocated extreme early binding, but that really is usually associated with Forth, not with mainstream languages.

I didn't mean that the editor would change what was presented to the compiler, just that it would simplify for the user when expanding the use of helper functions.

With Visual Studio, you can visually inline the definition of a function below its call by selecting "Peek Definition", which is close to what you're saying.

You can only do it one at a time, and it's for quick scanning of what the function does, though.

Hmm, wonder if I can coax Sublime into doing that. It's a little closer to IDE-type functionality, which it's pretty weak on (refactoring is terrible for Ruby with it).

I think Jetbrains ide's also have this. It's been a while though.

Visual Studio has had that for awhile now.

http://msdn.microsoft.com/en-us/library/dn160178.aspx

VSCode has this as well.

> By making your methods shorter, you’re just trading one kind of complexity for another.

Oh, I want to frame this and put it on the wall.

I can't stand code where even the simplest thing is implemented as a giant tree of sub-5-line functions nested 15 deep (and probably, for bonus points, scattered across half a dozen files).

I don't know, I'd prefer:

config_filename = get_config_filename()

config = read_config(config_filename)

endpoint_url = config["endpoint_url"]

auth_data = get_auth_data(endpoint_url)

to just dumping all of that inline.

Is get_config_filename() a large function that gets the filename directly or is the end result nested another hundred lines of callstack down? If it is a large function that directly returns results then that is my pick, high level "story" with shallow, direct access to the details. No dicking about for half an hour trying to figure out where A, B, or C happen, yet hidden details for when you are focusing on a different part of the code.

Except that is a false dichotomy. This isn't about inlining 'pure' functions (I know your example is IO, but they aren't mutating your program's state), it is about avoiding functions that are only used once and/or that mutate state.

I've used the same technique - instead of creating a function that might be awkward due to all the inputs and outputs, I'll create an inner scope {} with nothing around it. Only the variables that it modifies/initializes are left on the outside. This is a simple way to enforce more of a data flow style within a function and ends up being a useful organizational tool. It is also similar to 'let' in some languages.

This. In the article, Carmack does suggest just this, although its not as explicitly called out.

If your methods are functional, then

    int fancyNumber = calculateFancyNumber();

Can be inclined cleanly/equivalently as:

    int fancyNumber;
    {
        // [Mathy stuff redacted]
        fancyNumber = someIntermediateVariable / anotherIntermediateVariable;
    }

And with c++11 you can use a lambda capture to make it even cleaner (I'm not sure if this is the right syntax)

[&fancyNumber] { // [Mathy stuff redacted] fancyNumber = someIntermediateVariable / anotherIntermediateVariable; }();

That's all good, unless you need to do it twice. Then you're repeating yourself, and you're in a whole other world of pain next time you want to change some of the code.

2x copy-paste is a "whole other world of pain"? I've worked in shops where the rule was you didn't make a method or otherwise refactor until there were 3 repeats of the same code. If you're in an environment where you can make the prophylactic search for that code pattern, this works well. (I could easily make searches with full syntactic expressiveness.)

> 2x copy-paste is a "whole other world of pain"?

Yep, namely when someone fixes a bug in one of the paths but forgets to update the second.

Sorry, but this isn't a "whole other world of pain." Increase the multiple to dozens, hundreds, or thousands. That is a whole other world of pain. (I've worked in a project that started with literally 500 re-implementations of doubly linked lists.)

Best of both worlds in Javascript. Use "IIFE" to make an anonymous function and call it. The editor lets you elide the function if you don't want to see the details, or leave it "open" if you want to read it.

If it turns out said little dance needs to be done twice, instead, assign the function expression to a name (in an appropriate scope) and call it twice.

Nested funcs/procs in Pascal were useful for this kind of local partitioning, as well (before C; C++; Java came and peed in the development mindshare pool), even if you couldn't make closures out of them.

> Nothing is easier to read and understand than code which just flows straight through from top to bottom of a big function

It really depends on how long the function is. Ignoring stuff like variable declarations and verifying constraints at the beginning of a function, I personally find anything longer than a screen or two is usually better off (in terms of readability) being in its own function.

I wonder if we've over-focused on the inlining vs functions-for-modularity thing here. Fundamentally, the primary objective is to express code in a way that is clear to the reader for maintenance. Secondarily, the code must work with the compiler to achieve the desired level of efficiency in speed or resource usage.

I have come to interpret this as: We are language designers. This isn't about functions. This is about building a language for the business case that is comprised of primitive expressions, means of combination, and means of abstraction. If the language is clear to the reader, expressing the problem well, it should be easier to detect problems or extend the existing language and its uses.

We are language designers already: If you build a traditional class with a bunch of methods, that is a language with how to deal with the concept embodied by the class. It must be held to the same standards of any language, DSL, or API design.

I like to remind people that we don't tend to dig into the code behind printf(); we trust what it does. We have years of experience using that primitive. It's a great example of a function that has been through many revisions due to security issues, untrustworthy in its inception. What is key here is trust that a primitive does as advertised so that one does not have to dig into its source code repeatedly. Nested functions are not an issue in the presence of trust.

My "secondarily" clause has a fatal flaw: Many languages are not suited for building languages while simultaneously not trading off speed and resource usage. The ones with pre-runtime macros/templates assist us developers in the building of expressions beyond the limitations of the base language with minimal fuss.

"This isn't about functions. This is about building a language for the business case that is comprised of primitive expressions, means of combination, and means of abstraction."

Heh. Anyone up for a Sussman&Abelson drinking game? :D

My experience, limited though it is, is that there is a trade-off between how easy it is to write code vs how easy it is to read.

Abstracting with functions is very beneficial to the writer because, well, they come up with the abstractions and know what they mean.

I feel they are less helpful to the reader, except perhaps at a very cursory level. If the reader is trying to actually understand the code to be able to modify it, many abstractions are actually a hindrance.

For example, in lisp, it's a fairly common practice to essentially write a DSL for the problem you are solving. It's a great tool to be able to do this easily and quickly. You can build massive and complex programs without overloading your brain.

However, for a reader new to your code base, there is a huge cognitive load to try to decipher the DSL. It's intuitive for the writer, because they invented it, but for the reader, it is a hurdle to overcome.

Once you learn someone's DSL, it's a very powerful tool now for you too. But when every project has it's own, it's really too much to bear.

If you write and document your DSL well, the cognitive load is minimal, unless you need to plunge into the implementation. And it's not hard to write a DSL: I wrote what looks a heck of a lot like a DSL for a very simplistic piece of IF I wrote with maybe 5 exposed functions, and no macros.

Big functions are hard to unit-test.

The article includes comments from Carmack from 2014 saying he now favours breaking the code up into pure functions.

I had the "pleasure" of working on a system that made recursive calls that made other recursive calls that made other recursive calls, which made recursive calls to the database. I'd helped design it originally but this was not at all what I intended. I had a medical emergency though that knocked me out of work for quite a while and when I got back this unreasonable thing was what they had built.

From my experience a lot of nested functions usually means spagetti code created from huge functions which were split on radnom points to small functions (which mixed abstraction levels and still do multiple things at once). If you properly design your data model there will be no huge functions and no deeply nested calls.

You can definitely break up a function's contents into logical nested functions... Why are you saying "random points"?

Nested functions can actually allow you to even out your abstraction levels... Just group lower-level operations in more deeply nested functions. It's sort of the functional equivalent of extracting a group of similarly-leveled concepts into a new object in the OO approach.

Not sure if you were talking about C++, where my point probably doesn't apply... (Lack of nested function support, AFAIK)

I think the biggest problem with the "big function" is that it tends to lead to code duplication. If taskY is in bigFunction, but taskY is needed in otherPlaces then people tend to just copy paste taskY in otherPlaces.

If another developer joins the team, then he might not have noticed that there is a taskY and may end up writing his own, completely different, implementation in yet another place.

For C, I tend to go the big function route but I usually try to put extra braces with comments to isolate subtasks from each other within the big function. Then I can pull out the tasks into functions if I see that I need them in more places. I don't know how my old code is doing so I don't know if anyone has followed my lead in those projects.

I don't know if you read the whole article but the exact same thing is suggested towards the end.

We do have Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity). I see this often enough to understand how important it is.

Isn't cyclomatic complexity just about the number of paths through code? It seems like (statically resolved) nested calls, as long as they don't loop or branch themselves, shouldn't increase cyclomatic complexity.

There may be subtle branches like error handling that can impact it for otherwise non branching code

Maybe an editor can allow you to expand function calls so they appear in-line when you want to read them as such. Often I do have the nested call hell, but the alternative is an absurd amount of writing/testing things twice.

I'd have thought at least a few people measure bug ratios of different coding styles?

It's a big motivator in terms of deciding up best practices. And whenever I fix a bug, I try to identify the root cause. If it was a coding pattern to blame (as opposed to bad process or design) I look for ways to eliminate that pattern.

My most recent real-life example: Jackson + Afterburner

I hand wrote a LA(1) style parser (and lexer) for JSON, because I wanted to experiment with a source code generation notion I had (vs reflection, or bytecode generation). I was surprised that in micro benchmarks, Jackson + Afterburner is still twice as fast as my stuff. I had to understand why.

Turns out it does the lex/parse equivalent of unrolling and inlining (cut and paste) absolutely everything. The code is utterly baffling.

My implementation's jar is ~30Kb, fast enough (faster than all but Jackson + Afterburner, Boon), stupid simple, and works the way I want, so I'll keep using it for my projects.

There is a very interesting discussion on how to go about doing this in this video https://youtu.be/QM1iUe6IofM?t=37m41s

C++11 has given us a new and wonderful world of this small function debugging horror, since we can now gin up lambda functors that have no name, that have a type with no known name, and don't play well with the debugger (good luck figuring out why your program is spending all of its time in "operator()").

Even relatively old generally and lldb show location information correctly for lambdas.

Templates are usually more of a pain to debug.

How do you mean they show them correctly? Perhaps you are right but I often see them attributed to std::function::operator() in the header <functional>, because someone has assigned the lambda to a class member field or function argument of type std::function. When the function has more than one caller it can be a nuisance trying to figure out which caller's lambda is the one being called. The only way I know of to identify them is to examine the full template expansion which is often a kilobyte of metaprogram gibberish.

Can you not see the call stack for your lambda, as for any function?

YES.

Nothing is more annoying than a pointlessly huge call tree where the function is called from a single place.

Procedural code is easier to reason about. OOP is easier to change. Unless it is Evil OOP, with deeeeeep hierachies and done without understanding why and what for.

Reply on news.ycombinator.com