Questions tagged «clean-code»

我正在用Java编程，并且我总是使转换器像这样： public OtherObject MyObject2OtherObject(MyObject mo){ ... Do the conversion return otherObject; } 在新的工作场所中，模式是： public void MyObject2OtherObject(MyObject mo, OtherObject oo){ ... Do the conversion } 对我来说，这有点臭，因为我习惯于不更改传入的参数。此传入参数更改是反模式吗？它有一些严重的缺点吗？

60 java  clean-code  anti-patterns 

关于SO的这个问题是关于纠正OP认为是功能嫉妒代码的问题。我看到这个漂亮短语被引用的另一个示例是在developer.SE中最近给出的答案中。尽管我确实在该答案的注释中要求提供信息，但我认为这对遵循Q＆A的程序员理解“ 特性嫉妒 ”一词有帮助。如果您认为合适，请随时编辑其他标签。

52 refactoring  code-reviews  clean-code  code-smell 

有时候（很少），创建一个需要大量参数的函数似乎是最好的方法。但是，当我这样做时，我觉得我经常随机选择参数的顺序。我通常按​​照“重要性顺序”进行操作，首先要考虑最重要的参数。 有一个更好的方法吗？是否有一种“最佳做法”的参数排序方式可以提高清晰度？

52 refactoring  clean-code  functions  parameters  order 

我读过罗伯特·C·马丁（Robert C. Martin）的“ 清洁代码”的第一章，在我看来，这很不错，但是我怀疑，在某种程度上，有人提到函数应该具有尽可能少的参数是很有意义的（认知上）甚至可能暗示3个或更多参数对于一个函数来说太过昂贵了（我发现它非常夸张和理想化），所以我开始怀疑... 使用全局变量和在函数上传递许多参数的实践都是不好的编程习惯，但是使用全局变量可以大大减少函数中参数的数量。 所以我想听听您对此的看法，使用全局变量减少函数参数的数量是否值得？在什么情况下会呢？ 我认为这取决于几个因素： 源代码大小。 平均功能参数数。 功能数量。 使用相同变量的频率。 我认为，如果源代码的大小相对较小（例如少于600行代码），则有许多函数，将相同的变量作为参数传递，并且这些函数具有许多参数，那么使用全局变量将是值得的，但是我想知道... 你有我的看法吗？ 您对源代码较大的其他情况有什么看法？ PS。我看到了这篇文章，标题非常相似，但是他没有问我想知道什么。

48 programming-practices  clean-code  variables  globals 

软件开发公司的主要目标之一是提高其总线系数。Google在一次演讲中也倡导了这一点。 这意味着您应该以一种方式对所有内容进行编码和文档编制，以确保明天您要在公共汽车上运行时，项目仍然可以继续进行。换句话说，您应该使自己很容易被具有类似技能的其他程序员替换。 可替换，这是否违背了开发人员的利益？在这本书中，有48条权力定律第11条规定，您应该设法使人们依赖于您，以便获得权力，然后将其转化为金钱奖励。 除了这种情况，您需要自己准备一些文档才能在暂停6个月后继续进行项目，开发人员和软件公司之间显然存在利益冲突。 因此，作为一名程序员，您应该为所有人真正编写出色的文档和易于阅读的代码吗？还是应该以一种可以完成工作的方式编写代码和文档，并且您自己可以理解它，但是另一个人可能很难理解它？

48 documentation  clean-code 

在Clean Code中，作者举了一个例子 assertExpectedEqualsActual(expected, actual) 与 assertEquals(expected, actual) 前者声称更为清晰，因为它消除了记住论据去向以及由此引起的潜在滥用的必要性。但是，我从未在任何代码中看到前者命名方案的示例，并且一直都在看到后者。正如作者所断言的，为什么编码人员不采用前者，如果后者比后者更清晰？

47 clean-code 

