Hacker News Reader

Comment by PeterisP | Hacker News Reader

Your arguments still seem to lead me to the entirely opposite conclusion - that different choices would be better for different organizations and different projects, and it would make sense to have things like "lots of small functions vs. few fat ones" or "exceptions vs. expected" to be well-known tradeoffs where the choices would be made according in an objective manner according to the type of the project, and override personal preference because for this thing we'll explicitly optimize for this type of reader because we believe that this codebase has XYZ properties and will be maintained at ABC level by DEF kind of people.

View on HN

My argument is that those are fundamentally not project-level tradeoffs, those are "whatever your current ticket is about"-level tradeoffs. Your task may be such that you'll want opposite choices to have been made within 5 minute span - e.g. "lots of small functions" to get the gist of what the module is doing, followed by inlining everything into a single fat function along a vertical, after you found what piece of logic you want to debug. Both might also benefit from temporarily pretending error handling is done by unchecked exceptions, to remove visual clutter.

I.e. you're talking strategy and architecture, I'm talking not even tactics, but individual minute-to-minute execution.

IMHO at the ticket-to-ticket level you're not really making these tradeoffs but rather experiencing the consequences of them - it doesn't matter if for minute-to-minute execution right now lots of small functions would be better or worse, you either have them or not; and whatever tradeoffs you make for the code you write during this one ticket, it should take into account the potential future readers.

> it doesn't matter if for minute-to-minute execution right now lots of small functions would be better or worse, you either have them or not; and whatever tradeoffs you make for the code you write during this one ticket, it should take into account the potential future readers.

This is precisely the problem.

The way it should look like is, these trade-offs should be purely local, minute-to-minute editor preferences. Inlining some helpers or removing error types from the code you see, should be no harder than folding a code block or pinning a peeked function definition. Nor should those "changes" have any effect visible to anyone else. You should not take into account any "future readers", because there won't be any - but rather, you should pick a representation you need right this second, and switch to a different one the moment you need that, etc.

Ah ok, I was assuming that having this be a fully transparent & reversible issue of representation isn't really possible - but if it is, then sure, then I'd agree, then it can be treated just like indentation or syntax highlighting color schemes.

But for the major issues like split between "lots of small functions" vs "one big function" even if the IDE could e.g. inline the functions for readability, but that feels a bit risky as it makes it difficult to talk about the code or document a functions' interface if another person is seeing different semantic structure of the code, it's as if they had different names for the same things.

Reply on news.ycombinator.com