当前位置：文江博客话题详情

.NET 集合命名约定

发布于 2024-07-27 15:48:19 字数 338 浏览 3 评论 0原文

我和我的同事一直在讨论集合应该被称为什么。

例如：

类产品 - 集合 - 类产品

或

类产品 - 集合 - 类产品集合

我环顾四周，看看是否可以看到使用其中之一的任何指南或原因，但似乎没有任何结果。例如，该框架似乎使用了这两种变体。我可以看到的论点是，具有产品变量集合的类应该称为 Products，但它应该是 ProductCollection 类型。

如果有的话哪个是正确的？

同样，函数的返回变量的命名也有一个标准。例如retVal？

我们主要用 C# 编写代码，尽管我不确定这会影响我的问题。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

浪漫人生路 2024-08-03 15:48:20

我想说，对于泛型来说，几乎没有理由创建自定义集合类型。但如果你一定要说的话，我会说 ProductCollection 最适合框架的命名约定。

不过，请考虑使用 List 或 Collection 或更好的 IList 或 ICollection。。

编辑： 这是对下面埃德蒙多先生的评论的回应。

根据您的情况，您有两种选择。最明显的选择是像这样使用继承：

class Ball { }

class BallCollection : List<Ball>
{
    public String Color { get; set; }
    public String Material { get; set; }
}

我说明显是因为乍一看它似乎是最好的想法，但经过一番思考后，很明显这不是最好的选择。如果您或 Microsoft 创建了一个新的 SuperAwesomeList 并且您想要使用它来提高 BallCollection 类的性能，该怎么办？这会很困难，因为您通过继承绑定到 List 类，并且更改基类可能会破坏任何使用 BallCollection 作为 List的代码;T>。

那么更好的解决方案是什么呢？我建议在这种情况下，您最好选择组合而不是继承。那么基于组合的解决方案会是什么样子呢？

class Ball { }

class BallCollection
{
    public String Color { get; set; }
    public String Material { get; set; }
    public IList<Ball> Balls { get; set; }
}

请注意，我已将 Balls 属性声明为 IList 类型。这意味着您可以自由地使用您希望的任何类型来实现该属性，只要该类型实现了 IList。这意味着您可以在任何时候自由地使用 SuperAwesomeList ，这使得这种类型的可扩展性显着提高，维护起来也更加轻松。

I would say that with generics there should rarely ever be a reason to create a custom collection type. But if you must I would say that ProductCollection would best fit the naming conventions of the framework.

Still, consider using a List<Product> or Collection<Product> or better yet IList<Product> or ICollection<Product>.

Edit: This is in response to MrEdmundo's comments below.

In your case you have two choices. The most obvious choice would be to use inheritance like this:

class Ball { }

class BallCollection : List<Ball>
{
    public String Color { get; set; }
    public String Material { get; set; }
}

I say obvious because it seems like the best idea at first glance but after a bit of thought it becomes clear that this is not the best choice. What if you or Microsoft creates a new SuperAwesomeList<T> and you want to use that to improve the performance of your BallCollection class? It would be difficult because you are tied to the List<T> class through inheritance and changing the base class would potentially break any code that uses BallCollection as a List<T>.

So what is the better solution? I would recommend that in this case you would be better off to favor composition over inheritance. So what would a composition-based solution look like?

class Ball { }

class BallCollection
{
    public String Color { get; set; }
    public String Material { get; set; }
    public IList<Ball> Balls { get; set; }
}

Notice that I have declared the Balls property to be of type IList<T>. This means that you are free to implement the property using whatever type you wish as long as that type implements IList<T>. This means that you can freely use a SuperAwesomeList<T> at any point which makes this type significantly more scalable and much less painful to maintain.

回复收藏 0 原文

浴红衣 2024-08-03 15:48:20

恕我直言，产品肯定是不正确的。非静态类名应该代表一个名词（不是复数），因为你应该能够说“x是一个[类名]”。

显然，产品不适合该方案。 ProductCollection 的作用是：

