Naming guidelines for collections

Naming guidelines for collections

Old forum URL: forums.lhotka.net/forums/t/1982.aspx


steveb posted on Friday, December 15, 2006

just wanted to get some input from people who have been using clsa for a while on naming standards for collection objects.

i have noticed in the 2.0 book that collection objects are being named things like this:

public class ProjectList :

ReadOnlyListBase<ProjectList, ProjectInfo>

or

public class ProjectResources :

BusinessListBase<ProjectResources, ProjectResource>

microsoft naming guideliness would dictate that these collection classes end with a suffix of "Collection". i dont have the 1.1 book available right now but if i remember correctly in that the naming guidelines were followed?

was there a reason for no longer using the microsoft standards when switching to 2.0, is there some kind benefit to not following it any more?

we use fxcop as part of our automated build and i need to decide which route would be more beneficial at this point, ignoring the fxcop violations in the fxcop project so that we can be consistent with the csla documentation and samples, or naming everything according to m$ standards and just continuing on.

not a big deal, just some curiosity :)

TIA,

steve

ajj3085 replied on Friday, December 15, 2006

steveb:
was there a reason for no longer using the microsoft standards when switching to 2.0, is there some kind benefit to not following it any more?


Is there a reason for following that particular guideline?  Smile [:)]

There are differences between a 'list' and 'collection,' but by the time you subclass BLB, you've implemented both interfaces, so why it wants you to name it Collection I have yet figured out...

RockfordLhotka replied on Friday, December 15, 2006

Hi Steve,

You must remember that I was working on CSLA .NET 2.0 long before .NET 2.0, or a final version of FxCop, came out. It is hard to conform to standards that don't exist, and going back to fix things after the fact is not practical - especially when you consider it would have meant changing the framework twice, the sample apps twice and the books twice. That last part - the books - makes it entirely impossible. Writing the books is far more work than writing the framework itself, and debugging a book is virtually impossible (trust me - I tried with my very first book and the quality suffered greatly...).

If you prefer the "Collection" suffix then have at it. Nothing in CSLA .NET dictates how you name your classes and collections, and if you are an FxCop user you may very well want to conform to their particular set of standards for simplicity.

steveb replied on Friday, December 15, 2006

that all makes sense rocky, thanks :)

steveb replied on Friday, December 15, 2006

we have setup fxcop as our coding standard because we have a distributed team working in china, chili, and here in the US and it automatically keeps some level of consistency through our codebase between the teams.

i am not the kind that holds to the belief that standards should be followed blindly but i do see some value in a consistent looking codebase in general. One of the things I like most about using the .NET framework is you can usually just guess what something will be named and find it. This is because for the most part its naming is consistent.

the algorithm that is flagging the names in fxcop most likely just simply looks to see if ICollection is implemented or inherited and says "that should be suffixed with collection". it doesn't have a rule for IList, gotta love stuff like that.

i can see naming something that is really a List by suffixing with List, in fact i would like that better as my own personal preference. It is still consistent and more precise.

what about the "Lists" that are named just by making the name plural though o_O

ajj3085 replied on Friday, December 15, 2006

steveb:
the algorithm that is flagging the names in fxcop most likely just simply looks to see if ICollection is implemented or inherited and says "that should be suffixed with collection". it doesn't have a rule for IList, gotta love stuff like that.


It probably does, and its exteremly silly.  If there was a rule for IList, FxCop would complain about both for a Csla based collection, and you'd end up in situtation, where you're always violating one rule or the other.   

I wonder why collection is such a big deal that it warrants its own naming rule, especially when its likely you'll implement both ICollection and IList.

SonOfPirate replied on Friday, December 15, 2006

ajj3085:
steveb:
the algorithm that is flagging the names in fxcop most likely just simply looks to see if ICollection is implemented or inherited and says "that should be suffixed with collection". it doesn't have a rule for IList, gotta love stuff like that.


It probably does, and its exteremly silly.  If there was a rule for IList, FxCop would complain about both for a Csla based collection, and you'd end up in situtation, where you're always violating one rule or the other.   

I wonder why collection is such a big deal that it warrants its own naming rule, especially when its likely you'll implement both ICollection and IList.

Andy, keep in mind that IList is derived from ICollection and IList<T> is derived from ICollection<T>, so in all cases a List is a higher order Collection.  So, if a rule was to be used, it would have to check for IList/IList<T> first and apply the suffix "List" if used then, if not, check for ICollection/ICollection<T> to apply the "Collection" suffix.  Seems pretty straight-forward to me, not sure why it's not in there - may be because MS doesn't have a "List" guideline.

As for implementing both interfaces, I do have a number of cases where the added methods, etc. exposed via IList/IList<T> are overkill.  Yes, we are using an IList<T> under-the-covers, and I did debate the design quite a bit before settling on it, the goal was to provide the most reasonable interface for the class.  And in these cases I only needed to be able to do the rudimentary functions provided by a collection.  So, we only implement ICollection/ICollection<T>.  Granted these are limited to some basic objects, but they do exist from time to time.  I am firm believer is using the "smallest" object needed to satisfy the requirements.

 