我正在尝试遵循Bob叔叔的干净代码建议，尤其是要使方法简短。 我发现自己无法缩短此逻辑： if (checkCondition()) {addAlert(1);} else if (checkCondition2()) {addAlert(2);} else if (checkCondition3()) {addAlert(3);} else if (checkCondition4()) {addAlert(4);} 我无法删除其他元素，因此将整个事物分解为较小的部分，导致“其他条件”中的“其他”有助于性能-评估这些条件的成本很高，如果我可以避免评估以下条件，请导致第一个条件是的，我想避免它们。 即使从语义上来讲，从业务的角度来看，如果满足下一个条件，评估下一个条件也是没有意义的。 编辑：此问题被认为是处理if（if else）else的优雅方式的可能重复。 我相信这是一个不同的问题（通过比较这些问题的答案，您也可以看到它）。 我的问题是检查第一个接受条件是否很快结束。 链接的问题试图使所有条件都可以接受，以便做某事。（从该问题的最佳答案中可以看出：https : //softwareengineering.stackexchange.com/a/122625/96955）

45 clean-code  conditions 

背景 ： 我试图在我的Android应用程序中使用Bob叔叔的干净架构。我研究了许多开源项目，这些项目试图展示正确的方法，并且发现了一个基于RxAndroid 的有趣实现。 我注意到的是： 在每一层（表示，域和数据）中，都有一个用于同一实体的模型类（正在谈论UML）。另外，每当数据越过边界（从层到另一层）时，都有一些映射器类负责对象的转换。 题 ： 当我知道如果需要所有CRUD操作时，它们都将具有相同的属性，是否需要在每个层中都有模型类？还是使用干净的体系结构是规则还是最佳实践？

44 java  architecture  android  clean-code  layers 

因此，我已经编程了几年，最近又开始更多地使用ReSharper。ReSharper经常向我建议的一件事是“反转'if'语句以减少嵌套”。 假设我有以下代码： foreach (someObject in someObjectList) { if(someObject != null) { someOtherObject = someObject.SomeProperty; } } ReSharper建议我这样做： foreach (someObject in someObjectList) { if(someObject == null) continue; someOtherObject = someObject.SomeProperty; } 看来，无论进行多少嵌套，ReSharper都会总是建议我反转IF。这个问题是我至少在某些情况下喜欢嵌套。对我来说，似乎更容易阅读和弄清某些地方的情况。并非总是如此，但有时我感到更舒适的嵌套。 我的问题是：除了个人喜好或可读性之外，还有其他减少嵌套的理由吗？是否存在性能差异或其他我可能不知道的东西？

39 .net  coding-style  code-quality  clean-code  resharper 

（我说的是HTML / CSS代码（不是编程语言），但我认为我们也面临与程序员相同的问题。） 我是团队中的高级前端设计师，而且我经常不得不在紧迫的期限内重新处理初级人员的输出。 我面临两个问题： 他们的编码风格有点混乱。 美学不好。 我发现，它们的编码风格是混合的，没有适当的约定/标准。在清理代码或只是处理他们的代码（甚至复制他们的工作方式）之间，我感到很痛苦。 我确实觉得遵循他们的编码风格感到沮丧，因为我觉得我可能会学到坏习惯。但是，那是完成截止日期的最快方法。 对于那些有更多经验的人，哪个更有效？我应该保存清理以备后用吗？还是在进行更改时进行清理？ （尽管我不想听起来很自大，但这是现实。要花更多的时间来编写更好的代码。我知道，我刚开始写的是凌乱的代码。）

38 coding-style  html  clean-code 

在提供用于获取域实体的业务逻辑方法时，该参数应接受对象还是ID？例如，我们应该这样做： public Foo GetItem(int id) {} 或这个： public Foo GetItem(Foo foo) {} 我相信整个传递对象，但是在这种情况下，我们得到一个对象，而我们只知道ID，该怎么办？调用方应该创建一个空的Foo并设置ID，还是应该将ID传递给方法？由于传入的Foo除了ID以外都是空的，因此我看不到调用方必须创建Foo并设置ID的好处，因为它可以将ID发送给GetItem（）方法。

