编码指南 - 一致的变量命名[关闭]答案

【问题标题】：coding guidelines - consistent variable naming [closed]编码指南 - 一致的变量命名[关闭]
【发布时间】：2010-11-09 10:24:48
【问题描述】：

我目前正在为初级开发人员编写编码风格指南，我很好奇是否有人使用常用变量名称列表（用于基本概念）来限制代码库中的混淆？

例如：

对于电子邮件地址：email（而不是：mail、e-mail、address、*mail_address * ...)
对于数据库名称：dbname（而不是：db、dbase、base、database , *database_name*, dbn ...)
对于具有完全限定路径的文件名：filepath（而不是：file、path、*file_name*、pathtofile ...)
相对文件名（无路径）：文件名（而不是：文件、名称、f , ...)
对于配置对象：config（而不是：configuration、conf、vars、...）

你使用类似的约定吗？

编辑：

确切地说：这不是关于格式化约定（camelCaps或*names_with_underscores*），它往往依赖于语言和项目，而是关于命名约定（mail、email 或 courriel），这是所有语言通用的东西（例如使用 i 的约定） , j, k 用于迭代计数器）

【问题讨论】：

En 电子邮件地址不是电子邮件。一封电子邮件有一个发件人地址和一个或多个收件人地址。
取决于语言 ;)。但我认为这恰恰表明了这种约定的目的。
那么，进展如何？您能否将我们链接到您完成的编码风格指南？
当我完成后，我会分享它:) 但这不会在圣诞节前发生（这显然不是我的首要任务）

标签： language-agnostic coding-style

【解决方案1】：

选择一个一致的约定并坚持下去。

您建议的约定不一致。 email 使用的是the English word，因此您应该使用 database_name 而不是 dbname。此外，file_path、file_name、configuration。

简而言之，我建议使用完整的英文单词，用“_”分隔。这是一致的，并且是 Eiffel 中使用的约定。其他系统也可能是一致的。但不是所有的混合。

【讨论】：

【解决方案2】：

这是最糟糕的微观管理。只需说“尝试使用清晰明确的变量名称”。告诉他们更喜欢更长的名称，并使用代码完成来节省输入。

如果您需要教后辈编写对其他人有意义的代码，请使用结对编程和代码审查。

你需要相信他们会做正确的事，并在他们不做的时候纠正他们。

不要自己制定约定，您使用的语言很可能在其文化中已经有约定，例如 Java 中的 camelCaseForVariableNames。跟着那些就行了。

【讨论】：

这行不通，因为我们有许多开发人员（包括我在内）的主要语言不是英语...
@ts：我不明白，什么不起作用，为什么？
要求开发人员使用好名字而不指导他们。他们来自不同的国家，英语水平也不同。除了在英语中使用许多相同术语的同义词外，他们经常开始使用他们的母语来命名 vars、一些方法或制作 cmets（“它不是 API 的一部分，所以没有人关心”的态度）。我们想要的只是让代码维护更容易。制定指导方针与不信任相反。我认为在进行更正之前，最好清楚地表达预期的内容，
所以告诉他们用英文写代码，如果他们使用同义词，只要它们清晰明确。
另外，添加。有时我半开玩笑地说，90% 的编程只是为事物选择好名字。如果有人告诉我我可以使用什么名字，那就像他们试图为我做我的工作，并且会妨碍我的编程能力。

【解决方案3】：

许多人通常更喜欢采用他们使用的语言中已经采用的约定。
例如。在 java 中是 databaseName 而在 C++ 中是 database_name

【讨论】：