Questions tagged «naming»

通常，尤其是在库中，程序包包含围绕单个概念组织的类。示例： xml，sql，user，config，db。我认为我们所有人都很自然地认为这些软件包以单数形式正确。 com.myproject。XML .Element com.myproject。SQL ■连接 com.myproject。用户。用户 com.myproject。用户 .UserFactory 但是，如果我有一个实际上包含单个类型的实现集合的包-例如任务，规则，处理程序，模型等，哪个更可取？ com.myproject。任务 .TakeOutGarbageTask com.myproject。任务 .DoTheDishesTask com.myproject。任务 .PaintTheHouseTask 要么 com.myproject。任务 .TakeOutGarbageTask com.myproject。任务 .DoTheDishesTask com.myproject。任务 .PaintTheHouseTask

226 object-oriented  naming  packages 

我的T-SQL老师告诉我们，在没有任何进一步说明的情况下，将PK列“ Id”命名为不良做法。 为什么命名表PK列“ Id”被认为是不良做法？

209 sql  naming  tsql 

对于我目前正在使用的代码库，这已经变得非常沮丧。我们的许多变量名都很简短且没有描述性。我是该项目上剩下的唯一一名开发人员，并且没有关于它们大多数功能的文档，因此我不得不花更多的时间来跟踪它们的含义。 例如，我正在阅读一些更新光学表面定义的代码。开始时设置的变量如下： double dR, dCV, dK, dDin, dDout, dRin, dRout dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1)); dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1)); ... and so on 也许只是我一个人，但实际上它们告诉我的内容并没有告诉我，这使得进一步理解代码变得困难。我所知道的是，它是一个变量，该变量从某个地方的特定表中解析出特定行。经过一番搜索，我发现了它们的含义： dR = radius dCV = curvature dK = conic constant dDin = inner aperture dDout = outer aperture dRin = inner radius dRout = outer radius 我将它们重命名为基本上我在那里所拥有的。它延长了一些行，但是我觉得这是一个公平的权衡。但是，在许多代码中都使用了这种命名方案。我不确定这是来自开发人员的作品，他们是通过使用较旧的系统而学习的，还是背后有更深层的原因。是否有充分的理由以这种方式命名变量，还是我在遇到变量时将其更新为更具描述性的名称是否合理？

140 coding-style  language-agnostic  naming 

这有点花哨，但我已经看到有人使用Id了： private int userId; public int getUserId(); 其他使用： private int userID; public int getUserID(); 其中一个比另一个更好吗？为什么？我在大型项目中看到这种做法非常不一致。如果我要设定一个大多数人会熟悉的标准？哪个是常规标准？

126 coding-style  naming  variables 

不同的版本命名约定是否适合不同的项目？您使用什么，为什么？ 就我个人而言，我更喜欢以十六进制表示的内部版本号（例如11BCF），该数目应该定期增加。然后为客户提供一个简单的3位数版本号，即1.1.3。 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, file format changes, etc.

107 project-management  development-process  naming  versioning 

“ 重塑方向盘 ”反模式非常常见-无需使用现成的解决方案，而是从头开始编写自己的解决方案。代码库不必要地增长，执行相同功能但接口略有不同的接口略有不同，浪费了时间来编写（和调试！）易于使用的功能。我们都知道这一点。 但是在频谱的另一端。如果不编写包含两行代码的函数，而是导入框架/ API /库，实例化，配置，将上下文转换为框架可接受的数据类型，然后调用一个可以完全满足您需要的函数，千兆字节抽象层下的两行业务逻辑。然后，您需要使该库保持最新状态，管理构建依赖关系，使许可证保持同步，并且其实例化代码比“重新发明轮子”要长十倍且更复杂。 原因可能多种多样：无论成本高低，管理层都严格反对“重新发明轮子”，尽管与要求之间存在边际重叠，有人推销他们所钟爱的技术，该系统以前主要模块的作用减弱，或者期望扩展和扩大使用这个框架，它永远不会到来，或者只是误解了“重量”，而一些导入/包含/加载指令却是“幕后”。 这种反模式有通用名称吗？ （无论是对还是错，或者它是一个真正的反模式或基于观点的任何内容，我都不会尝试进行讨论，这是一个简单明了的客观术语。） 编辑：建议的“重复项”讨论过度设计自己的代码以使其“为一切准备就绪”，完全与外部系统分开。在某些情况下，它可能源于此，但是通常它源于“厌恶重塑轮子”-不惜一切代价进行代码重用；如果存在解决问题的“现成”解决方案，则无论解决方案的适用性和成本如何，我们都将使用它。原则上赞成创建新的依赖项而不是代码复制，而与创建和维护新代码的成本相比，完全不考虑这些依赖项的集成和维护成本。