插图：

var products = new Products(); // products is a Products

var products = new ProductCollection(); // products is a ProductCollection

哪一个“听起来正确”？

关于命名集合类的另一件事：我通常尝试以明确它是什么类型的集合的方式命名集合类。

例如：

class ProductCollection：只能枚举并检索 Count（即仅实现 ICollection 接口）
class ProductList：可以使用 Add( 操作的列表) )、Insert() 等（即实现 IList 接口）
class ProductDictionary：可通过某个键访问的产品字典（即实现 IDictionary 接口）

最后一个可能不明确如果对字典的键是什么有疑问，那么最好指定键类型是什么（例如 ProductDictionaryByString）。但说实话，我很少这样命名，因为大多数时候密钥无论如何都是一个字符串。

Products is certainly not correct IMHO. A non-static class name should represent a noun (not plural), because you should be able to say "x is a [classname]".

Obviously, Products doesn't fit in that scheme. ProductCollection does:

Illustration:

var products = new Products(); // products is a Products

var products = new ProductCollection(); // products is a ProductCollection

Which one "sounds right" ?

Another thing about naming collection classes: I usually try to name collection classes in such way that it is clear what kind of collection it is.

For example:

class ProductCollection: can only be enumerated and the Count retrieved (i.e. only implements ICollection interface(s))
class ProductList: a list that can be manipulated using Add(), Insert(), etc. (i.e. implements IList interface(s))
class ProductDictionary: a dictionary of products accessible by some key (i.e. implements IDictionary interface(s))

The last one can be ambiguous if there could be a doubt what the key of the dictionary is, so it's better to specify what the key type is (like ProductDictionaryByString). But to be honest, I rarely name it this way because most of the time the key will be a string anyway.

回复收藏 0 原文

清引 2024-08-03 15:48:20

.NET Framework 经常使用“Collection”后缀来表示其集合类型。 StringCollection、ObservableCollection、KeyedCollection 等。所以选择 ProductCollection。

回复收藏 0 原文

飘然心甜 2024-08-03 15:48:20

注意到没有人回答你有关 retVal 的问题（或者我可能只是失明了）。虽然我不是专家；关于 retVal 问题，我不是 100% 确定“返回变量的命名”是什么意思，但如果你的意思是这样的：

public void GetSomething(out object retVal) 
{
    retVal = ThingFactory.CreateSomething();
}

我会说，无论约定是什么，不要这样做。这很烦人。只需返回值即可。如果您需要返回不止一件事，那么我认为该方法要么执行不止一件事（方法不应该这样做），要么这些事情应该包装在某种可以返回的逻辑类中。

如果“返回变量的命名”是指这样的内容：

var retVal = ThingFactory.CreateSomething();

那么我会说根据变量的内容来命名变量。它将用来做什么。如果它是一个汽车列表，则将其称为 listOfCars，如果它是稍后吃的一块面包，则将其称为 pieceOfBread 或 pieceOfBreadToBeEatenLater。

希望这对您有所帮助，并且它离某个领域不太远：p

Noticed nobody answered you on the retVal stuff (Or I could just be getting blind). Although I'm not an expert; on the matter of the retVal issue I'm not 100% sure what you mean by "naming of return variable", but if you mean stuff like this:

public void GetSomething(out object retVal) 
{
    retVal = ThingFactory.CreateSomething();
}

I would say, no matter what the convention is, don't do it. It's very annoying. Just return the value instead. If you need to return more than one thing, then I would think the method either does more than one thing (which a method shouldn't) or those things should be wrapped up in some sort of logical class that could be returned instead.

If instead by "naming of return variable" you mean stuff like this:

var retVal = ThingFactory.CreateSomething();

Then I would say name the variable according to what it is. What it is going to be used for. If its a list of cars, call it listOfCars, if it's a piece of bread to be eaten later, call it pieceOfBread or pieceOfBreadToBeEatenLater.

Hope that helped and that it wasn't too far off into a field somewhere :p

回复收藏 0 原文