38 c#  design  object-oriented  clean-code 

有时，我花费大量的时间（小时）来使代码“看起来很漂亮”。我的意思是使事情看起来对称。实际上，我将快速滚动浏览整个班级，以查看是否有任何东西因为看起来不“漂亮”或“干净”而跳出来。 我在浪费时间吗？这种行为有任何价值吗？有时，代码的功能或设计甚至都不会改变，我只是重新组织它，使其看起来更好。 我是完全被强迫症吗，还是隐藏着一些好处？

34 clean-code 

语境 在第35页的“ 清理代码”中，它说 这意味着if语句，else语句，while语句等中的块应为一行。该行可能是函数调用。这不仅使封闭函数较小，而且还增加了文档价值，因为在块中调用的函数可以具有很好的描述性名称。 我完全同意，这很有意义。 稍后，在第40页上，它介绍了有关函数参数的信息 函数的理想参数个数为零（尼拉度）。接下来是一个（单声道），紧接着是两个（双声道）。在可能的情况下，应避免使用三个参数（三重性）。超过三个（多义词）需要非常特殊的理由-因此无论如何都不应使用。争论很难。他们具有很大的概念力。 我完全同意，这很有意义。 问题 但是，通常我会发现自己从另一个列表创建了一个列表，而我将不得不忍受两个弊端之一。 我在代码块中使用了两行，一行用于创建事物，一行用于将其添加到结果中： public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms) { List<Flurp> flurps = new List<Flurp>(); foreach (BadaBoom badaBoom in badaBooms) { Flurp flurp = CreateFlurp(badaBoom); flurps.Add(flurp); } return flurps; } 或者，我在要向其中添加事物的列表的函数中添加了一个参数，从而使其“变差了一个参数”。 public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms) { List<Flurp> flurps = new List<Flurp>(); foreach (BadaBoom badaBoom …

33 clean-code  solid 

我在相当大的代码库上工作。数百个类，大量不同文件，许多功能，花费15分钟以上的时间才能提取新副本等。 如此庞大的代码库的一个大问题是，它具有相当多的实用程序方法，它们执行相同的操作，或者具有可能时不使用这些实用程序方法的代码。而且，实用程序方法不只是全部在一个类中（因为这将是一个巨大的混乱）。 我对代码库比较陌生，但是多年来致力于该代码工作的团队负责人似乎也遇到了同样的问题。这会导致很多代码和工作重复，因此，当发生问题时，通常会分成4个基本相同的代码副本 我们如何遏制这种模式？与大多数大型项目一样，并非所有代码都已记录在案（尽管有些文件已记录在案），并且并非所有代码都...很整洁。但是从根本上说，如果我们能够在这方面提高质量，那真是​​太好了，这样将来我们就可以减少代码重复，并且更容易发现实用程序之类的东西。 而且，实用程序函数通常在某个静态帮助器类中，在单个对象上工作的某些非静态帮助器类中，或者是主要“帮助”于其上的类的静态方法。 我进行了一个实验，将实用程序功能添加为扩展方法（我不需要该类的任何内部组件，并且肯定只在非常特定的情况下才需要）。这样可以防止主类杂乱无章，但除非您已经知道，否则实际上再也找不到了。

33 design-patterns  refactoring  clean-code 

我有一段代码在其中迭代地图，直到某个条件为真，然后再使用该条件做更多的事情。 例： Map<BigInteger, List<String>> map = handler.getMap(); if(map != null && !map.isEmpty()) { for (Map.Entry<BigInteger, List<String>> entry : map.entrySet()) { fillUpList(); if(list.size() > limit) { limitFlag = true; break; } } } else { logger.info("\n>>>>> \n\t 6.1 NO entries to iterate over (for given FC and target) \n"); } if(!limitFlag) …

30 design-patterns  object-oriented  object-oriented-design  clean-code