101 naming  anti-patterns 

我苦苦挣扎的事情之一就是不使用匈牙利符号。我不想仅去查看变量类型是什么，就不必去定义变量。当一个项目扩展时，能够查看以'bool'为前缀的变量并知道它正在寻找true / false而不是0/1值，这是一个很好的选择。 我还在SQL Server中做了很多工作。我在存储过程中添加了“ sp”前缀，在表中添加了“ tbl”前缀，更不用说数据库中的所有变量了。 我到处都看到没有人真正想要使用匈牙利符号，以至于避免使用匈牙利符号。我的问题是，不使用匈牙利符号的好处是什么？为什么大多数开发人员都像瘟疫一样避免使用匈牙利符号？

101 coding-style  coding-standards  naming 

这些话invert或control根本不使用在我见过的定义来定义控制反转。 定义 维基百科 控制反转（IoC）是一种编程技术，在此以面向对象编程的形式表示，其中对象耦合在运行时由汇编程序对象绑定，通常在编译时使用静态分析是未知的。〜http://en.wikipedia.org/wiki/Inversion_of_control 马丁·福勒 控制反转是Java社区中的一种常见模式，可帮助连接轻量级容器或将来自不同项目的组件组装到一个内聚的应用程序中。〜基于 http://www.martinfowler.com/articles/injection.html （改写） 那么，为什么将控制反转称为控制反转？什么控制被颠倒了？有没有一种方法可以使用术语“ 反转和控制”来定义“控制反转”？

98 naming  definition  ioc-containers  inversion-of-control 

