2

First, I believe I've seen this question discussed here before, but I cannot find it. My apologies if you do find it.

I'm starting a new project, and trying to figure out why IsResolved and/or ResolvedOn make more sense to me than Resolved. Obviously, when something is named "CompanyName" (for example), I'm fairly confident I'll test it as a string. However, when I see "Resolved", and I know the object it describes may not have a valid value for a resolution date, it bothers me that I have to inspect the type to determine how to test it: for undefined/null/etc. (as a date), or as a boolean value.

Is it reasonable to claim that Is and On typically do more than declare the variable type; they declare the intent? Or perhaps simply that it makes the code clearer for some other reason I'm not quite able to codify?

Arguing the other side, if I look at the type of Resolved, and see that it is a boolean, I will have my answer. Perhaps this is no different than knowing that I'll need to inspect a "Feasibility" variable to determine if it is an int, enum, or something else. (Although perhaps just that means "Feasbility" would be a sub-optimal name also.) And regardless, in the case of "ResolvedOn", I still have to inspect whether it is nullable to determine if I additionally need to inspect an "IsResolved" value. What is the point of the verbosity, encoding a second time in the variable name that which can be deduced from the type?

Please give me a hand understanding why Is[Property] and [Property]On make sense to me, although Hungarian in general does not. Or, explain why an exception like this wouldn't make sense?

Note: I primarily work with SQL, C#, and JavaScript.

9
  • 16
    Maybe because in everyday speaking you often use things like "this problem is resolved" while you rarely hear somebody claim that he owns two intDogs?
    – thorsten müller
    Commented May 10, 2013 at 12:29
  • Very good point. That could certainly explain why it "feels right" to me. I wonder, does that mean it IS right? It just seems that invariably when I do not use "Is" and "On" I have a harder time understanding my own code.
    – shannon
    Commented May 10, 2013 at 12:31
  • 1
    When you say "Hungarian in general does not [make sense to me]", what are you understanding by 'Hungarian' ?
    – AakashM
    Commented May 10, 2013 at 14:41
  • 1
    @shannon What doesn't make sense to you is called "Systems Hungarian Notation" (or sometimes, "Bad Hungarian Notation") as it is a complete misunderstanding of the original intent. This article has more information on the two versions of Hungarian Notation.
    – Izkata
    Commented Jun 20, 2013 at 2:04
  • 1
    @Izkata The difference between Systems Hungarian and Apps Hungarian is simply whether the compiler/interpreter knows about the type (Systems) or not (Apps). A safer solution for that article's example (in a language that supports creating new types) is to create a SafeString type and use it appropriately. Suddenly all that Apps Hungarian becomes Systems Hungarian noise. Use the compiler/interpreter to enforce type safety, not your eyes.
    – 8bittree
    Commented Mar 23, 2016 at 15:32

4 Answers 4

Reset to default
10

First of all, most of the allergic reactions to Hungarian notation stems from the fact that consistent application tends to result in very unnatural looking names. Occasional uses of prefixes or suffixes that suggest a certain type should not be considered to be Hungarian notation unless the name looks very forced.

What you are doing by using "IsResolved" or "ResolvedOn" instead of "Resolved" is disambiguating what information is conveyed by the name (i.e. what is represented by a class or object of that name, what does a thus-named function return).

To take a few more examples:

  • Company
  • CompanyName
  • Resolved
  • IsResolved
  • ResolvedOn

When reading code, "Resolved" would be the only one where I don't have an idea what it would represent and I would need to look it up. Context makes a difference and I am not claiming I am always correct, but "Resolved" is the only name in that list where I would not be able to tell at a glance if it looks to be used correctly.

4
  • Assuming that you'd also interpret "Company" as a non-standard/non-core type, I'm on the same page as you. The seeming "rule" I was questioning just came from the fact that any past-tense verb has the same ambiguity: Recorded, Reported, Opened, Closed, Etcetera(ed).
    – shannon
    Commented May 10, 2013 at 13:55
  • p.s. I'll take that answer :)
    – shannon
    Commented May 10, 2013 at 13:57
  • @shannon: Your assumption is correct. I would interpret "Company" as referring to a composite/class type. And it is not just past-tense verbs that have the problem. "Open" qualifies as well (is it a command to open something, or a check if it is open?)
    – Bart van Ingen Schenau
    Commented May 10, 2013 at 13:59
  • 1
    The real negativity toward Hungarian notation stems from the fact that while proper usage indicates the semantic type of an item (what kind of thing is it) rather than the syntactic type, some famous APIs have used prefixes for syntactic types. If items in an array have associated ID values of type int32 separate from their element indices, a name which indicates that a variable of type int32 isn't nearly as helpful as one which indicates whether a it represents an index or an element ID.
    – supercat
    Commented Dec 23, 2013 at 22:28
4

I'd say that neither of your examples actually involve hungarian notation, which is why you find them acceptable. blnResolved or dtResolved would be using hungarian notation. IsResolved and ResolvedOn are simply descriptive names. You could make IsResolved into HasBeenResolved if you like, but it's considerably longer and will not convey any additional information.

That said, don't let your dislike for hungarian notation get in the way of good names, DateResolved or ResolvedOnDate are again, just descriptive names. It just so happens that it includes what on some systems are an approximation of the data type -- note that for TSQL 2000 it isn't the exact data type as it doesn't have a date datatype.

2

I'd say that Resolved is a boolean, as well as IsResolved. ResolvedOn could be a date.

However, one simply cannot depend on notation or name of a variable to determine its type, especially if one is going through someone else's code. Imagine variables named in different language (we had an exchange student from Mexico, and she named all of her variables in Spanish). Also, there is a variable CompanyCode, for example. Can you tell whether it's a string or an int?

2
  • Yes, Aleksandra, I've tried all sorts of things in the past to avoid using the word "Code" in my naming, substituting things like "-HumanReferenceId", "-State", or other identifiers. You raise a good thought experiment for me to test against. It seems that in-general, I try to ensure that an English speaker who understands the business logic doesn't need to inspect the type to fully understand all the information the object can convey.
    – shannon
    Commented May 10, 2013 at 12:50
  • You can only go so far with your naming of objects. What if you have two objects with the same information, only converted (date and date.ToString("ddMMyyyy"))? Then maybe you'll include a little bit of Hungarian notation (Date and strDate)... I get what you're saying, don't get me wrong, I try to name my objects to be as descriptive as possible, but sometimes it just does not apply, especially if you have a veeeeeryyyyy tight deadline :)
    – Aleksandra
    Commented May 10, 2013 at 13:00
2

I believe the reason you think Is[Xxxxxxx] makes sense to you is due to your proficiency with SQL. Microsoft SQL has several IsXxxxxxxxx functions that makes life very easy for its users.

Your exposure to Microsoft SQL's IsXxxxxxxx type programming has shaped your thought process and you tend to lean toward using it outside of SQL. Why, because it does make sense. You probably question why other languages do not have similar built-in functions and you also probalby look to build similar IsXxxxxx functions when they are missing from the other languages you use.

I'm only speculating but your [Xxxxxxxx]On is probably just a natural progression of a similar thought to simplify properties that can either be On or Off.

1
  • Yes, I actually wondered if I might have pulled "On" from my database experience, although I don't think it is more typical for MS SQL schemas than others. Note that I'm using On to indicate a Date in my examples. Just more proof that no name is bullet-proof. :)
    – shannon
    Commented May 10, 2013 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.