Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
13  
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 May 10 '13 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 May 10 '13 at 12:31
    
Looking more at what seems right to me, natural language does seem to play the largest role for me. I find that "FirstVerified", "LastVerified", and "LastActivity" make sense to me. "Begin" and "End" are reasonable to me on an "Engagement" object, but would need clarification on a "Building" object. But "CreatedOn", "OpenedOn", and "ResolvedOn" all help clarify the intent is to record some type of time, where it would be reasonable to interpret the core function of the variable incorrectly when reading naturally. Conversely, "IsOffered" helps clarify also. –  shannon May 10 '13 at 13:22
1  
When you say "Hungarian in general does not [make sense to me]", what are you understanding by 'Hungarian' ? –  AakashM May 10 '13 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 Jun 20 '13 at 2:04
show 3 more comments

4 Answers

up vote 9 down vote accepted

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.

share|improve this answer
    
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 May 10 '13 at 13:55
    
p.s. I'll take that answer :) –  shannon May 10 '13 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 May 10 '13 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 Dec 23 '13 at 22:28
add comment

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?

share|improve this answer
    
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 May 10 '13 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 May 10 '13 at 13:00
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 May 10 '13 at 14:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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