1

My question is more for coding conventions and practice - but are there any impact on memory or performance as well?

I have a method like this which accepts data of SomeType:

public void someMethod(SomeType sm) {
  //does something
}

Practice #1:
public void callerMethod() {
    SomeType someName = null;
    someMethod(someName);
}

Practice #2:
public void callerMethod() {
    someMethod(null);
}

Does Practice #1 has any impact on memory reference creation that a programmer should even think of? And is a "preferred practice"?

Should Practice #2 be avoided as "bad practice" because it doesn't give any clue of what data is passed as null? Also it creates problem in case of overloaded methods?

GhostCat
  • 137,827
  • 25
  • 176
  • 248
Ajeetkumar
  • 1,271
  • 7
  • 16
  • 34
  • 1
    All `null` values are the same and they don't have a type as such. You can add variables like this to make the code more self documenting but they don't make any difference (unless you have method overloading) – Peter Lawrey May 22 '17 at 09:28
  • I would say (entirely subjectively) that method 1, while it can be used to disambiguate between overloaded methods, seems idiosyncratic to me. It would certainly make me stop and think "what the hell is going on here?" for a couple of seconds when I was reading it, whereas `someMethod((SomeType)null)` would not. – biziclop May 22 '17 at 09:50

2 Answers2

3

Practice #1 is a bit redundant, since it creates an unnecessary local variable.

You can replace it with

someMethod((SomeType) null);

The only advantage this practice has over Practice #2 is eliminating ambiguity when someMethod is overloaded (i.e. if you have multiple methods called someMethod that take a single reference type argument, calling someMethod(null) will not pass compilation in some cases, since the compiler won't know which method to call).

Eran
  • 387,369
  • 54
  • 702
  • 768
  • just to make a point, casting vs unnecessary local variable. and doesn't java compiler optimizations will make the same bytecode for both of the codes? – Ajeetkumar May 22 '17 at 09:40
  • @Ajeetkumar It's possible. You are welcome to test it. However, I find a single line of code (as in `someMethod((SomeType) null)`) more readable in this case. – Eran May 22 '17 at 09:42
  • Upvoting here, as you clearly addressed the part on overloading and passing a specific type ... which I overlooked. – GhostCat May 22 '17 at 09:59
  • Thank you for the someMethod((SomeType) null); @Eran this adds value to my knowledgebase. However in my case using an overloaded method fit better. casting to type has it's own significance in cases where class is not open for modifications. thanks again. – Ajeetkumar May 22 '17 at 10:01
  • Byte code will not be the same but they're similar enough for the difference to not matter in practice. – biziclop May 22 '17 at 12:15
1

The real best practice here: be careful about putting up methods that are fine with null arguments in the first place.

Why not have two public methods: one that expects a non-null object; and one that takes no arguments? That makes your intention much clearer than both of your proposals.

Allowing for null values always carries the risk of forgetting somewhere in the code that a null check is required; so if you think about best practices: put up clean, precise interfaces that make it hard to be used the wrong way.

And regarding performance: simply forget worrying about that. If your method is called so often that the JIT decides to optimize it; it will be optimized at runtime. If the JIT sees that this method is called once per hour; and therefore doesn't optimize it - why do you think you need to worry either? If at all, we are talking about nanoseconds here. You need many method calls to make nanoseconds matter ...

Meaning: of course, one should avoid outright stupid performance killers; but you absolutely focus on readability most of the time. Remember that premature optimization thing?

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Any difference in performance and bytecode? is someMethod((SomeType) null); any better than creating local variable? – Ajeetkumar May 22 '17 at 09:41
  • Having `null` inputs is particularly smelly in cases like this, where you clearly have two execution paths (since you have two separate methods you can call). – biziclop May 22 '17 at 09:53