Questions tagged «naming»

曾经有很保持指令很好的理由/注册短名称。这些原因不再适用，但是简短的加密名称在低级编程中仍然很常见。 为什么是这样？仅仅是因为旧习惯难以改变，还是有更好的理由？ 例如： Atmel ATMEGA32U2（2010？）：（TIFR1代替TimerCounter1InterruptFlag），ICR1H（代替InputCapture1High），DDRB（代替DataDirectionPortB）等。 .NET CLR指令集（2002）：（bge.s而不是branch-if-greater-or-equal.short）等。 较长的非加密名称不是更容易使用吗？ 在回答和投票时，请考虑以下内容。这里建议的许多可能的解释同样适用于高级编程，但是，普遍的共识是使用由一个或两个词组成的非加密名称（不包括通常理解的首字母缩写词）。 另外，如果您的主要论点是关于纸质图表的物理空间，请考虑这绝对不适用于汇编语言或CIL，此外，如果您向我展示一个简短名称适合但易读的名称的图表，我将不胜感激。 。从无晶圆厂半导体公司的个人经验来看，可读名称恰好适合，并可以使图更易读。 低级编程与高级语言相比有什么不同的核心之处，高级语言使简洁的加密名称成为低级编程而不是高级编程的理想选择？

64 naming  coding-standards  low-level 

对于类名，我总是很难在单数形式和复数形式之间进行选择： CustomerRepository vs. CustomersRepository CustomerService vs. CustomersService CustomerController vs. CustomersController 对于复合名称，则更加困难： OrderCustomerRepository vs.OrderCustomersRepository vs.OrdersCustomersRepository 您喜欢哪种方式，为什么？

58 naming  source-code 

对于返回布尔值的方法，哪个名称更好？ IsSupportContentType 要么 CanSupportContentType

51 naming  naming-standards 

人们的共识似乎是，应该遵循他们所开发平台的惯例。看到： 下划线还是驼峰式？ 命名约定：camelCase与underscore_case？ 然而，PHP似乎没有遵循任何的约定内部（没有惊喜出现），甚至方法和功能（例如mysqli::set_local_infile_default， PDOStatement::debugDumpParams）; 但是，下划线似乎在函数名称中占主导地位。 但是，我找不到的是：PHP中变量的主要命名约定是什么？

51 php  naming  readability  camelcase 

是否应该始终将is布尔变量用作前缀？指示过去的布尔值呢？我应该写isInitialized还是wasInitialized？我应该写属性IsManyMembers还是HasManyMembers？ 有没有最佳做法？还是我应该按照英语规则写作？

49 coding-style  naming  boolean 

我在以下一般指导下遇到了一个极端情况： 变量名词 功能动词 具体地讲，我有一个情况下字是不明确的-它可以是一个动词或名词。在某些情况下，当我们讨论应用程序时，将在同一句子中同时使用这两种方法。 我的目的是确保当我几个月后返回代码部分时，该程序将对将来的开发人员以及我自己仍然可读。 例子之一是带有battery。A battery有一个charge，您也可以装charge()电池。 我认为，同时具有Battery.Charge和Battery.Charge(value)将是混乱的未来发展。 我当前的解决方案是为其中一种或两种情况（变量和函数）简单地选择一个不同的词。我用这种方法的问题是，Battery对象的变量和函数charge与涉及的设计讨论不一致Battery。 我的问题是在命名约定中是否存在另一种/更好的方法来处理此冲突？ 关于该主题的一些其他阅读。没有人真正解决我的问题。 有意义的简洁方法命名准则 变量的命名约定 从https://softwareengineering.stackexchange.com/questions/14169/what-naming-guidelines-do-you-follow选择的答案

48 naming  variables 

