4 ms·
Ask HN: What's you're heuristic for using 'const' vs. 'var' in 2025?
Disclaimer: I acknowledge that the entire 'debate' is pretty trivial. For the most part, whatever gets the job done is fine.
I recently joined a team that uses a different heuristic than I prefer, and frankly until now I assumed my approach was pretty universal. Since I am joining "their" code base I'm adapting to their style but wanted an outside perspective on what is more common. The way I see it, there are 5 main approaches.
Const literally never: 'Const' is not allowed as all data should be mutable, and the responsibility to mutate the values belongs to the object/class that value is declared in, and that object/class should have full power to do what it wants within itself. Don't expose set() functions if you're worried.
Const nearly never: Only use const for real constants, like in the mathematical sense. Pi, domain name, etc. If a different client or instance could get a different value - it's not a constant.
Const for things that locally never change: Things like feature flags, usernames, etc. Stuff where changing the value outside very explicit situations, something almost definitely went wrong.
Const whenever possible - Use const at all times unless you explicitly need to change the value, such as in an accumulator. If you write a function and never need to reassign the value for your use case, make it const, ignoring all other aspects. If you return to that function a month from now and now need to reassign it, change it to 'let' and make your changes.
Const literally always: 'let' is not allowed. If you need to declare 'let', you either need to actually declare several 'const' variables or make better use of native functions (such as reduce() for accumulators)
- grajaganDev 2y agoConst whenever possible.
- NotAnOtter 2y agoFunny, that's not my preferred one nor the teams
- grajaganDev 2y agoShould it be mutable or not? Seems reasonable to answer up front by choosing const or let. What are other considerations?
- NotAnOtter 2y agoAfter thinking about it a bit more, I think I am actually on your side. I previously claimed to be on "Const when things should never locally change". But thinking through the example function expectedRevenuePerAttempt() { (const/let) successRate = success / attempt; return successRate * revenuePerSuccess } I would prefer to use const there.
- taylodl 2y agoI'm with you, const whenever possible. Fewer things to reason about and chase down while diagnosing issues or debugging. I also thought this was the default for a majority of developers.
- grajaganDev 2y agoRight, the hope is to find bugs early.
- SkySkimmer 2y agoThis is what I would call const correctness, because it is correct.
- MattGaiser 2y agoConst for things that locally never change. I also would not fight const whenever possible. Lots of data is not intended to be mutable, even if it lives within an object and there are business reasons for that. I find the restrictions above ideologically purist over practical, like the devs who insist that private/internal methods should not have unit tests. Const literally always means reduced readability and sometimes a lot of extra code.
- taylodl 2y ago> like the devs who insist that private/internal methods should not have unit tests Because unit tests for private/internal methods aren't required. They are tested via the testing of the public methods. If a test coverage analysis reveals that your private/internal methods weren't fully tested, then that tells you one of two things: 1. Your public methods weren't fully tested. Your test coverage analysis should reveal if that is the case. 2. Your private/internal methods were overengineered. They include functionality that isn't being used. Both of these are problems, but problems of a different kind. You shouldn't ignore (1), but (2) can be addressed in a myriad of different ways - including not addressing it. (2) is indicative of a development process issue more so than a defect in a development artifact.