Skip to main content
27 events
when toggle format what by license comment
Jan 15, 2018 at 15:04 vote accept GregT
Jan 13, 2018 at 4:09 history tweeted twitter.com/StackSoftEng/status/952029701031292928
Jan 10, 2018 at 8:14 history edited GregT CC BY-SA 3.0
edited title -- may is better here than should
Jan 9, 2018 at 21:59 comment added Stack Exchange Broke The Law @CandiedOrange Nor do different versions of the "same" program see those names in each other.
Jan 9, 2018 at 16:02 comment added casey @BerinLoritsch even our approximations of those constants change over time as experimental observations refine thier precision. (Thinking physical constants, not pure mathematical constants)
Jan 9, 2018 at 13:59 comment added candied_orange @immibis different programs wouldn't even see those names in each other. If the code from each was linked together into a 3rd program you'd need some kind of namespace to make them unique. That's an entirely different issue then dealing with multiple users of a public constant that have different expectations of what it's value should represent.
Jan 9, 2018 at 13:22 answer added AnoE timeline score: 0
Jan 9, 2018 at 2:52 comment added Stack Exchange Broke The Law Wait, your program has final static int NUMBER_OF_RUNS = 5; but mine has static final int NUMBER_OF_RUNS = 50;! Are constants supposed to be the same in different programs?
Jan 8, 2018 at 21:17 answer added fluffysheap timeline score: 6
Jan 8, 2018 at 21:02 comment added svidgen Not much time to articulate a full answer, but I suspect your colleagues concern isn't so much with constants, but with the code-inlining of configuration values, which might tend to manifest as constants. ... Constants protect you against stupid mistakes, like accidentally assigning over gravity mid-game/run. They don't necessarily mean, gravity is the same on every planet ... That said, the healthy solution is to make gravity a constant, but pull it from a planet file or database at the start of the relevant scope.
Jan 8, 2018 at 18:24 comment added Alexander @GregT I would disagree. final gives you a compiler-enforced guarantee that the program won't modify the value. I wouldn't dispense with that just because the programmer might want to modify the value assigned in the source code.
Jan 8, 2018 at 18:08 comment added user251748 @BerinLoritsch I think that even some physical constants can (theoretically) change over time. Is nothing sacred?
Jan 8, 2018 at 17:56 comment added Ralf Kleberhoff In Java, be sure to recompile all classes where the constant itself or dependent constants are used, hopefully done by your IDE / toolchain.
Jan 8, 2018 at 15:58 comment added Erik Eidt software is soft.
Jan 8, 2018 at 15:27 answer added amon timeline score: 13
Jan 8, 2018 at 15:22 answer added user292808 timeline score: 2
Jan 8, 2018 at 14:30 comment added Berin Loritsch @GregT, after giving it some thought, there are cases where your senior colleague would be correct. You can see the end of my answer for more clarification.
Jan 8, 2018 at 14:18 answer added Berin Loritsch timeline score: 6
Jan 8, 2018 at 14:08 review Close votes
Jan 13, 2018 at 3:04
Jan 8, 2018 at 14:05 answer added nvoigt timeline score: 85
Jan 8, 2018 at 14:05 answer added DMuenstermann timeline score: 1
Jan 8, 2018 at 14:04 comment added Berin Loritsch Unless you are modeling physical properties with constants that have known mathematical values, everything can change at some time.
Jan 8, 2018 at 14:00 comment added GregT @VincentSavard A senior colleague told me that if something may be changed, it should not be final static.
Jan 8, 2018 at 13:59 comment added Berin Loritsch As long as it is a constant for the entire run-time of your application, I see no harm.
Jan 8, 2018 at 13:58 comment added Vincent Savard I'm curious, why would you believe it to be bad style to change these?
Jan 8, 2018 at 13:53 review First posts
Jan 8, 2018 at 15:43
Jan 8, 2018 at 13:52 history asked GregT CC BY-SA 3.0