what's wrong with this approach?

Question

A new Code Review process has been put in place and now my team must not ever declare a string as a local variable, or the commit won't pass the code review. We are now to use constants instead.

So this is absolutely not allowed, even if we're dead sure the string will never be used in any other place

String operationId = "create"; 

This is what should be used instead:

private static final String OPERATION_ID = "create";

While I totally agree to use constants for strings that appears +2 times in the code ... I just find it overkill to completely not have the ability to declare a string in place if it's used only once.

Just to make sure it's clear, all the following are NOT ALLOWED under any circumstances:

• String div = "div1";
• Catch(Exception ex){ LOGGER.log("csv file is corrupt") }

• String concatenation String str = "something ...." + someVar + "something" ... we are to replace someVar with %s , declare whole thing as a global string, and then later use String.format(....)

• if( name.equals("Audi" ){....}

• String value = map.get("key")

Any ideas guys ? I want some strong arguments. I'm ready to embrace any stand that's backed by a good argument.

Thanks.

Answer 1

First, let's throw out your assumption: There's nothing inherently wrong with the approach described.

It's not about strings being used in more than one place, it's about constants being easy to find and documented, and your code being consistent .

private static final String OPERATION_ID = "create";

Really, this isn't used anywhere else? Nothing would break if I changed this to the string "beetlejuice"? If something would break, then something else is using this constant... If the "something else" happens to be a codebase in a different language, and that's why they don't share string constants-- that's the exception, not the rule. Consistency!

---

That said, there are a few things I would standardize in a slightly different manner, but I would still standardize them nonetheless:

I would suggest allowing string literals in the constructors of enums:

public enum Operation {
    CREATE("create"),
    ...
}

because here, the enum is the constant that is being referenced in the code, not the string literal. Declaring the constant as an enum or as a private static final String are equivalent to me, and there's no need to do both.

Additionally, I would not use this pattern anywhere that it breaks your IDE's ability to warn you about missing strings-- For example, looking up strings from .properties files. Many IDEs will give you proper warnings when you look up a key in a .properties file that doesn't exist, but the extra level of indirection might break that depending upon how smart your IDE is.

Catch(Exception ex){ LOGGER.log("csv file is corrupt") }

This to me is a bit of a gray area - Is this an internal-only message? Are the logs only ever seen by you, the developer, or are they for a user's benefit too?

If it's only for developers of the application These probably don't need to be localized.

If you do expect the user to view the logs, then they should be externalized into a .properties file.

Answer 2

It is good coding style to define a constant for a value/literal when the value/literal is used multiple times.

The imposed coding style forces you to use a constant for every string literal.

The good effect of that coding style is: All string literals which really should be declared as constants are now declared as constants.

The bad implication of that coding style is: You - the developers - are not able to decide if a string literal should be defined as constant or not. This is a heavy punch.

Therefore you should raise your concerns that the good intention of the coding style does not compensate for the mistrust in your developer qualitites.