use `DRAGON_CASE` - because of env vars
junaga opened this issue · comments
environment variables exist
In JavaScript, environment variables exist. They are far from redundant, and became the new norm to set software parameters. Because of the nature of the web, and JavaScript, configuration files turned into declarative source code (package.json, Webpack, Vite, etc). Environment variables, are the parameters, JavaScript developers use, to configure software.
./.envmanifest- public cloud VMs
- platforms (GitHub, Replit, etc)
It is certain that environment variables are not a legacy Unix relic, but a core feature of computer software development (DX).
they're not constants
Environment variables, are variables, not constants.
I propose an alias for constantCase to dragonCase, and an update to documentation, replacing CONSTANT_CASE with DRAGON_CASE, not SCREAMING_SNAKE_CASE.
My research on this so far
No thanks. Alternative names could come from here: https://en.m.wikipedia.org/wiki/Naming_convention_(programming)
But I find the naming acceptable and don’t follow the argument entirely. Typically constants in all languages use this format. The references/research don’t seem relevant or well cited enough to use either.
FWIW, you may be surprised to learn that the naming has nothing to do with the fact that it’s a literal constant in whatever programming language you use, but rather its used to signify that it should be constant (not modified) by the user.
Even in JavaScript, before we had a const keyword, CONSTANT_CASE was used for variables.
hi, you are correct I did not know this. but so don't 95% of developers. and they probably do not care.
I feel a sense of hostility from your reply and instant-lock of of the issue without any discussion. this is not how growing works.
goodbye
FYI wiki:SCREAMING_SNAKE_CASE redirects wiki:Snake_case so wikipedia (and MDN) say that SCREAMING_SNAKE_CASE is the correct name.
sense of hostility from your reply and instant-lock of of the issue without any discussion
It wasn't locked, it was closed. It was closed because I said I wasn't going to do it. You are welcome to continue the discussion, as you seem to have anyway. A locked issue is different to a closed issue and would not allow you to reply.
For context, you'll often see people close an issue if they aren't going to do it. It's common sense as a maintainer. We have limited bandwidth and need to filter by open real issues. If you are a maintainer, what would you do in the same situation? I'm seeing half a dozen issues per day and need to close them so I can keep track of what's actually broken, not to mention that open issues have a negative externality (i.e. reputation on NPM/GitHub, they are measured and visible) so keeping a non-issue open is bad for me.
FYI wiki:SCREAMING_SNAKE_CASE redirects wiki:Snake_case so wikipedia (and MDN) say that SCREAMING_SNAKE_CASE is the correct name.
I don't think most developers would know what SCREAMING_SNAKE_CASE is if you asked them, but CONSTANT_CASE is typically a lot more obvious.
A redirect doesn't mean it is the "correct" name either. For example, here's google using CONSTANT_CASE: https://google.github.io/styleguide/jsguide.html#naming-constant-names
Ignoring this though, there are multiple valid "names" for most of these cases. For example, PascalCase could be called CapitalCamelCase. I previously called Train-Case, Header-Case. I don't keep the aliases around because it creates unnecessary confusion and package bloat.
It just seems like you're very invested to try and rename this without any good reason, which honestly just makes my life as a maintainer more difficult for no good reason.