Property Name Sementics - IsEmpty or Empty
-
PURGE *.*;*:)Luc Pattyn [My Articles] Nil Volentibus Arduum
Alas. I moved in December and haven't even hooked my AlphaServers back up yet.
-
Can't make up my mind. Coding a class that represents a Polygon. If the polygon has no points should the property name be Empty or IsEmpty?
IsPointless
-
Can't make up my mind. Coding a class that represents a Polygon. If the polygon has no points should the property name be Empty or IsEmpty?
IsEmpty sounds like it should be a method because it contains a verb. And verbs are actions, like methods. Empty sounds like it should be a property because it's simply a state of being.
The difficult we do right away... ...the impossible takes slightly longer.
-
.NET isn't entirely consistent on the matter. Have a look at all the boolean properties of a System.Windows.Forms.Form, including: 1. Visible 2. IsAccessible, IsDisposed, IsMdiChild, ... 3. AllowDrop, CanFocus, CanRaiseEvents, CanSelect, ... 4. AutoScroll, AutoSize, ... 5. Created, Enabled, ... Except for #1, they all have a verb (or even two), and that is how I'd do it too. One should avoid confusion, especially when the word could be an adjective as well as a verb. So I would reserve Empty for an action (method or event), IsEmpty for a property. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
We can take this thread over and discuss such issues. :-D On something I was writing last week I have a Parse method and decided to have a TryParse as well, but it occurred to me that there is no need to differentiate the method names -- having overloaded Parse methods won't cause any trouble. So I wonder why Microsoft decided to use a new name. I suspect it's simply a matter of marketing -- they can advertise and talk up the new TryParse methods more easily that way.
-
We can take this thread over and discuss such issues. :-D On something I was writing last week I have a Parse method and decided to have a TryParse as well, but it occurred to me that there is no need to differentiate the method names -- having overloaded Parse methods won't cause any trouble. So I wonder why Microsoft decided to use a new name. I suspect it's simply a matter of marketing -- they can advertise and talk up the new TryParse methods more easily that way.
I guess it would be considered too confusing to have some Parse() methods that throw exceptions on failure, and others that just return false; I do recall a Microsoft recommendation NOT to have a parameter that controls whether failures would throw exceptions, for the same reason. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
IsEmpty sounds like it should be a method because it contains a verb. And verbs are actions, like methods. Empty sounds like it should be a property because it's simply a state of being.
The difficult we do right away... ...the impossible takes slightly longer.
For a different view[^]... :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
For a different view[^]... :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Well, since .NET is inconsistent on the matter, why follow them? Set your own naming standards for your own code, I say.
The difficult we do right away... ...the impossible takes slightly longer.
-
Well, since .NET is inconsistent on the matter, why follow them? Set your own naming standards for your own code, I say.
The difficult we do right away... ...the impossible takes slightly longer.
It is only a little inconsistent, it is mostly all right, so I choose to go along with their view, which helps readability I'd say. The most annoying inconsistency IMO is
Array.LengthversusList.Count(I would applaud them if they would introduce the missing one as a synonym). :)Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Can't make up my mind. Coding a class that represents a Polygon. If the polygon has no points should the property name be Empty or IsEmpty?
If a polygon has no points, it's not a polygon. If a polygon comprised of four or more points contains no additional points within the boundaries which define it, then it IsEmpty. How you code it makes little difference; it's still going to be a boolean value that you'll test. But I prefer to name boolean properties for the value I expect to find most often. It makes no difference logically, but I find it easier to read and understand what the code is looking for.
Will Rogers never met me.
-
Can't make up my mind. Coding a class that represents a Polygon. If the polygon has no points should the property name be Empty or IsEmpty?
If you're just using a property to indicate whether or not it has any points, then I would expect it to be
HasPoints. If, however, you need to indicate whether or not it has enough points to be classed as a polygon, I would useIsPolygon.*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Can't make up my mind. Coding a class that represents a Polygon. If the polygon has no points should the property name be Empty or IsEmpty?
The short answer is that both are acceptable and both are used within the Framework, so use whichever you think is better. I typically drop the 'Is'. I also agree with other posters who've said that you should really be defining a Valid (or IsValid ;P ) property which checks that there are at least 3 points (maybe 3 non-colinear points?). The points array being empty isn't really a relevant concern, I don't think.
-
Can't make up my mind. Coding a class that represents a Polygon. If the polygon has no points should the property name be Empty or IsEmpty?
"Empty"; as "IsEmpty" would be question and would indeed imply either a delegate or a method. "Empty" is a property of the Polygon. "IsEmpty" would be a method that can be called from that property to fetch a value, but a property never begins with "Is". The color of an apple is "Apple.Color", not "Apple.IsColor". Yes, you might be persuaded to prefix the "Is" because the property returns a bool. It shouldn't matter whether it returns a bool or an enum - if it's a property, then it'll have the name of a property - not the form a question.
Bastard Programmer from Hell :suss:
-
I guess it would be considered too confusing to have some Parse() methods that throw exceptions on failure, and others that just return false; I do recall a Microsoft recommendation NOT to have a parameter that controls whether failures would throw exceptions, for the same reason. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Luc Pattyn wrote:
it would be considered too confusing
I disagree; the boolean return and the documentation make it clear.
-
Luc Pattyn wrote:
it would be considered too confusing
I disagree; the boolean return and the documentation make it clear.
bool.Parse()would always return a bool... :doh:Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Can't make up my mind. Coding a class that represents a Polygon. If the polygon has no points should the property name be Empty or IsEmpty?
Thinking about the way structs such as
Size,PointandRectangledeal with this, I haven't checked, but I don't believe they don't provide a property for this. There is a static read only instance available calledEmptythat you can use for equality comparison to see if the one you have is empty. OverridingEquals(object),GetHashCode()and providing operator overloads for==and!=(and possibly implementingIEquatable<T>) would be the way to do this. I don't think I would use a property for this, I would use a methodpublic bool IsEmpty()as you are asking for information about the object as a whole rather than a part of it which is IMO opinion the purpose of a property.Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
bool.Parse()would always return a bool... :doh:Luc Pattyn [My Articles] Nil Volentibus Arduum
True, but then there's the out parameter.
