Is it better practice to create a new variable solely for demonstrating something is final?

Question

I recently encountered a situation in a Java project where I wrote a block like this:

    String user = System.getProperty("user.home").toUpperCase();
    user = user.substring(user.lastIndexOf(File.separator) + 1);

    final String path1 = "C:\\first\\path";
    final String path2 = "C:\\second\\path";
    final String uniquePath = "C:\\users\\" + user + "\\unique\\path";

I'm just getting into practice of marking variables as final for style, but not sure how to handle this type of example. As I understand it, final is often used not just to prevent a value from being changed, but to indicate to the reader right off the bat that this variable is immutable. In this example, someone sees that path1, path2, and uniquePath are not going to change, and that fundamentally changes the way they think about those variables.

My concern is that, in the above example, the paths are clearly final, and user is clearly not. It's not too hard (I think) to work out that user probably isn't going to be manipulated, and the only reason it isn't also final is because it can't be gotten in one expression. However, if I saw this code, it would be really difficult for me to mentally group user with the paths. The coder obviously wanted to point out which variables were final, and they didn't mark user.

It seems then that something like this would make things more clear:

    String temp = System.getProperty("user.home").toUpperCase();
    temp = temp.substring(temp.lastIndexOf(File.separator) + 1);

    final String user = temp;

    final String path1 = "C:\\first\\path";
    final String path2 = "C:\\second\\path";
    final String uniquePath = "C:\\users\\" + user + "\\unique\\path";

But I'm not sure if this is worth the extra space and variable needed.

Is there a consensus on which of these approaches is a better practice? Is there a better option I've not considered?

Answer 1

One solution to this is to instead extract the code into a method and then just call it. This way you won't need to have the temp variable in the main method's scope and it won't "pollute" it. Below is an example refactored method

final String user = getUser();

final String path1 = "C:\\first\\path";
final String path2 = "C:\\second\\path";
final String uniquePath = "C:\\users\\" + user + "\\unique\\path";

/* you could use a more descriptive name */
private String getUser() {
    String userHome = System.getProperty("user.home").toUpperCase();
    return userHome.substring(userHome.lastIndexOf(File.separator) + 1);
}

Answer 2

My problem with you code is that is not system independent. You should always use UNC naming for paths (using / instead of \). Javas (N)IO classes with take care of the system specific conversion.

But there is more:

String user = System.getProperty("user.home").toUpperCase();

You convert the username to uppercase. This might not be a problem in your target environment if (and only if) all usernames are uppercase by default. But If you have a user Strauß the resulting string will be STRAUSS. Your code will fail in this case because even windows will not "retranslate" STRAUSS to Strauß.

Also: The location of the user home can be tweaked by a policy in the active directory. The default location you anticipate will work for 99,9% of your users, but for some it will not, because if the administrators moved the user homes, they most likely also restrict write access to C:\ so that you program will fail to create that folder...

So the question arises:

 System.getProperty("user.home")

already gives you the 100% correct path to users home folder. Why do you construct it yourself?

Answer 3

You wrote:

String user = System.getProperty("user.home").toUpperCase();
user = user.substring(user.lastIndexOf(File.separator) + 1);

But the first expression is not "user", it's something else. Just write:

final String userHomeUpperCase = ...
final String user = ...

N.B. Timothy Truckle is right, this is terrible Java code because it will only ever work on Windows. The Java library has methods to accomplish your goals without hard-coding Windows paths.