Hacker News Reader

Comment by mrkeen | Hacker News Reader

It's talked about, just in the opposite direction.

I've left hardcoded strings (think Kafka event type names) in my source for this very reason, but after a round of code review they get squirreled away as constants in separate files because string repetition is bad or something.

View on HN

Without constants, it's too easy to let a typo sneak in or have inconvenience later replacing one "event" but not replacing an unrelated "event". I'll only do it if the string is used two times at most, but usually I'll make a constant the first time and it doesn't feel like any loss.

Yes, this is exactly what I was fighting against.

If I have three classes that interact with "MyTable", then I can grep for places that interact with "MyTable" and I get back three classes.

After refactoring, the class which now knows about "MyTable" is Constants.java, which has no business knowing about "MyTable". Grepping it now turns up a false-positive and finds 0 of the actual usage sites (3 false-negatives).

Sure, but now you have the string constant as a symbol, which you can either grep for (in which case you're delayed by one search, not the end of the world if you were going to unwind callstacks anyway) or, if you have an LSP, you can jump directly from it to users...

It's not exactly a false positive. It's just a level of indirection, 1 more search by the constant name to find usages. What you sacrifice there you gain by having the compiler help find typos and the IDE help with autocompletion.

`Constants.java` is a massive code-smell (which I have in many projects, but it's still a smell).

The file name is awful.

At worst it should be 'DbConstants' but probably they should be defined elsewhere.

Reply on news.ycombinator.com