|
The bigger problem is the original thread is also a breed of 'code solicitation', which is not normally supported in these forums.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
|
|
I would choose IsEmpty because IMHO it implies a predicate that checks for emptiness, while Empty implies either a method to empty the polygon or a singleton instance of an empty polygon.
/ravi
|
|
|
|
|
|
Hmmmm... from the existentialism point of view, isn't a polygon with no points null??
Seriously, IsEmpty could also be used to describe the polygon as an enclosure. So, IsEmpty could actually refer to the polygon enclosing some content.
And is a polygon with only one or two points really a polgyon? Wouldn't the property then become IsValidPolygon?
Just some food for thought...
|
|
|
|
|
.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.
|
|
|
|
|
We can take this thread over and discuss such issues.
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 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...
|
|
|
|
|
True, but then there's the out parameter.
|
|
|
|
|
Exists or IsExists?
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Are you speaking to non-existing objects now? Do you really expect Exists to return false any time soon?
This reminds me of Thread.IsAlive
|
|
|
|
|
|
PURGE *.*;*
|
|
|
|
|
Alas. I moved in December and haven't even hooked my AlphaServers back up yet.
|
|
|
|
|
There has been references to "Exists" from FileInfo. You CAN "Empty" something while you canNOT "Exists" something therefore, "Exists" is valid as a boolean property. The question is more about grammar and how we associate words and actions. "IsEmpty" is asking a question with only two answers (boolean true/false). "Empty" is either stating something is empty or indicates an action that can be taken to obtain something that is empty (String.Empty allows you to obtain an empty string). Therefore, if a boolean value indicating whether a Polygon 'is empty' is needed I would suggest "IsEmpty". If you would like to obtain an empty Polygon, Polygon.Empty will suffice.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.Length versus List.Count (I would applaud them if they would introduce the missing one as a synonym).
|
|
|
|
|
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.
|
|
|
|
|
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 use IsPolygon .
|
|
|
|
|
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 ) 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.
|
|
|
|