1

In code I found:

String age = null;
String place = null;
new Employee(firstParam, secondParam, null, null, age, place);

Class Employee is not our class, probably generated from wsdl file where parameters(age and place) are called alter, platz so someone tried to name null parameters to know which is which but is it good practice? Another problem is that age and place are translated while other two parameters are just null but beside of that is creating variable with null value just to pass it in next line to constructor is okey?

Michu93
  • 5,058
  • 7
  • 47
  • 80
  • 2
    Have you considered builder pattern? – Sweeper Jan 19 '20 at 11:08
  • 2
    Stuff like that is not necessarily the job of source code, it is the job of the IDE. Most of the major IDEs, like Intellij, have a feature called "parameter hints". Where they display the name of the parameter in the method call, if not obvious from the passed in parameter or method name (like in `setName(name)` it wouldnt be displayed). If you enable this feature this issue would be gone completely. – Zabuzard Jan 19 '20 at 11:10
  • By the way, I have seen this pattern being quite common among some programmers and languages. At work, we are doing C++ and our coding convention did encourage this until we switched to a plugin that had parameter-hints as feature (Resharper). But the Java IDEs have this feature for free, built-in already. So no need. – Zabuzard Jan 19 '20 at 11:13
  • 1
    @Zabuza totally right, our IDE display names of parameters but problem is that it's not 'our' constructor, it's automatically generated and names are in german which doesn't help a lot. – Michu93 Jan 19 '20 at 11:13
  • 1
    @Zabuza not needed, unless you read code out of the IDE, like during code reviews. – JB Nizet Jan 19 '20 at 11:17
  • As sweeper suggested, a builder pattern would be a very good code-counter to that issue. As it explicitly introduces naming into your object creation. But if you overdo it, like for all your method calls, it might pollute your repository with lots of classes. Maybe also think about changing the design of the method to not support optional null-arguments, maybe overloading would also help. – Zabuzard Jan 19 '20 at 11:17
  • 1
    Or use a language that has named parameters, like Kotlin. – JB Nizet Jan 19 '20 at 11:18

3 Answers3

2

In my experience, when I have pregenerated class defs that expose contracts that don't suit my needs, I tend to abstract them behind a factory method (may not be a full fledged builder, but depends..) and expose overloaded contracts that help API users to simply pass whatever args are actually needed. Now as to whether naming variables as null is considered good practice or not, i think that is more subjective of your choice rather than an established pattern. But IMO, simply passing null would be cleaner than writing few extra lines only to pass method args.

Ed Bighands
  • 159
  • 8
2

There is no clear yes or no on this pattern. It is indeed commonly used in some areas.

It has the obvious advantage that it introduces the naming and by that making your code easier to read and maintain, which is always good and also reduces likelyness of bugs.

But it also has disadvantages. The biggest is probably that, for a reader, the intend of the variable may not be directly clear. Tripping into thinking that it might be used later on, thus polluting your variable scope. It might also just not be very convenient if you employ this pattern all the time.

Without going into much detail, there are some other solutions to it:

  • Most IDEs have a feature called parameter-hints
  • Some languages, like Kotlin have named-parameters
  • A builder pattern for the method-call would introduce explicit naming
  • Redesign the method to not allow optional null-parameters (some consider optional-parameters a bad practice)
  • Get rid of optional parameters by overloading your method

Apart from that, the question is probably too opinion-based for StackOverflow, especially since there is not really a strong opinion on this pattern in the community.

Zabuzard
  • 25,064
  • 8
  • 58
  • 82
0

No, it is not a good practice to do something like this. Anyway, when you're declaring some fields like this String age; , age will be null by default. Instead I would suggest to look over some generic builder patterns (look at @SpaceTrucker 's answer please) instead of instantiating by constructors with more than 2 parameters.

user1234SI.
  • 1,812
  • 1
  • 8
  • 22
  • 3
    No it won't. That's only true for fields. Not for local variables. – JB Nizet Jan 19 '20 at 11:09
  • 1
    That's true. My bad, I was thinking about **fields** too and wrote **variables** instead. – user1234SI. Jan 19 '20 at 11:15
  • 3
    Do you have any resource that backs your "not a good practice"? It is quite common and some people tend to disagree. This pattern can significantly increase readability and reduce bugs, in case a parameter-hint feature is not available in the IDE. – Zabuzard Jan 19 '20 at 11:15