Hacker News Reader

Comment by lex-lightning | Hacker News Reader

The drawback of the microscopic function craze is you lose the ability to read a whole procedure from top to bottom. If some code is truly reused, break it out into a function with a good name, sure.

But in my domain I have seen countless one-line functions used in one place each, and it’s frustrating having to jump around the code (and add to my mental context stack*) rather than just putting some curly braces and a comment. Functions aren’t primarily meant as a hygiene mechanism. I really like the curly brace scoping in Rust.

I found my style partly by reading John Carmack and Casey Muratori’s coding philosophies and putting them to the test for myself.

* For a natural language analogy, consider the difference between parenthetical remarks and asterisks. You have to remember your place in the text.

View on HN

Mostly a problem with people who borrow their concepts of cohesion from MVC, but yes people tend to fundamentally misunderstand SIP and it results in over modularity.

IMHO that is a side effect of how we teach people how to program mixed in with orgs cargo culting acronyms and not the core concepts of ideas.

For real though. This was my biggest frustration when I was an SE.

Want people in a large organization to ignore your ideas? Speak them out loud.

Want them to follow them as dogma? Write a blog post under a pseudonym.

You should be able to read a function from top to bottom and it should show you the whole procedure at a given level of abstraction. Hiding the details is the heart of what programming is.

I always try to write code like

fn foo() {

    let foo = do_first_thing();

    let bar = do_second_thing();

    do_third_thing(foo, bar);

}

whenever possible. Then you can see the abstract overview of what the code does at a glance, but you can drill down into the details if you need to.

It's a personal preference based on how we mentally model problems. I cannot stand long procedural code. The mental gymnastics required to know what it does is too much. More than 5-6 variables in scope and I have no idea if it does what you say it does. It would take me some time to figure that out. If it is under test we can at least say it's not wrong some times.

I much prefer breaking problems down to the level where I can reason in terms of sets, algebras, and that sort of thing. It's much easier for my brain to rely on properties and the ability to substitute terms in equations than it is to reconstruct a giant state machine and execute it in my head. Much more so when we add concurrency to the mix.

At the end of the day though I don't think there's, "one true way."

When I was a kid I would tell my parents I cleaned my room, then they’d look in the closet and see everything in a pile.

Don't let perfect be the enemy of good

I still don’t fold clothes. I just buy stuff that doesn’t wrinkle. Work smarter not harder.

My kid does this. We wanted to find a book. It required us to search through the mountain hidden in the closet and was very annoying. If it was organized we would have known where to find the book.

I dislike microscopic functions a lot too and yet I've never needed 10 uninitialized variables at the beginning of a function. I've written readable 100 lines long functions. I just assumed that the OP was dealing with like 5000 lines long files with statics all over the place.

If your functions are 100 lines long, readability may be in the eyes of the beholder. That's how big I'd expect most modules to be.

> you lose the ability to read a whole procedure from top to bottom

An ability that is only valuable if it really is a procedure, some sequence of operations, rather than a function, some forming of a value. I'd agree that procedures should generally not be split up into subprocedures; a procedure has to be read from top to bottom, so factoring out subprocedures only makes it harder to understand. But a function can be understood without understanding the smaller functions that it calls, so breaking functions up into smaller functions - and breaking small functions out of procedures, where possible - makes it easier to understand.

Having a language that makes an explicit distinction between procedures and functions - in particular, where calling a procedure looks different from calling a function - helps a lot (e.g. Haskell).

I define functions as often in let/letfn blocks than I do as separate functions, so they are local and in context. Makes it easy to read.

This sounds like another option while maintaining agreement with the gist of what I meant. Those are good, though that’s where I start preferring smallness

Reply on news.ycombinator.com