A friend asked me to do some web scraping for her. Since I didn’t have much time, I figured out the difficult part — some home grown encryption/obfuscation scheme used by the website in question, and handed ~30 lines of Python to another programmer friend of hers, a Fortune 500 Java programmer, to finish the remaining boring work.

A day later the Java guy got back to me with a full blown Java project three levels deep which was just a translation of my ~30 lines of Python, and it “didn’t work”. I had to read what was now hundreds of lines of Java to find 3(!) bugs in it.

That day I realized FizzBuzzEnterpriseEdtion is much closer to reality than I thought.

I wanted to some simple web scraping and wrote around 100000 lines for an HTML parser and XPath interpreter

I feel like that's code scanning tools to blame. A lot of them complain about "magical constants" even when they're cleaner than a dedicated constant

When you introduce a typo in a literal you will typically realise at runtime. Referencing a non-existing field won’t make it through compile time. I honestly don’t see the problem with this approach. I would choose better (semantic) names though.

You shouldn't introduce a typo in the int literal "1" or even in the word "https". It should be in your manual memory.

my issue is with it being named INT_1. If it were a constant with some meaning, I'd be accepting of it.

As is, the only way I'd approve of it is if it was required to have the value be addressable. I'm not sure how often of a concern that is in java, but in Go for example, from ~1.3 to somewhat recently sticking an integer in a interface would cause a small allocation to hold the integer. By having it stored as a variable (you can't take the address of a constant in go) one could elide the allocation by storing the address of the variable in the interface instead of it's value. Of course now go will automatically do that for small values (N < 256).

That's a pretty niche use, but it does exist. I'll assume it's not novel, and there are other, perhaps similar use cases for having a symbol instead of using the literal.

wrt https: Yeah, it should be in muscle memory, but humans make mistakes, fat fingering is a thing. Using a symbol can give you a compilation time check. Of course, you may typo the symbol and have the exact same problem. The ability to compare by address actually applies more to strings though, since you can check the address & length for equality rather than having to do a full comparison of the string. This may or may not be an issue in any given language/implementation based on a variety of reasons (string interning, multiple definitions of a literal due to runtime/dynamic loading).

I don't know if people should but people definitely do. When I review code, if a constant is inlined in several places (e.g. "https" is used instead of `PROTOCOL = "https"`), I have to check at every place that there's no typo. With a constant I just have to check once.

Some say it should be in a test.

  assert(INT_1 == 1);

Gotcha.

What? You are going to use a global state for this? No, no, no! You ought to put that in a class ...

    class MyBetterrrrInteger(MyCustomNumberClass) implements ICalculatable {
      public static MyBetterrrrInteger(OtherIntegerClass num) {
        ...
        // oh did I forget to add generics to the mix? damn.
      }
    
      ...
    }

There was the "hello world" from project GNU:

https://www.gnu.org/software/hello/

For a while I did not clue in to the fact that they were serious, I thought they were making fun of their own build tools...

Something like `SECURE_HEADER = "https://"` and `PLAINTEXT_HEADER = "http://"` can spare real headaches down the road.

How?

The s that’s so easy to miss can make a big difference in some cases.

It just goes to prove how realistic FizzBuzz Enterprise Edition is that I can't tell when people are joking about stuff like this or when they're deadly serious.

In fact, I came across a line of code that was basically `two = 2;` in my own company's codebase just a few days ago.