（假设是单线程环境） 满足此条件的功能是： bool MyClass::is_initialized = false; void MyClass::lazy_initialize() { if (!is_initialized) { initialize(); //Should not be called multiple times is_initialized = true; } } 本质上，我可以多次调用此函数，而不必担心MyClass多次初始化 不满足此条件的功能可能是： Foo* MyClass::ptr = NULL; void initialize() { ptr = new Foo(); } initialize()多次调用将导致内存泄漏 动机 最好有一个简洁的词来描述此行为，以便可以适当地注释预期符合此条件的功能（在描述预期被覆盖的接口功能时特别有用）

96 naming  functions 

我最近尝试对Python 3实现排名算法AllegSkill。 这是数学的样子： 不完全是。 这就是我写的： t = (µw-µl)/c # those are used in e = ε/c # multiple places. σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5 我实际上以为Python 3不幸的是不接受√或²作为变量名。 >>> √ = lambda x: x**.5 File "<stdin>", line 1 √ = lambda x: x**.5 ^ SyntaxError: invalid character …

82 naming  unicode 

“ to”和“ as”方法名称前缀（例如）之间有什么区别 toList（）， asList（）， 等等... 设计方法何时使用？

78 java  naming 

我一直在阅读Robert Martin的“ Clean Code ”，希望成为一个更好的程序员。尽管到目前为止还没有一个真正的突破性进展，但是它使我对我设计应用程序和编写代码的方式有了不同的看法。 我不仅同意书中的一部分，而且对我没有任何意义，特别是关于接口命名约定。这是直接从书中摘录的文字。我将这方面加粗了，我感到困惑，并希望澄清。 我更喜欢不修饰界面。前面的I在当今的一堆旧书中很常见，充其量可以使人分心，而在最坏的情况下则可以提供过多的信息。我不想让用户知道我正在给他们一个接口。 也许是因为我只是一个学生，或者可能是因为我从未做过任何基于专业或团队的编程，但是我希望用户知道它是一个界面。 实现接口和扩展类之间有很大的区别。 因此，我的问题归结为：“为什么我们应该隐藏一部分代码期望接口的事实？” 编辑 回答： 如果您的类型是接口或类是您的业务，而不是使用您的代码的人的业务。因此，您不应在此第三方代码中泄漏代码的详细信息。 我为什么不“泄漏”给定类型是第三方代码的接口还是类的详细信息？对于使用我的代码的第三方开发人员来说，知道他们将要实现接口还是扩展类不是很重要吗？差异是否不如我要记住的那么重要？

73 naming  interfaces  coding-standards 

我已经使用了underscore_case大约2年了，由于新工作，我最近改用了camelCase（后来使用了大约2个月，后来我仍然认为underscore_case更适合涉及大量程序员的大型项目，主要是因为代码更易于阅读）。 现在，每个人都使用camelCase，因为（他们说）代码看起来更优雅。 您对camelCase或underscore_case的看法 ps请原谅我的英语不好 编辑 首先更新： 使用的平台是PHP（但是我不希望得到与PHP平台相关的严格答案，任何人都可以分享他们的想法，最好使用它，这就是为什么我首先来到这里） 我和团队中的其他人一样使用camelCase（就像你们大多数人一样推荐） 我们使用Zend Framework，它也推荐camelCase 一些示例（与PHP相关）： Codeigniter框架建议使用underscore_case，说实话，代码更易于阅读。 ZF推荐了camelCase，但我并不是唯一一个认为ZF代码更难理解的人。 所以我的问题改写为： 让我们以您拥有一个不推荐任何命名约定的Foo平台为例，这是团队领导者选择一个的惯例。您是那个团队的负责人，为什么要选择camelCase或为什么选择underscore_case？ ps谢谢大家到目前为止的迅速回答

70 naming 

Bob叔叔在“ 干净代码”中有关名称的章节中建议您避免使用名称编码，主要是关于匈牙利表示法。他还特别提到I从接口中删除前缀，但没有显示此示例。 让我们假设以下内容： 接口的使用主要是通过依赖注入实现可测试性 在许多情况下，这导致与单个实施者具有单个接口 因此，例如，这两个应命名为什么？Parser和ConcreteParser？Parser和ParserImplementation？ public interface IParser { string Parse(string content); string Parse(FileInfo path); } public class Parser : IParser { // Implementations } 还是在这样的单一实现案例中忽略该建议？

68 c#  naming  clean-code  naming-standards 

有时候，某些事物（例如变量）的最合逻辑的名称是所选语言或环境中的保留关键字。当没有同等合适的同义词时，该如何命名？ 我想象有针对此问题的最佳实践启发式方法。这些可以由编程语言和环境的创建者或管理者提供。例如，如果python.org（或Guido van Rossum）说了如何用Python处理它，那将是我书中的一个很好的指导原则。有关如何使用C＃处理它的MSDN链接也将很好。 另外，软件工程中主要影响者提供的指南也应该是有价值的。也许Google / Alphabet有一个不错的风格指南，可以教我们如何处理它？ 这只是一个示例：在C＃语言中，“默认”是保留关键字。当我使用枚举时，我可能希望将默认值命名为“ default”（类似于“ switch”语句），但不能这样。 （C＃区分大小写，枚举常量应大写，因此“ Default”是显而易见的选择，但让我们假设当前的样式指南规定所有枚举常量都应为小写。） 我们可以考虑使用“ defaultus”一词。 ”，但这不符合“最小惊讶原则”。我们还应该考虑“标准”和“初始”，但是不幸的是，“默认”是在这种情况下准确传达其目的的词。

64 naming