1

Started a new job, provided my first PR and had a lot of review comments which I personally just consider frivolous.

Whilst it's easy to fix personally I do not believe this is Hungarian Notation and it is just sensible variable naming.

Here is the line of code:

final List resultTermsList = Collections.singletonList(resultTerm);

And this is the comment I received:

No need for Hungarian notation. resultTermsList -> resultTerms

Is this Hungarian Notation?

Hulk
  • 6,399
  • 1
  • 30
  • 52
user3864189
  • 19
  • 3
  • 4
    No, it's too verbose (and reversed). [Hungarian notation](https://en.wikipedia.org/wiki/Hungarian_notation) would be something like `lResultTerms`. So you have expanded reverse Hungarian notation. And `resultTerms` is all that's necessary assuming you use any sort of modern tooling. – Elliott Frisch Sep 20 '18 at 04:06
  • 7
    *"Started a new job, provided my first PR and had a lot of review comments which I personally just consider frivolous."* - You need to fit in with your team / organization's culture. (You are the new person.) Asking us what >>we<< think is entirely beside the point. And it is also beside the point whether this is "Hungarian notation" or not. Your reviewer clearly thinks there is a problem with your PR. Talk to them about what they think the problem is. (And I would advise NOT suggesting to them that their comments are frivolous ...) – Stephen C Sep 20 '18 at 04:15
  • No it is not `Hungarian Notation`, that putting single characters in front to show scope and type. Your naming is fine as long as it is not a [tautology](http://www.vertigrated.com/blog/2011/02/interface-and-class-naming-anti-patterns-java-naming-convention-tautologies/), that is the best test for naming. –  Sep 20 '18 at 17:25

1 Answers1

6
final List resultTermsList = Collections.singletonList(resultTerm);

Is this Hungarian Notation

Yes, and no.

No

No, not in the strictest sense.

Hungarian notation was a practice from the earlier days of computer programming. Tooling was weak, without sophisticated parsers that gave detailed analysis and feedback to the programmer as he/she worked. IDEs as seen today did not exist. Various languages were extremely limited, even to the point of variable names limited to extremely short lengths.

Hungarian was a way of identifying the type by indicating the data type of a variable by including a particular letter in the variable's name, as a convention.

As tooling & languages improved, the need for Hungarian notation evaporated.

So, in the strictest sense, no, your given code is not exactly following the Hungarian notation conventions.

Yes

Yes, in the more general sense.

Your given code example includes the data type, List, as a word “list” within the name of the variable. This is similar input purpose to Hungarian notation including l in variable name lInvTot to mean “long integer”.

Given today's powerful editors and IDEs that can provide all kinds of realtime assistance in identifying the data type, the class, superclass, and other contextual information, including an indicator of type within the variable name is unnecessary. Such an indicator adds to verbosity without adding value. Generally this should be avoided where needless, where readability is decreased.

But context is everything. Sometimes it is sensible and justifiable to include the type in the name. For example, in an app calculating an invoice total, you may have an label, a button, a result field, an internal result number, and a method name that could all be named something like "invoiceTotal". So there it might make sense to have names such as invoiceTotalLabel, invoiceTotalButton, invoiceTotalField, and invoiceTotalBigDecimal within one area of code if clarity and readability are enhanced.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • 100% agree with last paragraph. I find myself using that kind of naming for GUI stuff, but not much for server-side stuff. More importantly, I've found it to be very helpful when I go back and have to edit stuff months later. – Jeutnarg Sep 20 '18 at 16:54