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

有关于如何命名变量的教程吗？

发布于 2024-09-13 09:56:07 字数 52 浏览 4 评论 0 原文

正如您可能从我之前的帖子中看出的那样，我有可怕的命名约定。您知道有关如何命名事物的教程吗？

原文

as you can probably tell from my previous posts i have horrific naming conventions. do you know of any tutorials dealing with how to name stuff?

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

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

发布评论

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

评论（12）

把梦留给海 2024-09-20 09:56:07

我认为不会有任何好的教程，因为没有任何硬性规则。这里有一些提示：

  • 符合约定：循环变量为i、j和k； *args 和 **kwargs 中包含可变数量的参数；使用驼峰命名法或下划线命名法。

  • 保持一致。

  • 要简洁。 list_of_drugs_used_in_this_program 比 drugs 更不清楚。同样，您不需要在名称中包含变量的数据类型：drugs_list 是多余的。

  • 不要过度使用下划线。我从来不需要超过一个。 2+ 正在推动它。

  • 永远不要永远使用元句法变量 ( foo, spam...) 在任何快速而肮脏的例子中。 method1 也已过时。

但你可以总结这一切：

别傻了。

嘻嘻。

变量命名约定通常可以
变成一场宗教战争，但我
当我宣布时完全有信心
世界上最糟糕的变量名称是：

<前><代码>$数据

当然是数据！就是这样
变量包含！这就是他们的全部
永远可以包含。就好像你是
收拾好你的物品准备搬去
一座新房子，在
你用大黑色记号笔写的框，
“事情。”

http://www.oreillynet.com/onlamp/blog/2004/ 03/the_worlds_two_worst_variable.html

I don't think there will be any good tutorials, because there aren't any hard-and-fast rules. Here are some tips:

  • Conform to convention: Loop variables are i, j, and k; variable numbers of arguments go in *args and **kwargs; use camelCase or underscored_names.

  • Be consistent.

  • Be concise. list_of_drugs_used_in_this_program is much less clear than drugs. Similarly, you don't need to include the datatype of the variable in the name: drugs_list is redundant.

  • Don't go overboard with the underscores. I've never needed more than one. 2+ is pushing it.

  • Never ever ever use metasyntactic variables (foo, spam...) in anything but quick-and-dirty examples. method1 is also out.

But you could summarise all of that with:

Don't be silly.

Tee hee.

Variable naming conventions can often
turn into a religious war, but I’m
entirely confident when I declare The
World’s Worst Variable Name to be:

$data

Of course it’s data! That’s what
variables contain! That’s all they
ever can contain. It’s like you’re
packing up your belongings to move to
a new house, and on the side of the
box you write, in big black marker,
“matter.”

http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html

回复 原文
○闲身 2024-09-20 09:56:07
  1. 完全遵循一个糟糕的惯例比不同的良好“惯例”的组合要好（如果不遵守，它们就不再是惯例了）。
  2. 然而，如果某个约定比被忽略的情况更不明确，则应该被忽略。

这是我唯一会声明为任何规则的两条。除此之外，约定的偏好是一个很快就会变成咆哮的意见问题。这篇文章的其余部分正是如此，不应被解读为其他内容。

  1. 对于集合，请使用自然语言复数。在英语中，这意味着数据、模式、子项、索引、标准、公式（实际上还有焦点、鹅、脚、男人、女人、牙齿），而不是像数据模式、子项、索引、标准、公式（以及类似的）这样的虚构词。焦点、鹅、脚、男人、女人、牙齿，不管你信不信，我实际上已经看到其中一些在使用）。驼峰式命名和缩写对英语本身造成的损害已经够多了，而且还没有做更多的事情。好吧，我从未见过数据，但我见过元复数数据。亲爱的阿拉迪亚，为什么？
  2. 也就是说，即使您使用不同的英语方言，也请使用美式英语作为名称。大多数具有此类方言的程序员在 12 岁时就已经学会将“颜色”视为计算机环境中颜色的单词，并且该原理适用范围更广。如果我们能处理“颜色”（韦伯斯特最糟糕的混蛋之一），我们就可以处理-ize和-ization（-ise和-ization无论如何都是法国18世纪的伪作，美国人在这方面是传统主义者）。
  3. 同样，如果您不确定如何拼写用作整个或部分名称的单词，请查找它（谷歌搜索并查看谷歌怎么说）。有人可能会花很长时间因为你的拼写错误而分心，这些错误在运行的代码中如此广泛地分布，以至于修复它变得令人畏惧。
  4. 匈牙利语很糟糕（在许多现代语言中，尽管在某些语言中它占有一席之地），但原则是好的。如果您可以瞬间区分 const、static、实例、局部和参数变量，那就太好了。如果你能立即说出意图，那也很好。
  5. 与此相关的是，公共变量之前的 _ 使它们不符合 CLR。这对于私有变量来说实际上是一件好事（如果您将它们公开以进行快速实验，并且忘记修复可见性，编译器会警告您）。
  6. 记住波斯特尔定律，“在你所做的事情上要保守，在你从别人那里接受的事情上要自由”。其中一个示例是，即使您使用的是不区分大小写的语言，也要表现得好像您正在使用区分大小写的语言。与此相关的一个问题是，更加坚持公开名称而不是私人名称。还有一个就是更多地关注遵守惯例，而不是抱怨那些不遵守惯例的人。
  1. A bad convention followed fully is better than a combination of different good "conventions" (which aren't conventions at all any more, if they aren't kept to).
  2. However, a convention that is making something less clear than if it had been ignored, should be ignored.

