Adding flags is very WET right now

[KernelDeimos]

If DRY means "Don't Repeat Yourself", you could think of "WET" as meaning "Write Everything Twice".

Well, to counter my own point, suggesting that "write everything twice" is always bad is a fallacy; considering Rule of three suggests that anything repeated twice does not require refactoring. I however disagree further and see this as depending on context:

• is the duplicate close to the source? (will a careful developer see it immediately)
• is the repeated code a 1-to-3-liner, or 30 lines of nuanced branching?

This issue isn't a duplicated section of code, but something of similar consequence: adding to a logical list in the software (in this case, the list of flags that exist) requires changes in multiple places:

• two places in bin/http-server
  • documentation for --help
  • check argv['snake-case'] to assign options.camelCase
• entry in defaults.json
• three locations of opts.js
  • variable initialization at the top with the default
  • assignment to local variable from opts
  • export at the end
• two places in lib/http-server.js:
  • assignment from options to instance variable
  • passing from instance variable as argument to httpServerCore

In total, that's adding the same information ("this is a boolean flag called --my-flag") as slightly different code in: 4 files, 8 individual locations.

This is an anti-pattern called shotgun surgery

note: I realize that the description of DRY is disjunctive to the rest of the contents of this issue description. I was going to write this description differently and changed course, but left this description related to DRY intact because the quantification of duplicate code might follow similar rules/guidelines to the quantification of multiple points of code required for a specific change (I don't think anyone is going to write "rule of three but specifically for shotgun surgery rather than DRY")

[Arvind054]

Hi! 👋
This is a great point — the current structure does seem to exhibit a form of shotgun surgery, where adding new flags requires changes across multiple files and locations.

I’d like to take this up and explore a refactoring that centralizes flag definitions or introduces a single configuration source (perhaps a metadata-driven or schema-based approach) to minimize repetition and improve maintainability.

Could you please assign this issue to me? I’ll start by mapping all the current flag-related touchpoints and propose a cleaner structure before implementing any code changes.

Thanks! 🙌

[KernelDeimos]

Hello, before I assign you to this issue I'd like to ask you for clarification on the approaches you mentioned: a metadata-driven or schema-based approach. This sounds like the introduction of a layer of abstraction over configuring flags but to me that doesn't seem like an appropriate first step - right now centralizing information about what flags exist is prerequisite to any abstraction.

Also, and if this isn't the case I'm sorry I have to even bring it up, but to me your message reads as AI-generated. It's really hard to tell but I'd like some assurance that the code will be reviewed and understood by a contributor before the maintainers have to spend their time reviewing it. This is a growing problem for maintainers in general on GitHub right now.