为什么在方法名称中使用连词是不好的命名约定？[关闭]

12

在我的团队中，我们与一些软件架构师紧密合作。他们批准我们项目的所有设计决策，进行一些代码审查等。

我们的项目主要包括使用Symfony 2框架以PHP实现的后端功能。因此，在语法上，代码，命名约定和项目结构看起来几乎与Java的外观相同（Symfony 2鼓励采用这种结构）。我之所以这样说是因为特定于Java的约定也适用于我们的情况（如果可能）。

最近，他们提出了一些令我感到很奇怪的东西：所有方法的名称中都应带有连词，例如getEntityOrNull，setValueOrException等等。

这样的命名约定对我来说是非常错误的，但是我无法提出任何具体的论据或在线文章/页面来专门挑战这一点。

我想到的唯一的东西是：

此类信息应出现在方法的注释中，例如@return或@throws
在方法名称中使用连词（“和”，“或”等）通常表明未适当遵守“单一责任原则”

反对该命名约定的其他一些具体论点是什么？

php conventions naming-standards

— 拉杜·穆塞亚（Radu Murzea）
source

通常，您不能

— 2014年

5

the use of conjunctions ("and", "or" etc.) in method names usually suggest that the Single Responsibility Principle is not properly respected

对于您列出的示例，情况并非如此，在该示例中，连词用于阐明处理故障的机制，而不是表示它可能会做一件事或另一件事。甚至最狭窄定义的函数也可能具有合法的故障情况，例如弹出一个空堆栈。

— Doval 2014年

4

考虑：（1）使用“可选”而不是“或null”。“ GetOptionalEntity”听起来比“ GetEntityOrNull”更好。（2）.NET基类库使用以下约定：如果您有两个仅在抛出方法上不同的方法，请命名一个不能抛出“ TryBlah”的方法。例如，Int32.TryParse和Int32.Parse-都将字符串解析为整数，但是前者返回一个布尔值，指示成功，而后者则抛出失败。

— 埃里克·利珀特

我不会将后缀用于throwing变体，但会使用一个后缀来返回null。可能是Try...，...OrNull，...OrDefault。@EricLippert这不是.net中唯一的约定。考虑Singlevs. SingleOrDefault，它与OrNull建议的OP 非常接近。

— CodesInChaos

11

他们这样做可能是由于命名冲突。我假设您不能有两种名为的方法getEntity，一种可能引发异常，另一种可以返回null。因此，您必须相应地命名它们。

我不喜欢用一种不同的方法来调用同一方法的实践，除非它正在执行仅该特定类可以执行的更改。

换句话说，如果getValueOrNull只是调用getValueOrException，捕获异常，然后返回null，则可以由调用者执行。它会使类杂乱无章，而这些方法实际上并没有贡献任何有用的东西。相反，我希望使用getValue，并且知道它会引发异常。更好的是，我更希望知道所有get方法都可能抛出异常，而没有一个返回，null因此行为在我的整个项目中是统一的，或者相反，所有可能都返回return null，并且知道调用者必须在抛出异常时抛出异常所希望的。

但是，您也不必为此负责。我的建议是提出来，但不要流血于琐事。最终，这些命名约定的责任落在他们的肩上，无论它们是否接受您的建议，并且由于它是驴友，所以我认为，我的拙劣说法是拒绝。

— 尼尔
source

如果只选择一个，则最好返回null（或者更好，一个Optional / Maybe类型），因为投掷相对昂贵。编写一个检查值是否无效并抛出异常的助手不会增加太多开销。但是，当您需要不抛出版本时，吞下异常不会使您退回抛出它所带来的性能损失。

— Doval 2014年

1

@Doval好点，也许更重要的是，异常应该是例外。如果您经常抛出异常，那么您就没有正确使用它们。返回的唯一问题null是null在某些情况下实际上可能是有效的返回，因此您将不得不偏离规范并在此类情况下引发异常。

— 尼尔

3

尽管使用连词通常表示违反了SRP，但在这种情况下，它仅表示穷人的代数数据类型的返回值，该值可以是两个值之一，也可以null是“成功”值。

他们使用一种匈牙利表示法来弥补类型系统中的弱点，即缺乏不可为空的类型。换句话说，无法在@return批注中指定该函数永远不会返回null，相反，也无法在@return批注中指定该函数可能会返回null。

另外，我相信@throws注解在php中不是强制性的，因此缺少注解并不表示没有异常，尽管可以通过在样式指南中将注解强制性来解决。

考虑到您所使用语言的这些限制，这并不是一种完全不合理的样式。

— 卡尔·比勒费尔特
source

2

在我的代码中，有时我会创建名称为getEntity（）和getEntityOrNull（）之类的方法对。该名称使预期行为明确。如果getEntity（）没有找到实体，则将引发异常。getEntityOrNull（）将返回null。

这样，调用代码将变得更加清晰。如果调用代码必须具有实体，则getEntity将解决问题。如果实体是某种可选的东西，那么getEntityOrNull是选择的方法。

可以用一个方法完成同一件事，但是这会将一些负担转移给了调用程序。您始终需要测试是否为空，或者需要一个try / catch块。无论哪种方式，每次调用该方法时都需要重复多余的代码。

如果您的架构师没有使用这些方法对，那么可以，我会质疑是否需要后缀。

从来没有真正看到过setValueOrException方法。不能想到一个好的通用用例。

您可以考虑问建筑师为什么。我认识的人总是很乐意解释他们的决定。通常是非常详尽的（有时甚至是令人费解的）细节。

— 塞拉德
source

那个getEntity会在失败时抛出异常对我来说还不是很清楚，我期望一个简单的NULL。

— Elise van Looij，2013年

1

您的两个论点是正确的。但是，如果他们是负责决定命名约定的人，请不要为自己不同意而感到难过。

在使用它时，应该说服他们不要使用“ get”和“ set”部分，除非这些方法实际上确实直接设置或获取了成员变量。

— 埃本
source