ajj3085 replied on Monday, December 18, 2006

That's true, but it makes the current rule even more absurd, and the List suffix even more accurate.  Following the rule would have you calling a list a collection, which implies it doesn't have the 'higher order' features.

Looking at the ICollection interface, just having an object implement that seems, well, not quite useful.  You can get a count and an enumerator.  I'm sure that in the objects you describe it makes sense, but without knowing specifics I'd be hard pressed to come up with a situtation where those two alone are useful as business objects.

DansDreams replied on Monday, December 18, 2006

As has been mentioned, the purpose of a standard is to be a standard.  I think 99.9% of developers would understand what a "List" suffix meant.  As is sometimes the case, the FxCop rules don't seem to work real well here.

But it did point out what I think has been an error on my point.

I use a "SummaryList" suffix to designate my abbreviated read-only lists/collections.  Mainly lookup or selection purposes.  But for editable lists I've just used the plurals which is probably not a good thing.

So in my case I'll have two standard suffixes, "SummaryList" and maybe "EditableList" or something like that.

SonOfPirate replied on Friday, December 15, 2006

Yea, you'll find a hodge-podge out there for how collections are named.  I agree completely with the MS-directed conventions with one little exception (I'll explain in a minute).  But, you do find some of us old times still adhering to the "plural" convention.

I believe in Rocky's case, he uses the "plural" convention for read/write collections and the "List" suffix to indicate a read-only collection.

In my case, I've take it a step farther and actually differentiate a List from a Collection based on its form and function.  Technically speaking, a Collection and a List are not the same even though we intermingle the names.  A Collection is a group of unorganized items; there is no indexer with Collections.  the minute you add an indexer, it is now a List because you have a way to organize the items.  This is the critical difference between the two structures.

So, if I have a ProjectCollection class, it means that I have an unordered/unorganized collection of Project objects which cannot be obtained by index - leaving me with just an enumerator.  Whereas, a ProjectList class does have an indexer.

For read-only collections, I preface the name with "ReadOnly" - which is also an MS convention.  So, I would have a ReadOnlyProjectList class.

As with any rule or guideline, it is ultimately up to you how much you want to adhere to or deviate from what is written.  Our organization, at my urging, has adopted the vast majority or the MS guidelines for naming conventions but not all.  There are still some odd ones in there that we didn't agree with and you'll probably find the same thing.  Figure out what works best for you with the guidelines and industry standards in mind and you'll be fine.

HTH

 

malloc1024 replied on Friday, December 15, 2006

I use the “List” suffix for lists and the “Collection” suffix for collections.  I prefer the suffix “Collection” over the plural form because I find it more consistent.  A collection could have a suffix of “s”, “es”, “ies” etc. to represent the plural form. However, if you use the “Collection” suffix, the suffix will always be the same.  Further, I find it easier to distinguish between collections and other classes if I use the “Collection” suffix.

malloc1024 replied on Friday, December 15, 2006

If you do use the plural form, what do you do when you have a class named deer, sheep etc?  Many words are spelled the same way in their singular and plural form.  This is another reason why I use the suffix “Collection”.

ajj3085 replied on Friday, December 15, 2006

DeerHerd, SheepFlock Wink [;)]

steveb replied on Friday, December 15, 2006

any app that has class names like that sounds like a much more fun application than i am working on :)

i think for now myself i will avoid the plurals, but only as a matter of preference, and go with a List suffix.

thanks for all the thoughts, good stuff :)

steve

cds replied on Friday, December 15, 2006

Hey! Only we Kiwis and Australians are allowed to find sheep "fun" Embarrassed [:$] Besides, my crazy girlfriend thinks that "sheeps" is a perfectly acceptable word! Smile [:)]

malloc1024 replied on Friday, December 15, 2006

cds:
Hey! Only we Kiwis and Australians are allowed to find sheep "fun"


I don’t even want to know what you meant by that.  Smile [:)]


xAvailx replied on Tuesday, December 19, 2006

>> microsoft naming guideliness would dictate that these collection classes end with a suffix of "Collection" <<

I hate that rule. We set it to ignore in the fxcop project.

>>
not a big deal, just some curiosity :) <<

FWIW, we use singular for classes, plural for containers, list for read-only lists and "info" for read-only struct/classes.

e.g.
ProjectResources > ProjectResource
ProjectList > ProjectInfo

I am not a fan of postfixing with "Collection", because it implies the underlying container is a collection (from VB days). What happens if I use a different container like a Dictionary or Hashtable or something else. Should the BO consumer really care how I implement the container? Probably not IMHO.

My $0.02

Thx.

Copyright (c) Marimer LLC