Questions tagged «code-smell»

C＃允许使用#region/ #endregion关键字使代码区域在编辑器中可折叠。每当我这样做时，我都会隐藏可能会重构为其他类或方法的大量代码。例如，我见过一些方法，其中包含500行代码以及3或4个区域，只是为了使其易于管理。 那么明智地使用区域是否会带来麻烦呢？对我来说似乎是这样。

264 c#  code-smell 

我已经知道了一段时间，但从未考虑过的一件事是，在大多数语言中，可以根据其顺序在if语句中为运算符赋予优先级。我经常用这种方法来防止空引用异常，例如： if (smartphone != null && smartphone.GetSignal() > 50) { // Do stuff } 在这种情况下，代码将导致首先检查对象是否不为null，然后在知道该对象存在的情况下使用该对象。该语言很聪明，因为它知道如果第一条语句为假，那么即使评估第二条语句也没有意义，因此永远不会抛出空引用异常。对于and和or运算符，其作用相同。 据我所知，这在其他情况下也很有用，例如检查索引是否在数组的边界内，并且可以用各种语言执行这种技术：Java，C＃，C ++，Python和Matlab。 我的问题是：这种代码是否代表不良做法？这种不良做法是由某种隐藏的技术问题引起的（例如，这最终可能导致错误）还是对其他程序员而言导致可读性问题？会令人困惑吗？

88 programming-practices  language-agnostic  code-smell  operators 

您是否只需要用Expression s 来展示新技巧或将三个不同的过程归纳起来就知道吗？这并不一定要达到宇航员的规模，实际上可能会有所帮助，但是我不禁注意到其他人将以更清晰，直接（有时很无聊）的方式实现相同的类或程序包。 我注意到我经常通过过度解决问题来设计程序，有时是故意的，有时是出于无聊。无论哪种情况，我通常都会诚实地相信我的解决方案是清晰而优雅的，直到我看到相反的证据，但通常为时已晚。我中还有一部分人喜欢无证假设而不是代码重复，而更喜欢简单性。 我该怎么做才能抵制写“聪明的”代码的冲动，什么时候我应该做错了？ 当我现在与一个经验丰富的开发人员团队一起工作时，问题变得更加严峻，有时我写智能代码的尝试即使是我自己，经过一段时间消除优雅的幻想似乎也是愚蠢的。

75 architecture  programming-practices  language-agnostic  code-smell 

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

52 refactoring  code-reviews  clean-code  code-smell 

通常，我只是使用复制和粘贴以及所有其他不良做法将单元测试放在一起。单元测试通常看起来很难看，充满了“代码味道”，但这真的重要吗？只要“真实”代码是“良好”，我总是告诉自己，这很重要。另外，单元测试通常需要诸如存根函数之类的各种“臭味”。 我应该如何应对设计不佳（“臭”）的单元测试？

52 unit-testing  code-quality  code-smell 

标志变量是邪恶的吗？以下类型的变量是否极不道德，是否邪恶地使用它们？ “布尔值或整数变量，您可以在某些位置分配值，然后向下选择以下值，然后进行其他操作，例如，使用newItem = true下面的某些行if (newItem ) then” 我记得做过几个项目，在这些项目中我完全忽略了使用标志，最终得到了更好的体系结构/代码。但是，这在我从事的其他项目中是一种常见的做法，当代码增长并添加标志时，恕我直言，意大利面条也随之增长。 您是否会说在任何情况下都使用标志是一种好习惯甚至是必要的做法？或者您是否同意在代码中使用标志是...红色标志，应避免/重构。我，我只是通过执行实时检查状态的函数/方法来解决问题。

47 code-quality  code-smell  maintainability 

在旧版代码中，我偶尔会看到只不过是数据包装器的类。就像是： class Bottle { int height; int diameter; Cap capType; getters/setters, maybe a constructor } 我对OO的理解是，类是数据的结构以及对该数据进行操作的方法。这似乎排除了此类对象。对我而言，它们无非是structs一种失败的面向对象的目的。我认为这不一定是邪恶的，尽管它可能是一种代码味道。 是否存在这样的对象必要的情况？如果经常使用，是否会使设计令人怀疑？

43 java  code-quality  object-oriented  code-smell 

Web上有大量参考和列出代码气味的资源。但是，我从未见过有关建筑异味的信息。这是在某处定义的，并且有可用的列表吗？是否已对架构缺陷及其对项目速度，缺陷等的影响进行了正式研究？ 编辑：我并不是真正在答案中寻找清单，而是有关建筑气味的文档（在网络上或书籍中）。

37 architecture  code-smell  quality 

我发现有很多2-3k线文件，但实际上并没有觉得它们应该那么大。 客观地将源代码文件称为“太大”的最佳标准是什么？源代码文件应具有最大行数吗？

36 code-quality  code-smell 

我和一群朋友在过去的一段时间里一直在从事一个项目，我们想发明一种很好的面向对象的方法来表示特定于我们产品的方案。基本上，我们正在开发东方风格的 子弹地狱游戏，我们希望建立一个系统，在其中可以轻松表示我们可以梦想的子弹的任何可能行为。 这就是我们所做的；我们制作了一个非常优雅的架构，使我们可以将项目符号的行为划分为不同的组件，这些组件可以随意附加到项目符号实例上，类似于Unity的组件系统。它工作得很好，易于扩展，灵活并且覆盖了我们的所有基础，但是存在一个小问题。 我们的应用程序还涉及大量的程序生成，即我们以程序方式生成项目符号的行为。为什么这是个问题？好吧，我们的OOP解决方案虽然表现优雅，但是代表人的举止却很复杂，如果没有人使用它，工作起来会有些复杂。人类足够聪明，可以想到既合理又明智的问题解决方案。程序生成算法还不那么聪明，我们发现很难实现一个充分利用OOP架构的AI。诚然，该体系结构的一个缺陷是并非在所有情况下都直观。 因此，为了解决此问题，我们基本上将不同组件提供的所有行为都推到了bullet类中，这样我们可以想像到的一切都直接在每个bullet实例中提供，而与其他关联的组件实例不同。这使我们的过程生成算法更容易使用，但是现在我们的bullet类是一个巨大的上帝对象。到目前为止，它很容易成为程序中最大的类，它的代码量是其他任何代码的五倍以上。维护也有点麻烦。 可以让我们的一个类变成一个上帝对象，只是为了使其更容易处理另一个问题吗？通常，如果它允许更轻松地解决其他问题，代码中是否会有代码味道是可以的吗？

31 object-oriented  architecture  code-smell 

在第一次使用python时，我发现我最终在同一文件中编写了多个类，这与Java之类的其他语言（每个类使用一个文件）相反。 通常，这些类由1个抽象基类组成，其中1-2个具体实现的用法略有不同。我在下面发布了一个这样的文件： class Logger(object): def __init__(self, path, fileName): self.logFile = open(path + '/' + filename, 'w+') self.logFile.seek(0, 2) def log(self, stringtoLog): self.logFile.write(stringToLog) def __del__(self): self.logFile.close() class TestLogger(Logger): def __init__(self, serialNumber): Logger.__init__('/tests/ModuleName', serialNumber): def readStatusLine(self): self.logFile.seek(0,0) statusLine = self.logFile.readLine() self.logFile.seek(0,2) return StatusLine def modifyStatusLine(self, newStatusLine): self.logFile.seek(0,0) self.logFile.write(newStatusLine) self.logFile.seek(0,2) class GenericLogger(Logger): def …

31 python  code-quality  code-smell 

建议在.cs文件中创建多个类，还是每个.cs文件都应有一个单独的类？ 例如： public class Items { public class Animal { } public class Person { } public class Object { } } 一分钟就躲避一个事实，那就是这不是一个好的架构示例，.cs文件中是否有多个类才有代码味道？

30 c#  code-smell 

自从我在有争议的编程观点线程中阅读此答案以来，我一直在思考以下问题： 你的工作是使自己失业。 在为雇主编写软件时，所创建的任何软件都应以任何开发人员都可以选择并以最小的努力理解的方式编写。它经过精心设计，清晰一致地编写，清晰地格式化，记录在何处，按预期每日生成，检入存储库并进行适当版本控制。 如果您遇上公共汽车，下岗，解雇或下班，您的雇主应该能够在短时间内通知您，然后下一个人可能会担任您的职务，接管您的代码，并做好准备。一周之内就可以跑步了。如果他或她做不到，那您就惨败了。 有趣的是，我发现有了这个目标使我对雇主更有价值。我越努力成为可抛弃型产品，我对他们就越有价值。 而且在其他问题（例如这个问题）中也进行了讨论，但是我想再次提出来从更空白的角度讨论“ 这是代码的味道！ ”的观点-尚未真正涵盖深入。 我从事专业开发已经十年了。我曾经做过一项工作，代码编写得足够好，可以被任何体面的新开发人员相对迅速地拿到，但是在行业中的大多数情况下，似乎拥有很高的所有权（个人和团队所有权）规范。大多数代码库似乎都缺乏文档，流程和“开放性”，而这将使新开发人员可以选择它们并快速使用它们。似乎总是有很多不成文的小技巧和黑客，只有非常了解代码库的人（“拥有”它）才知道。 当然，明显的问题是：如果该人退出或“被公交车撞上”怎么办？还是在团队层面上：如果整个团队在团队午餐时外出时食物中毒，而他们全都死了怎么办？您是否可以相对轻松地用一组新的随机开发人员代替团队？-在过去的几份工作中，我完全无法想象这种情况的发生。这些系统充满了诡计和技巧，以至于您“ 只需要知道 ”，以至于您雇用的任何新团队所花费的时间远远超过可盈利的业务周期（例如，新的稳定版本）才能使事情恢复正常。简而言之，如果不得不放弃该产品，我不会感到惊讶。 显然，一次输掉整个团队是很少见的。但是我认为所有这一切中还有一个更微妙和危险的事情-这就是让我开始思考这个话题的要点，因为我以前从未看到过这些术语的讨论。基本上：我认为对代码所有权的高度需求通常是技术债务的指标。如果您“必须知道”系统中缺乏流程，沟通，良好的设计，许多小技巧和小技巧，等等-这通常意味着系统正在逐渐陷入越来越深的技术负担。 但是问题是-代码所有权通常被表示为对项目和公司的“忠诚”，是对工作“承担责任”的积极形式-因此，完全谴责它是不受欢迎的。但是，与此同时，等式的技术债务方面通常意味着代码库变得越来越不开放，并且使用起来更加困难。特别是随着人们的前进和新开发人员的到位，技术债务（即维护）成本开始飙升。 所以从某种意义上说，我实际上认为，如果对代码所有权的高度需求被公开认为是一种工作气味（在流行的程序员想象中），这对我们的职业而言将是一件好事。与其将其视为工作中的“承担责任和自豪感”，不如将其视为“通过技术债务巩固自己并创造人为的工作保障”。 我认为测试（思想实验）基本上应该是：如果这个人（或者实际上是整个团队）明天要从地球上消失，该怎么办？这是否会对项目造成巨大的伤害甚至是致命的伤害，还是我们可以招募新人员，让他们阅读doccos和帮助文件并使用代码几天，然后再返回在几周内完成业务（一个月左右即可恢复全部生产力）？

27 development-process  code-quality  source-code  code-smell  code-ownership 

在这里，我们是2010年，具有4年或5年或经验的软件工程师，仍然在设计带有96个压裂柱的工作台。 我告诉他这将是一场噩梦。 我向他展示了我们必须使用普通语言将MySQL与C＃接口。 我解释说，列多于行的表有很大的味道。 不过，我得到“这样会更简单”。 我该怎么办？ 编辑* 该表包含来自传感器的数据。 我们有带 Dynamic_D1X的传感器1 Dynamic_D1Y [...] Dynamic_D6X Dynamic_D6Y [...] 编辑2 * 好吧，我终于离开了那份工作。这是另一个程序员在几个月后昏昏欲睡的一个信号，是管理层没有意识到这是一个问题的另一个信号。

23 sql  code-smell 

声明init()类型的方法是否有目的？ 我不是问我们是否应该优先init()于构造函数，或者如何避免声明init()。 我问的是在声明方法（查看它的普遍性）后是否有任何理论依据，init()或者它是否是一种代码味道，应避免使用。 这个init()习语很普遍，但是我还没有看到任何真正的好处。 我说的是鼓励通过方法初始化的类型： class Demo { public void init() { //... } } 什么时候可以在生产代码中使用它？ 我觉得这可能是代码的味道，因为它表明构造函数未完全初始化对象，从而导致部分创建了对象。如果未设置状态，则该对象不应存在。 从企业应用的意义上讲，这使我相信它可能是某种用于加速生产的技术的一部分。这是我可以想到的惯用法，这是唯一合乎逻辑的原因，但我不确定是否会有这样的习惯。

20 java  object-oriented  object-oriented-design  code-quality  code-smell