Hacker News Reader

Comment by RivieraKid | Hacker News Reader

Not a law but a a design principle that I've found to be one of the most useful ones and also unknown:

Structure code so that in an ideal case, removing a functionality should be as simple as deleting a directory or file.

Functionalities aren’t necessarily orthogonal to each other; features tend to interact with one another. “Avoid coupling between unrelated functionalities” would be more realistic.

What's the smallest unit of functionality to which your principle applies?

For example, each comment on HN has a line on top that contains buttons like "parent", "prev", "next", "flag", "favorite", etc. depending on context. Suppose I might one day want to remove the "flag" functionality. Should each button be its own file? What about the "comment header" template file that references each of those button files?

I think that if you continue along the logical progression of the parent poster, then maybe the smaller units of functionality would be represented by simple ranges of lines of text. Given that, deleting a single button would ideally mean a single contiguous deletion from a file, versus deleting many disparate lines.

The `comment_header` template would iterate over the files in `comment_header.d/*`, which would, admittedly, need forced sorted naming:

100_parent.template

150_context.template

200_prev_next.template

300_flag.template

350_favorite.template

Looks odd with the numbering, no?

But then you get the added benefit of being able to refer to them by numbers, just "100" or "300" without having to glue humanlang inflection, declension, punctuation onto identifiers that happen to be words...

Some places where you can see this pattern: BASIC's explicit line numbering; non-systemd init systems.

Maybe the buttons shouldn't be their own files, but the backend functionality certainly could be. I don't do this, but I like the idea.

Features arise out of the composition of fundamental units of the system, they're not normally first class units themselves. Can you give an example?

For example using nested .gitignore files vs using one root .gitignore file. I guess this principle is related to this one:

Imagine the code as a graph with nodes and edges. The nodes should be grouped in a way that when you display the graph with grouped nodes, you see few edges between groups. Removing a group means that you need to cut maybe 3 edges, not 30. I.e. you don't want something where every component has a line to every other component.

Also when working on a feature - modifying / adding / removing, ideally you want to only look at an isolated group, with minimal links to the rest of the code.

You're describing "modularity" or "loose coupling" in code. But it rarely implies you can just delete files or directory. It usually just means that a change in one component requires minimal changes to other components -- i.e. the diff is kept small.

Now, I tend towards the C idiom of having few files and not a deep structure and away from the one class, one file of Java. Less files to rename when refactoring and less files to open trying to understand an implementation.

One advantage of more smaller files is that merge conflicts become less common. I would guess that at least half of the trivial merge conflicts I see are two unrelated commits which both add some header or other definition at the top of the file, but because both are inserted at line 17, git looks at it and says, “I give up.”

This in itself might not be enough to justify this, but the fewer files will lead to more challenges in a collaborative environment (I’d also note that more small files will speed up incremental compilations since unchanged code is less likely to get recompiled which is one reason why when I do JVM dev, I never really think about compilation time—my IDE can recompile everything quickly in the background without my noticing).

for the first point, such merge commits are so trivial to fix that it’s barely takes time.

You got a point for incremental compilation. But fewer files (done well) is not really a challenge as everything is self contained. It makes it easier to discern orthogonal features as the dependency graph is clearer. With multiple files you find often that similar things are assumed to be identical and used as such. Then it’s a big refactor when trying to split them, especially if they are foundational.

YES! "Deletability"

Reply on news.ycombinator.com