Repeated getter calls VS local variable?

[hushed ibex]

I’m curious about a small Java code-style / maintainability question. Suppose I have something like:

void myFunction(Payload payload) {
    log.info("Calling function using {}", payload.getCode());
   // some other instructions..
    myFoo(payload.getCode());
   // some other instructions..
    myBar(myVariable, payload.getCode());
   // some other instructions..
}

I usually prefer extracting the repeated getter call into a local final variable:

void myFunction(Payload payload) {
    final String code = payload.getCode();
    log.info("Calling function using {}", code);
   // some other instructions..
    myFoo(code);
   // some other instructions..   
   myBar(myVariable, code);
}

My reasoning is mostly:

• readability / avoiding repetition;
• maintainability, especially if the way code is obtained changes later;
• making it explicit that all these calls use the same value;
  However, I don’t seem to see this pattern used very often unless the expression itself is relatively complex. Is there a reason Java devs generally prefer calling a simple getter repeatedly instead of introducing a local var?

Would you consider the second version cleaner, unnecessary abstraction, or mostly a matter of style? And are there any cases where one approach is objectively preferable? I'm also interested in performance impacts here.

Thanks

[twilit trench]

Detected code, here are some useful tools:

Formatted code

void myFunction(Payload payload) {
  log.info("Calling function using {}", payload.getCode());
  // some other instructions..
  myFoo(payload.getCode());
  // some other instructions..
  myBar(myVariable, payload.getCode());
  // some other instructions..
}

<@&987246883653156906> please have a look, thanks.

[ionic ice]

Variable is cleaner for me although I'd always consider just passing the Payload object instead if you're working in the same module I've worked with people who love throw away useful abstractions by deconstructing the object.

[rotund saffron]

yea feel free to make the local variable

the local variable probably costs zero performance so why not

though i'd expect the jvm to optimize away the function calls as well, so it's a 0 vs 0 tradeoff here

just go with whatever you personally like

[spiral cave]

Yeah I don't think there is a hard rule here.

I think to me it depends a bit on whether .getCode() is just doing return code; or something else

[rotund saffron]

oh fuck yea true

does that mean that the local variable is generally faster then 😱

🤔

idk i'll test sometime

[spiral cave]

not generally, but if it does a network call thats unavoidable

you are right that this is something that the JVM can usually fully optimize away

[hushed ibex]

good thought

the getCode() ive put there is just example

but im also considering cases where it's an object

with potential complex relationships

(a bit heavy)

in other hand, im also considering cases where id do calculations and that getter brings something that must be fixed

i think, at such case, using a local variable would be quite meaningful

[queen finch]

Generally there's no difference between calling a simple getter multiple time VS creating a local copy or reference. The JIT will inline it. If the function has side effects, manipulates member variables, or is not idempotent then the JIT can't reason as well about immutability and that's when a helper local variable is called for. Of course, if you just practice that all the time you have nothing to worry about. As far as dogma is concerned, the actual tradeoff of introducing local helper variables is whether your code 'looks' less declarative because you are now exposing the "how" instead of the "what". And being more declarative is generally a good thing.

No matter what your style is, some problems look better solved a certain way so it's better to be flexible.