[HN Gopher] Settling the File Structure Debate
___________________________________________________________________
Settling the File Structure Debate
Author : moebrowne
Score : 20 points
Date : 2025-05-02 12:47 UTC (10 hours ago)
(HTM) web link (muhammedsari.me)
(TXT) w3m dump (muhammedsari.me)
| GenerocUsername wrote:
| Blog has a unique voice, but also the clear outline structure of
| a ChatGPT response.
| hnuser123456 wrote:
| Yep, has em dashes all over.
| CodeMage wrote:
| The first time someone accused me of being a bot because I
| use em dashes for inserting parentheticals, I was
| flabbergasted and then pissed off. I have plenty of concerns
| about GenAI, but I honestly didn't expect one of the problems
| to be "using a wide variety of punctuation is frowned upon".
| What's next? "Only bots use the Oxford comma", maybe?
|
| That said, this blog post does seem to use em dashes
| "incorrectly", at least according to what I've been taught.
| The way I've been taught to use them, they're not exactly the
| same thing as a comma and you cannot use them
| interchangeably. But perhaps I'm nitpicking.
|
| (PS: If it's not clear, I'm _not_ the author of the blog. I
| 'm just someone who hates how the GenAI is contributing to
| the enshittification of communication.)
| hnuser123456 wrote:
| Their presence isn't enough on its own, but combined with
| the tone and style, it definitely "feels" like the way
| chatgpt talks. The blog owner seems obsessed with
| productivity hacks so I wouldn't be surprised. At least you
| can feel confident knowing that people who write like you
| make up a significant portion of its training.
| ttepasse wrote:
| As someone who memorised the key combo for em dashes, curly
| quotes and guillemot's back in IRC days this notion depresses
| me.
| wodenokoto wrote:
| Could be a result of "clean up my post and fix the intro"
| fellowniusmonk wrote:
| The checkbox tables really stood out to me.
| mcbishop wrote:
| tl;dr from the bottom of the blog post:
|
| > Type-based grouping is great for tech-focused tasks, consistent
| naming, and large sweeping changes.
|
| > Context/process-based grouping shines for domain clarity, team
| ownership, debugging, and mapping business problems directly to
| code.
| kiitos wrote:
| ...for PHP projects
| karmakaze wrote:
| It was never a question for me. If you consider visibility by
| package, domain grouping is clearly the right choice.
| nayuki wrote:
| The article is essentially an instance of the debate about
| hierarchical folders vs. tags for organizing a collection of
| files.
| bulatb wrote:
| At the risk of becoming that guy from the tabs vs. spaces meme:
| Why not both? Name folders by domain or topic and files by role,
| if you can. app/ iam/ orgs/
| models.xyz roles/ models.xyz
|
| Then any editor with file search can produce the type-based
| structure on demand.
| keeganpoppen wrote:
| this is part of what charmed me about svelte when i first learned
| about it a while back-- it really does seem like a better way in
| many ways.
| Groxx wrote:
| As much as I greatly prefer context-based grouping when I can get
| it, I find it breaks down in a few significant ways:
|
| Contexts are not always (or even usually?) hierarchical and
| distinct. This leads to constant variance on if your IAM code
| belongs in "users", "auth", "access", "api", or even "iam" (and
| is that nested under something else or not?). Or maybe it's
| "middleware"? Wait the identity team is called "Galactus"...
| Every team makes different decisions, and while all may be
| defensible they're still different and can take a lot of time to
| figure out. Assuming anyone even knows, and it isn't just rolling
| along vaguely on its own inertia.
|
| "Directly mirrors stakeholder language" does not always have any
| bearing on how a thing works or is built. To take the house
| example, sure, houses have doors and windows. They also have
| stuff hidden in walls, paperwork that buyers never see, and
| massive supply chains that nobody actually fully knows - are you
| modeling those too? They're part of a house's existence. But
| obviously you're not because you obviously only care about X and
| not Y... but really, how many times have you run across a
| business that _fully agrees on what X is_ and is completely
| consistent on it? Some, surely, but vague sections are often
| natural because otherwise your market would be a solved problem.
|
| And last (OTOH) but not least: business needs and concepts often
| change with time. Do you restructure your code to match that? At
| this point you're knee deep in the first one above, _again_ , and
| if you don't complete it you're left with confusing tech debt.
|
| ---
|
| Type-based layouts benefit greatly from _not needing to think
| about it_. Almost everyone is almost immediately able to put
| things in the right place, and know where to go to find
| something. Sure, it 's a bit of a mess in there, but you've still
| cut out like 75% of the codebase and the task is now smaller.
|
| Though obviously ^ this can break down rather badly when the
| remaining 25% is still much too large to search quickly.
| 12_throw_away wrote:
| TBH I wish we didn't have to choose. There are a variety of ways
| folks might need to read the code, so why not have multiple views
| of the project, depending on how you want to look at it?
| Wowfunhappy wrote:
| > If there's one unshakable prophecy in software development,
| it's this: Your code will change.
|
| > Maybe tomorrow. Maybe in six months. But change is coming
| faster than your next caffeine crash from the coffee you had this
| morning. Smart developers accept this upfront and set up their
| projects to embrace it, not fight it.
|
| ...this _does_ depend on the project. If you 're developing a
| video game, for example--a single player game like Zelda, not a
| service game like Fortnite--there actually is a point where your
| code _won 't_ change. Similarly, I used to work at an agency that
| specialized in one-off static websites tied to particular moments
| in time. While we did sometimes modify these websites post
| launch, the edits were minor and generally meant something had
| gone wrong, either on our end or the client's.
|
| This is kind of unfair to the author. I point this out only
| because I think it's important to acknowledge that some software
| really _is_ one and done, and it 's important to know what kind
| of project you're doing. YAGNI and all that.
___________________________________________________________________
(page generated 2025-05-02 23:02 UTC)