I going to go with an "It Depends" answer here, but first off, I'll bash a couple of concepts about as food for thought before getting into the real heart of the matter.
First off, I read an answer that made a passing mention of Hungarian notation. One of the reasons why I really dislike the use of the Hungarian notation is because the prefixes aren't always meaningful to the reader unless the reader is familiar with the same coding standard as the author. You can read a couple of letters as a prefix and assume that the author intended it to mean one thing, but really it means another. The fewer the letters used, the easier it is to misinterpret, and if you are adding letters to clarify the intention, then you might as well just spell the whole thing out. So, potentially meaningless abbreviations are out, and nice descriptive words are definitely the better option.
So you've got a nice descriptive word that you think should be a prefix or a suffix for your class, variable, object, or whatever. Do you use dollarAmount, or amountInDollars? or, does it even matter? Should this concept be limited to your variables/fields/properties/etc.., or should the classes be prefixed and suffixed also? Or perhaps the question you should be asking is: What value does this word provide within the context of the code?.
Compare the following:
var itemList = new List<Item>();
var listOfItems = new List<Item>();
var items = new List<Item>();
Is it worth stating that your items are a part of a list, or is it enough to infer that a variable represents a list if you use a plural name? If it were me, I'd use the simplest name with the fewest characters, because I like nice concise names that are descriptive enough for me to understand the meaning, even if it is inferred. I see no additional value making things any wordier, especially if I find myself dealing with a long line of code with a lot of words in it. Granted, there are those who might feel differently, however the point I am trying to make isn't to debate the finer nuances of the choices of names I have here, but to highlight that all things being equal, for the case I have shown you it isn't entirely necessary to use a prefix or a suffix in this case.
So how about the following cases?:
var items = new ItemArray();
var items = new ItemList();
var items = new ItemCollection();
var items = new Items();
In this example, there is one stand-out option that I personally wouldn't choose to use. While later in the code I might not care about my variable name beyond the fact that I have some sort of a list or a collection there, when it comes to the actual class type, the suffixes remind me that each class represents a different interface for the object that I am creating, and thus the suffixes provide me with valuable information about their compatibility with other classes that I may wish to invoke in a common way.
C# offers the ability to create static classes as containers for extension methods. That being the case, consider the following:
public static class CommonExtensions { ... }
public static class UnCommonExtensions { ... }
Is there any value here? Possibly not, because it isn't really clear which is the prefix and which is the suffix. I know that the class contains extension methods, but do I really need the word Extensions there? On the flip side, do the words Common and Uncommon offer any value? Should I have used a partial class instead, and just call the class in each partial class file Extensions? That's probably not a bad idea, but consider the following case:
public static class StringExtensions { ... }
public static class TextBoxExtensions { ... }
public static class ObjectExtensions { ... }
This is perhaps a little more descriptive and allows a nice logical grouping of the various extension methods being made available.
My last point is about standards and expectations. When a brand new system, language, or an API becomes available, people tend to follow whichever conventions were suggested by the developers of the product at the time it was released. Some APIs use Hungarian-styled prefixes as a means to distinguish different parts of the API, and to group classes where name spacing isn't available, or because there is a lot of history and there is an expectation to continue to present an interface in a certain way. Personally I don't see much wrong with this if there isn't a better way to do things. What about the Win32 API, with all of those Windows methods that end in Ex, and W and suchlike? Such suffixes probably meant something to the engineers that had created those methods at the time, but to those of us who never really learned what the prefixes actually stood for, they didn't really make a great deal of sense for the most part.
So, I feel that the answer really is that it depends on each specific situation. Short and essentially unclear abbreviations do not offer value, while descriptive words do. It is however a case of where and when the prefixes and suffixes are used, and how they might add value to the names you are giving the entities within your code. As always, strive for the simplest form that you can use. Be descriptive enough to get the message across while remaining concise enough to retain value in the name, and when you have decided how to go about naming things, do it systematically and consistently.