我总是很难确定是否应该以getSomethingvs 开头的某个方法findSomething。 问题在于为设计不当的API 创建帮助程序。当从对象获取数据时通常会发生这种情况，这需要对象作为参数。这是一个简单的示例： public String getRevision(Item item) { service.load(item, "revision"); // there is usually more work to do before getting the data.. try { return item.get_revision(); } catch(NotLoadedException exception) { log.error("Property named 'property_name' was not loaded", exception); } return null; } 如何以及为什么要在将此方法命名为getRevision()or时做出决定findRevision()？

47 naming  methods 

我经常看到这样的代码，其中包含常见单词的故意拼写错误，无论好坏，这些单词已成为保留单词： klass或clazz为类：Class clazz = ThisClass.class kount用于计数在SQL：count(*) AS kount 我个人认为这会降低可读性。在我自己的实践中，我发现没有太多案例无法使用更好的名称- itemClass或recordTotal。 JavaDocs for Class中的示例在参数中显示了这一点： public <U> Class<? extends U> asSubclass(Class<U> clazz) 这是否显示合理的用例？

45 coding-style  variables  readability  naming 

通常，当语言的语法要求我命名一个从未使用过的变量时，我将其命名为_。 在我看来，这减少了混乱，让我专注于代码中有意义的变量。我发现它不引人注目，因此可以产生“视线之外，头脑混乱”的效果。 我执行此操作的一个常见示例是在SQL中命名子查询。 SELECT * FROM ( SELECT * FROM TableA JOIN TableB ON TableA.ColumnB = TableB.ColumnB WHERE [ColumnA] > 10 ) _ --This name is required, but never used here ORDER BY ColumnC 另一个示例是未使用的循环变量。 array = [[] for _ in range(n)] # Defines a list of n empty lists …

44 language-agnostic  naming  readability  variables 

调用方法返回的变量名是一个好习惯result吗？ 例如： public Zorglub calculate() { Zorglub result = [...] [...] return result; } 还是应该按类型命名？ public Zorglub calculate() { Zorglub zorglub = [...] [...] return zorglub; } 我曾经在野外看到过这两种情况，如果我需要选择一种原因，是什么原因会使我偏爱前者或后者（或任何更好的名字）？ 我主要是在考虑Java。

44 programming-practices  naming  variables 

布尔方法是否应该始终采用肯定形式，即使仅将它们用作否定形式也是如此？ 假设我想在创建实体之前检查一个实体是否存在，我的论点是下面的第一种形式要好于第二种形式，无论该方法是否曾经以肯定形式使用过。 总而言之，我觉得if(!affirmative)比容易阅读if(negative)。我有一个不同意的同事，有何想法？ 第一种形式： int entity_id = 42; if(!entity_exists(entity_id)) create_entity(entity_id); 第二种形式： int entity_id = 42; if(entity_not_exist(entity_id)) create_entity(entity_id);

43 naming  functions 

我不确定该怎么做： 我们从自己工具中的外部工具获取数据。该数据用荷兰语编写。我们正在用英语编写Java代码。然后我们应该将此荷兰语翻译为英语还是保留为荷兰语？例如，我们有两个部门：Bouw（英语建筑）和Onderhoud（英语维护）。 创建逻辑是否合理： public enum Department { BOUW, ONDERHOUD } 要么： public enum Department { CONSTRUCTION, MAINTENANCE } 甚至： public enum Afdeling { BOUW, ONDERHOUD } （在荷兰语中系部门）

39 naming  translate 

我从这里取消了“蓝精灵命名”一词（21号）。为了省去不熟悉的人的麻烦，Smurf命名是为一堆相关的类，变量等添加通用前缀的行为，因此您最终将“ a SmurfAccountView传递SmurfAccountDTO给SmurfAccountController”，等等。 我通常听到的解决方案是创建一个smurf名称空间并删除smurf前缀。通常，这对我来说很好，但是我遇到了两个问题。 我正在与一个图书馆一起Configuration上课。它可以被调用，WartmongerConfiguration但是在Wartmonger命名空间中，因此它被称为Configuration。我同样有一个Configuration可以调用的类SmurfConfiguration，但是它在Smurf命名空间中，因此是多余的。我的代码中有些地方Smurf.Configuration出现在旁边，Wartmonger.Configuration并键入完全限定的名称比较笨拙，并且使代码的可读性较差。处理一个SmurfConfigurationand 会更好（如果这是我的代码而不是一个库）WartmongerConfiguration。 我Service在Smurf命名空间中有一个可能称为的类SmurfService。Service是运行Smurf作业的复杂Smurf库顶部的外观。SmurfService似乎是一个更好的名字，因为Service没有Smurf前缀是非常通用的。我可以接受的是，这SmurfService已经是一个通用且无用的名称，而去除蓝精灵只是使这一点更加明显。但是它本来可以命名为Runner，Launcher等等，但对我来说仍然会“感觉更好”，SmurfLauncher因为我不知道a的Launcher作用，但是我知道a的SmurfLauncher作用。您可能会争辩说a的Smurf.Launcher行为应该与a的行为一样明显Smurf.SmurfLauncher，但我可以看到`Smurf.Launcher是某种与安装相关的类，而不是启动smurfs的类。 如果有一种开放和封闭的方式来处理这两种情况，那将是很好的。如果不是，有什么常用的方法可以减轻他们的烦恼？

39 naming  coding-standards 

仅通过参数名称（而不是类型）来区分方法就足够了吗？还是更明确地命名呢？ 例如T Find<T>(int id)VS T FindById<T>(int id)。 是否有充分的理由更明确地命名（即添加ById）而不是仅保留参数名称？ 我能想到的一个原因是方法的签名相同但含义不同。 FindByFirstName(string name) 和 FindByLastName(string name)

36 c#  naming  coding-standards  conventions  method-overloading 

有一些名字，如果您发现自己喜欢这些名字，那您就知道自己已经搞砸了。 例如： XxxManager 这很不好，因为一个类应该描述该类做什么。如果您能为该班级提出的最具体的词是“管理”，则该班级太大。 还有哪些其他命名反模式？ 需要澄清的是，我并不是在问“名字不好”的问题-这个问题完全是主观的，无法回答。我问，“什么名字表示系统的总体设计问题”。也就是说，如果您发现自己想调用组件Xyz，则可能表明该组件不安全。还要注意，每条规则都有例外-我只是在寻找警告标志，以指示何时确实需要停止并重新考虑设计。

35 naming  anti-patterns