language-agnostic - 您是否使用特定的约定来命名互补变量？

Question

我经常发现自己试图为互补的变量对取个好名字。其中两个变量表示相反的概念，两个参与者在某种形式的对话中，等等。

这可能通过一个反例更好地解释 - 我维护一个应用程序，它打印两个图形作为印刷广告的一部分。它们以 和 的形式存储在数据库中TopLogo，LowerLogo每次使用它们时我都必须停下来仔细检查，因为我希望top补充bottom，并且lower应该补充upper。

有一些我认为效果很好的明显例子：

client / server
source / target用于将数据或文件从一个变量复制/移动到另一个变量
minimum / maximum

但是有些概念不适合这种简洁的命名方案。例如，在对记录进行分页时，“last”是指“final”还是“previous”？我最近看到了一些使用firstPage,和完全避免模棱两可的代码previousPage，我认为这很糟糕，因此提出了这个问题。nextPagefinalPagelastPage

您有什么特别简洁的变量名对想与我们分享吗？（如果它们的长度相同，则加分，这使得等宽字体中的代码更加整洁。）

Answer 1

与各种代码样式约定一样，一致性是您应该努力的目标。

我会让开发团队就“源/目标”或“从/到”等常见场景的“标准”前缀对达成一致，然后在整个项目中坚持使用它们。只要每个开发人员都知道代码库中特定前缀的含义，就更容易避免误解。

如果变量是公共 API 的一部分，则应在文档中阐明规则的例外情况，或者如果其可见性仅限于单个类或方法，则应在代码中的注释中阐明。

Answer 2

虽然在明显的情况下确实尝试在语义上保持一致——例如，最大值与最小值而不是“最低”——在结构良好的 OO 代码（我知道这不是所有代码）中，问题消失了IDE。类很短，方法很短，每个方法中的变量也很少。因此，只要变量对是明确的，您调用什么变量对并不重要。你的代码可能看起来不专业，但真正的质量在于代码，而不是代码的外观。

如果有好的 JavaDoc 或任何文档系统，并且如果有好的类名，问题就会进一步消失。例如，如果你有一个Connection类的实例并且它有一个方法叫做 方法setDestination，那没关系，但是如果你知道 setDestination 接受一个被调用的参数destination并且它是Server类的，那么你很酷......即使你可能更喜欢称它为target、aimHere、placeToSendTheData或whatever（以及相应的名称、source、comingFromHere和placeToGetTheDataFrom）。再加上文档系统说明了这件事的用途，那是无价的。

接下来的事情可能听起来很愚蠢，我相信我会在 StackOverflow 上被否决，但独特的非专业听起来的变量名称有一个很大的优势：我知道我的变量有类似placeWeWantTheDataToGo的名称（并且 IDE 负责输入它），但是做 JDK 的“认真”的人永远不会使用这种愚蠢的名字。所以我立即知道变量是我的一个。顺便说一句，当我与西班牙和意大利的开发人员一起工作时，他们使用西班牙变量名编写代码（并非总是如此，但通常如此）。这会产生同样的效果：我们可以很快看到Conexion该类是我们的，但Connection该类不是我们的。

[另外，不要输入变量名，而是在代码中的某处为它们分配一个常量字符串并使用它，所以如果他们将其称为 lower 或 downer 而不是 low，你仍然可以。]

Answer 3

在我的数据库中，您会发现许多包含一对名为start_dateand的列的有效状态时态（“历史”）表end_date。那么，对我来说没有任何奖励积分，因为我宁愿使用常用的“结束”，也不愿尝试想出一个与“开始”字数相同的直观替代方案。

我倾向于更喜欢这些通用术语，即使更多特定于上下文的术语可能是可行的，例如更喜欢employee_start_date（employee_hire_date如果他们的工作开始的原因不是正式雇用，例如他们的公司是收购的对象）。也就是说，我更person_birth_date喜欢person_start_date:)

Answer 4

是的，我确实尝试系统地命名互补的变量集，以使对称性清晰。这并不总是那么容易；有时，甚至不可能。好吧，使用我为自己制定的规则是不可能的——这意味着我通常会尝试让名字的长度相同。'top' 和 'lower' 的例子会让我发疯（假设我还没有发疯，这远非确定）；我可能会使用“上”和“下”，因为它们的长度相同；由于长度的不同，“顶部”和“底部”也会让我感到沮丧。