Those are the only two I would state as any sort of rule. Beyond that convention preferences are a matter of opinions quickly turning into rants. The rest of this post is exactly that, and shouldn't be read as anything else.

  1. For collections, use natural language plurals. In English, this means data, schemata, children, indices, criteria, formulae (and indeed foci, geese, feet, men, women, teeth) not made-up words like datums schemas, childs, indexes, criterions, formulas (and likewise focuses, gooses, foots, mans, womans, tooths, believe it or not I've actually seen some of those in use). Camel-casing and abbreviatiating does enough damage to English as it is, without doing more. Okay, I've never seen datums, but I have seen the meta-plural datas. Sweet Aradia, why?
  2. That said, use American English for names, even if you use a different dialect of English. Most coders with such dialects have learnt to think of "color" as a word for colours in a computer context by the age of 12, and the principle applies more widely. If we can deal with "color" (one of Webster's worse bastardisations) we can deal with -ize and -ization (-ise and -isation is a pseudo-French 18th C affectation anyway, the Americans are the traditionalists on this one).
  3. Similarly, if you aren't sure how to spell a word that you are using as the whole or part of a name, look it up (google it and see what google says). Somebody may spend a long time distracted by your misspelling that is so liberally distributed throughout running code as to make fixing it daunting.
  4. Hungarian is bad (in many modern languages, though in some it has its place) but the principle is good. If you can tell a const, static, instance, local and parameter variable from each other in a split-second, that's good. If you can tell something of the intent immediately, that's good too.
  5. Related to that, _ before public variables makes them non CLR compiant. That's actually a good thing for private variables (if you make them public for a quick experiment, and forget to fix the visibility, the compiler will warn you).
  6. Remember Postel's Law, "be conservative in what you do, be liberal in what you accept from others". One example of this is to act as if you are using a case-sensitive langauge, even if you're using a case-insensitive one. A related one is to be more of a stickler in public names than private ones. Yet another is to pay more attention to following conventions well than to complaining about those who don't.
回复 原文
剪不断理还乱 2024-09-20 09:56:07

这里的所有答案都是非常有效的。最重要的是：保持一致。

也就是说，这是我的规则 (C#)：

  • 驼峰标识符 - 我个人
    发现这比
    下划线
  • Public 属性开始
    带有大写字母
  • Something I
    永远不应该碰以 a 开头的
    下划线——例如，支持
    属性的字段只能是
    从财产上感动。如果我有
    在别处强调，我知道我是
    错误的
  • 应用程序匈牙利语在哪里
    适当的——描述行的整数
    ID也许可以被命名
    rowSelected、rowNextUnread 等
    等等。这不同于
    匈牙利系统，这将标志着
    它们作为整数，例如iSelected，
    iNextUnread。匈牙利系统
    并没有增加太多，如果有的话，在哪里
    Apps Hungarian 提供信息
    type 没有：它告诉我添加
    rowItemsPerPage 和 colSelected 是
    无意义的操作，尽管
    编译得很好。

All the answers here are quite valid. Most important: be consistent.

That said, here are my rules (C#):

  • camelCase identifiers -- I personally
    find this much easier to read than
    underscores
  • Public properties start
    with a capital letter
  • Something I
    should never touch starts with an
    underscore -- example, the backing
    field to a property should only be
    touched from the property. If I have
    underscores elsewhere, I know I'm
    wrong
  • Apps Hungarian where
    appropriate -- ints describing row
    IDs perhaps could be named
    rowSelected, rowNextUnread, et
    cetera. This is different than
    Systems Hungarian, which would mark
    them as ints such as iSelected,
    iNextUnread. Systems Hungarian
    doesn't add much if anything, where
    Apps Hungarian gives information the
    type doesn't: it tells me adding
    rowItemsPerPage and colSelected is a
    meaningless operation, even though it
    compiles just fine.
回复 原文
枕头说它不想醒 2024-09-20 09:56:07

不是教程...更像是指南/最佳实践之类的东西：
http://msdn.microsoft.com/en-us /library/xzf533w0(VS.71).aspx

Not a tutorial... more like a guide/best practice kind of thing:
http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

回复 原文
浅笑依然 2024-09-20 09:56:07

我建议购买一本 Robert C. Martin 所著的《Clean Code》。它充满了很好的建议，从命名约定到如何编写易于理解的函数等等。绝对值得一读。我知道自从阅读它以来它影响了我的编码风格。

I'd recommend purchasing a copy of "Clean Code" by Robert C. Martin. It is full of great suggstions ranging from naming conventions to how to write easy-to-understand functions and much more. Definitely worth a read. I know it influenced my coding style since reading it.

回复 原文
本宫微胖 2024-09-20 09:56:07

嗨，对我来说，您应该始终使用最明确的名称：

string_to_hash = "blabla"
hash(sring_to_hash)

并尊重 pep8 风格指南。那么您的代码应该非常容易阅读。

hi for me you should always put the most explicit names:

string_to_hash = "blabla"
hash(sring_to_hash)

and respect the pep8 style guide. You code should then be very easy to read.

回复 原文
瞎闹 2024-09-20 09:56:07

关于命名约定的具体细节有许多不同的观点，但总体要点可以概括为：

每个变量名称应该相关
无论数据存储在
多变的。

您的命名方案应该一致。

所以一个主要的禁忌是
单字母变量（有些人
使用 i 和 j 进行索引循环，其中
没关系，因为每个程序员都知道
它们是什么。尽管如此，我还是更喜欢
'idx' 而不是 'i'）。还出的是
像“method1”这样的名称，没有任何意义
- 它应该表明变量包含什么。

另一个（不太常见）约定是“匈牙利”表示法，其中数据类型以变量名称为前缀，例如“int i_idx”。这在现代面向对象的编程语言中毫无用处。更不用说公然违反 DRY 原则了。

第二点，一致性，也同样重要。驼峰式、大驼峰式，等等 - 只是不要无缘无故地在它们之间切换。

您会发现命名约定因语言而异，并且公司通常会有自己的命名规则。

正确命名变量是一项值得的投资，因为当您稍后维护代码并且忘记了所有内容的含义时，它将带来回报。

There are many different views on the specifics of naming conventions, but the overall gist could be summed up as:

Each variable name should be relevant
to whatever data is stored in the
variable.

Your naming scheme should be consistent.

So a major no-no would be
single letter variables (some people
use i and j for indexing loops, which
is OK because every programmer knows
what they are. Nevertheless, I prefer
'idx' instead of 'i'). Also out are
names like 'method1', it means nothing
- it should indicate what the variable holds.

Another (less common) convention is the 'Hungarian' notation where the data type is prefixed to the variable name such as 'int i_idx'. This is quite useless in modern, object oriented programming languages. Not to mention a blatant violation of the DRY principle.

The second point, consistency, is just as important. camelCase, UpperCamelCase, whatever - just don't switch between them for no reason.

You'll find that naming conventions vary from language to language and often, a company will have their own rules on naming.

Its a worthwhile investment to properly name your variables because when you come to maintain your code much later on and you have forgotten what everything means, it will pay dividends.

回复 原文
南薇 2024-09-20 09:56:07

您没有指定您要查找的语言。由于您的问题被标记为 .NET，因此这是我在编写 C# 代码时遵循的文档： http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx。

You didn't specify what language are you looking for. Since your question is flagged .NET, here is a document I follow when writing C# code: http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx.

回复 原文
℉服软 2024-09-20 09:56:07

你读过《代码大全》吗？他在书中对此进行了完整的论述。这绝对是我在印刷品中见过的最好的命名策略...并且很容易找到大约 1000 名程序员将其命名为程序员和程序设计的 5 个顶级资源之一。

只是我的 0.05 美元

Have you read Code Complete? He does a full treatise on this in the book. Definitely the best naming strategy I've seen in print... And it's easy to find like 1000 programmers at the drop of a hat who name this one of the top 5 resources for programmers and program design.

Just my $.05

回复 原文
浪漫人生路 2024-09-20 09:56:07

我可以为我的书“数据库设计的理智方法”中的“名称”章节制作一个无耻的插件吗？我专门谈论数据库中事物的名称，但大多数相同的考虑因素也适用于程序中的变量。

Can I make a shameless plug for the "Names" chapter in my book, "A Sane Approach to Database Design" ? I'm specifically talking about names for things in databases, but most of the same considerations apply to variables in programs.

回复 原文
真心难拥有 2024-09-20 09:56:07

目前尚不清楚您的问题是否与 Python 命名约定有关。

如果是这样，对于初学者来说，我会尝试遵循这些简单的规则：

  • ClassName - 类名大写
  • variable_name - 变量小写和下划线（我尝试保留它们最多两个字）

It's not clear if your question relates to Python naming conventions.

If so, for starters I would try to follow just these simple rules:

  • ClassName - upper case for class names
  • variable_name - lower case and underscore for variables (I try to keep them at two words maximum)
回复 原文
~没有更多了~

关于作者

请止步禁区

暂无简介

0 文章
0 评论
23 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

daid

文章 0 评论 0

我心依旧

文章 0 评论 0

晒暮凉

文章 0 评论 0

微信用户

文章 0 评论 0

DS

文章 0 评论 0

〆凄凉。

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文