Question

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.

No correct solution

Licensed under: CC-BY-SA with attribution
scroll top