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

Question

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

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

我认为有一些明显的例子可以很好地运作：

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

但是有一些概念不适合这种简洁的命名方案。例如，在翻阅记录时，“最后”是指“最终”还是“上一次”？我最近看到一些使用firstPage，previousPage，nextPage和finalPage的代码完全避免了lastPage，我认为这是非常好的，因此问题

您是否有任何特别整齐的变量名称对，您需要与我们分享？ （如果它们的长度相同，则可以加分，这使得代码在等宽字体中更加整洁。）

Answer 1

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

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

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

Answer 2

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

如果存在良好的JavaDoc或任何文档系统，并且具有与它们一起使用的良好类名，则问题会进一步消失。例如，如果你有一个Connection类的实例，并且它有一个名为setDestination的方法，那没关系，但如果你知道setDestination采用一个名为destination的参数，那就是对于Server课程，您很酷......即使您可能更喜欢将其称为target，aimHere，placeToSendTheData或whatever（以及相应的名称source，comingFromHere和placeToGetTheDataFrom）。另外，doc系统说 是什么，这是无价的。

接下来的事情可能听起来很愚蠢，我确信我会在StackOverflow上投票，但是独特的非专业声音变量名称有很大优势：我知道我的变量的名称类似于placeWeWantTheDataToGo （并且IDE会负责输入它），但是执行JDK的“严肃”人员永远不会使用这些愚蠢的名字。所以我立即知道变量是我的变量之一。顺便说一句，当我与西班牙和意大利的开发人员合作时，他们使用西班牙语变量名称编写代码（并非总是，但通常）。这会产生同样的效果：我们可以很快发现Conexion类是我们的，但Connection类不是。

[另外，不是输入你的变量名，而是在你的代码中的某个地方为它们分配一个常量字符串并使用它，所以如果它们将它调低或降低而不是低，你仍然可以。]

Answer 3

在我的数据库中，您会发现许多有效状态的时态（“历史记录”）表，其中包含一对名为start_date和end_date的列。那么，对我来说没有奖励积分，因为我宁愿使用常用的“结束”而不是尝试用与“开始”这个词相同数量的字符来提出一个直观的替代品。

我倾向于更喜欢这些通用术语，即使更多特定于上下文的术语可能是可行的，例如更喜欢employee_start_date而不是employee_hire_date（如果他们的工作开始的原因不是正式招聘，例如他们的公司就是收购的主题）。也就是说，我希望person_birth_date超过person_start_date：）

Answer 4

是的，我确实试图系统地命名互补的变量集，以便明确对称性。这并不容易;有时，甚至不可能。好吧，不可能使用我为自己制定的规则 - 这意味着我通常会尝试使用相同长度的名称。 “顶部”和“较低”的例子会让我感到沮丧（假设我已经不是很吵了，这远非确定）;我可能会使用'upper'和'lower'，因为它们的长度相同;由于长度不同，'top'和'bottom'也会让我感到沮丧。