关于命名事物的建议

发布于 2024-12-12 16:05:03 字数 647 浏览 0 评论 0原文

我有一个列表,我正在尝试决定将其称为 item 还是 items。如果我将其称为 items,那么很明显 foo(items) 正在传递一个项目列表,而不是单个项目。另一方面,我更喜欢写 item[i] 来引用特定元素,而不是 items[i] (因为我会说“给我带项目 7 ”,而不是“给我拿东西 7”)。

我也有一个函数,我正在尝试决定将其称为 value 还是 get_value。如果我称之为 value,我可以写出很好的语句,例如 value_squared = value() ^ 2 (我认为它比 value_squared = get_value() ^ 2 更好)),但我可能会在编写诸如 value = value() 之类的东西时遇到问题,而 value = get_value() 则不会有问题。

(我知道这个问题没有正确的答案,这是两个问题。我愿意接受编辑/删除/移动/拆分它等的建议,因为我不太确定什么是正确的然而,我希望看到一些回应,因为我想以其他人易于理解的方式编写代码。)

I have a list, and I'm trying to decide whether to call it item or items. If I call it items, it's clear that foo(items) is being passed a list of items and not a single item. On the other hand, I would prefer to write item[i] to refer to a particular element instead of items[i] (because I would say "bring me item 7", not "bring me items 7").

I also have a function, and I'm trying to decide whether to call it value or get_value. If I call it value, I can write nice statements like value_squared = value() ^ 2 (which I think is nicer than value_squared = get_value() ^ 2), but I might run into problems writing stuff like value = value(), whereas value = get_value() would not be problematic.

(I know that this question does not have a right answer, and that it is two questions. I am open to suggestions that I edit/remove/move/split it, etc., as I'm not quite sure what the right thing to do is. I would, however, like to see some responses, since I'd like to write code in a way that is easy for others to understand.)

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

凉墨 2024-12-19 16:05:06

这始终与偏好有关,做你自己的事情,或者如果你在一个团队中,那么团队会做什么。

这与你工作的商店有关,而不是对或错的问题。更何况这只是一个名字。

就我而言,我不喜欢将 "s"'s 添加到任何内容中。例如,如果我正在设计一个带有相关评论的问题数据库系统,我将我的问题表称为“问题”,因为一个元组(或行)代表一个问题。我的评论表也是如此,我最终将其命名为 Comment。我不在乎所有行的总数代表“问题”,对我来说,该表代表一个实体。 但这又是个人喜好。

您还提到了这一点:

另一方面,我更喜欢写 item[i] 来引用特定元素而不是 items[i] (因为我会说“给我带来项目 7”,而不是“给我带来项目 7”)。

但是如果你的列表名为 items 那么如果你做了 items[i]代码> 看到你所指的应该是显而易见的到列表中的一项。对我来说,这是非常可读的。

至于你的第二点,这实际上取决于,你真的想使用价值吗?在某些语言中,这可能是保留字。如果函数返回一个值,为什么不使用 getValue() 呢?我不认为这有什么坏处。只要与您的整个项目保持一致,这将使您和其他查看您的代码的人受益。

This is always about preference, do what you or if you are on a team-what the team does.

It's about the shop you work at and not about being right or wrong. Besides it's just a name.

In my case I don't like to add "s"'s to anything. For instance, if I am designing a database system of issues with related comments I call my Issues table Issue, because one single tuple (or row) represents a single issue. Same for my Comments table I end up naming it Comment. I don't care that the total of all rows represents "Issues", to me the table represents one entity. But again this is personal preference.

You also mentioned this:

On the other hand, I would prefer to write item[i] to refer to a particular element instead of items[i] (because I would say "bring me item 7", not "bring me items 7").

But if your list is called items then if you did items[i] it should be a no brainer to see that you are referring to one item in the list. To me this is very readable.

As for your second point it really depends, do you really want to use value? In some languages that may be a reserved word. If the function returns a value why not getValue() ? I don't see any harm in that. Just be consistent with your entire project, it will benefit you and others looking at your code.

神仙妹妹 2024-12-19 16:05:05

我喜欢列表的复数名称和函数的“get”前缀。我认为立即知道它们是列表和函数比负面因素更重要。

I like plural names for lists and 'get' prefix for functions. I think immediately knowing that they are lists and functions outweighs the negatives.

请你别敷衍 2024-12-19 16:05:04

将列表(“容器”)称为“项目”。将列表中的每个元素称为“项目”:)

“items[i]”是非常合适的。

也是如此:

  foreach (ListItem item in items) {
    ...

Call the list (the "container") "items". Call each element in the list an "item" :)

"items[i]" is perfectly appropriate.

So is:

  foreach (ListItem item in items) {
    ...
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文