Questions tagged «code-smell»

我是一名电气工程师，我不知道自己在做什么。请保存我的代码的未来维护者。 最近，我一直在研究一些较小的程序（在C＃中），其功能在逻辑上是“过程的”。例如，其中之一是一个程序，该程序从不同的数据库收集信息，使用该信息生成某种摘要页面，将其打印出来，然后退出。 所有这些所需的逻辑约为2000行。我当然不想像以前的开发人员所做的那样将所有内容全部填充到一起main()，然后用来“清理” #region（颤抖）。 这是我已经尝试过但不太满意的一些事情： 为每个粗略的功能（例如DatabaseInfoGetter，SummaryPageGenerator和PrintUtility）创建静态实用程序。使主要功能看起来像： int main() { var thisThing = DatabaseInfoGetter.GetThis(); var thatThing = DatabaseInfoGetter.GetThat(); var summary = SummaryPageGenerator.GeneratePage(thisThing, thatThing); PrintUtility.Print(summary); } 对于一个程序，我什至使用了接口 int main() { /* pardon the psuedocode */ List<Function> toDoList = new List<Function>(); toDoList.Add(new DatabaseInfoGetter(serverUrl)); toDoList.Add(new SummaryPageGenerator()); toDoList.Add(new PrintUtility()); foreach (Function f in toDoList) f.Do(); …

12 c#  object-oriented  code-quality  code-smell  procedural 

我们有一个用ASP.NET 2.0编写的糟糕的系统，我们需要向其中添加一些功能。问题在于，某个产品具有UI功能，对于在特定日期（其他时间已关闭）之后启动的业务，必须打开该UI功能，而页面必须与现有业务的外观相同。 我本能地发现基于日期的JavaScript UI开关的想法，而将新老业务的Web控件混合在一起是“不统一的”（因为想要一个更好的词），所以我努力为新业务重写页面）。 使用基于时间的UI的做法是否已被广泛接受，如果没有，采取该措施的已知风险是什么？

11 anti-patterns  code-smell  ui 

我今天早上在看一些博客文章，偶然发现了这一篇： 如果唯一实现Customer接口的类是CustomerImpl，那么您实际上就没有多态性和可替代性，因为实际上在运行时没有什么可以替代。这是假的普遍性。 这对我来说很有意义，因为实现接口会增加复杂性，而且，如果只有一种实现，则可能会争辩说它会增加不必要的复杂性。编写比需要的抽象要抽象得多的代码通常被认为是被称为“投机性一般性”的代码气味（在文章中也提到了）。 但是，如果我遵循TDD，那么如果没有这种推测性的普遍性（无论是接口实现形式还是我们的其他多态选项），就无法（轻松）创建测试双打，从而使类可继承且其方法是虚拟的。 那么，我们如何协调这种权衡呢？以投机性方式推广测试/ TDD是否值得？如果您使用的是测试双打，是否将这些视为第二种实现方式，从而使普遍性不再具有推测性？您是否应该考虑一个更重的模拟框架，该框架可以模拟具体的协作者（例如，C＃世界中的Moles与Moq）？或者，您应该使用具体的类进行测试，并编写什么可以被视为“集成”测试，直到您的设计自然需要多态性之前？ 我很想阅读其他人对此事的看法-预先感谢您的意见。

11 design  unit-testing  code-smell  polymorphism 

我已经进行了一年的TDD测试，对此我感觉很好，我喜欢我的测试套件以及所有其他工具。但是，我注意到最近我一直在做很多模拟通话验证。例如，我有一个将注入存储库的服务-在我的单元测试中，我将传递一个存储库的模拟并验证它在我正在测试的方法中被调用。然后，我将检查返回的结果是否正确（在另一个测试中）。这绝对是“感觉”错误，因为我的单元测试现在与实现细节非常相关。我听说您应该测试“行为”，但是在许多情况下……嗯-不可能吗？如果你有一个void例如，您通常会测试副作用。我的意思是继续进行并展示一些简单的代码集很容易就能证明这一点，但是恕我直言，它不能很好地反映我们编写的真实程序。我做错了吗？这种测试是一种反模式吗？感谢您对此的意见，在TDD方面，我还是一个新手。

11 unit-testing  tdd  code-smell  anti-patterns 

我有以下代码： public void moveCameraTo(Location location){ moveCameraTo(location.getLatitude(), location.getLongitude()); } public void moveCameraTo(double latitude, double longitude){ LatLng latLng = new LatLng(latitude, longitude); moveCameraTo(latLng); } public void moveCameraTo(LatLng latLng){ GoogleMap googleMap = getGoogleMap(); cameraUpdate = CameraUpdateFactory.newLatLngZoom(latLng, INITIAL_MAP_ZOOM_LEVEL); googleMap.moveCamera(cameraUpdate); } 我认为通过这种方式，例如，我消除了了解LatLng另一门课中的内容的责任。 而且，您无需在调用函数之前准备数据。 你怎么看？ 这种方法有名称吗？真的是不好的做法吗？

10 design  design-patterns  clean-code  code-smell  bad-code 

我继承了一些糟糕的代码，其中包括以下简短示例。 这个特殊的反模式有名称吗？ 有哪些重构建议？ // 0=Need to log in / present username and password // 2=Already logged in // 3=Inactive User found // 4=Valid User found-establish their session // 5=Valid User found with password change needed-establish their session // 6=Invalid User based on app login // 7=Invalid User based on network …

10 coding-style  code-quality  coding-standards  code-reviews  code-smell 

因此，我最近对代码进行了一些重大的重构。我试图做的主要事情之一就是将类分为数据对象和辅助对象。除其他外，这是由“ 清洁代码”的这一部分启发的： 杂种 这种混乱有时会导致不幸的混合数据结构，即一半对象和一半数据结构。它们具有执行重要功能的函数，也具有公共变量或公共访问器和更改器，它们出于所有意图和目的，将私有变量公开，从而诱使其他外部函数以程序程序将要使用的方式使用这些变量。数据结构。 这样的混合体很难添加新功能，但是也很难添加新的数据结构。他们是两全其美的。避免创建它们。它们表示设计混乱，其作者不确定（或者更糟，是无知）他们是否需要保护功能或类型。 最近，我正在查看我的一个工作对象（恰好实现了Visitor模式）的代码，并看到了： @Override public void visit(MarketTrade trade) { this.data.handleTrade(trade); updateRun(trade); } private void updateRun(MarketTrade newTrade) { if(this.data.getLastAggressor() != newTrade.getAggressor()) { this.data.setRunLength(0); this.data.setLastAggressor(newTrade.getAggressor()); } this.data.setRunLength(this.data.getRunLength() + newTrade.getLots()); } 我立即对自己说：“功能令人羡慕！这种逻辑应该在Data类中-特别是在handleTrade方法中。handleTrade并且updateRun应该始终一起发生”。但是后来我想到“数据类仅仅是一个public数据结构，如果我开始这样做，那么它将成为一个混合对象！” 有什么更好的，为什么？您如何决定该做什么？

10 java  object-oriented-design  data-structures  clean-code  code-smell 

代码库中的哪些症状指示需要使用事件侦听器方法？ 在我看来，当某些类需要被多个调用，而不是在其他类的设计时集合中定义时，您需要某种信令框架，但是我想听听还有哪些其他情况通过更改为基于事件的模型进行了改进。

10 architecture  design-patterns  code-smell 

我在两个单独的控制器中有一组单一用途的功能。现在，我只有重复的代码，并且想摆脱它。该代码是控制器的一部分，不属于我的服务层。你会放在哪里？

10 mvc  code-smell 

我正在阅读Roy Osherove撰写的《单元测试的艺术》。我在第7.2节“编写可维护的测试”中，作者对代码气味有此说明： 注意：当您重构内部状态以使其对外部测试可见时，是否可以将其视为代码异味（表示代码设计或逻辑中可能存在问题的迹象）？当您重构以暴露协作者时，这不是代码的味道。如果您要重构并且没有协作者，这是一种代码味道（因此您不需要存根或模拟任何东西）。 编辑：作者所说的“合作者”是依赖。他关于依赖项的一些示例是访问数据库或访问OS的文件系统的类。他在这里定义存根并开始使用“协作者”一词： 甲存根是用于现有的可控替换依赖性（或 合作者在系统中）。 作者没有此代码气味的示例，并且我在理解/描绘其外观时遇到困难。有人可以再解释一下，也许可以提供一个具体的例子？

9 unit-testing  code-quality  code-smell 

在我们的Delphi 2007应用程序中，我们使用了许多以下构造 FdmBasic:=TdmBasicData(FindOwnerClass(AOwner,TdmBasicData)); FindOwnerClass向上移动当前组件的Owner层次结构以查找特定的类（在示例TdmBasicData中）。结果对象存储在Field变量FdmBasic中。我们主要使用它来传递数据模块。 示例：生成报告时，结果数据将被压缩并存储在通过数据模块TdmReportBaseData访问的表的Blob字段中。在我们应用程序的单独模块中，具有使用ReportBuilder以Paged形式显示来自报表数据的功能。该模块的主要代码（TdmRBReport）使用TRBTempdatabase类将压缩的Blob数据转换为Reportbuilder运行时reportdesigner中可用的不同表。TdmRBReport可以访问TdmReportBaseData，以获取所有与报告相关的各种数据（报告类型，报告计算设置等）。TRBTempDatabase是在TdmRBReport中构造的，但必须有权访问TdmReportBasedata。因此，现在可以使用上面的构造完成此操作： constructor TRBTempDatabase.Create(aOwner: TComponent); begin inherited Create(aOwner); FdmReportBaseData := TdmRBReport(FindOwnerClass(Owner, TdmRBReport)).dmReportBaseData; end;{- .Create } 我的感觉是，这意味着TRBTempDatabase非常了解其所有者，并且我想知道这是某种代码味道还是反模式。 您对此有何想法？这是代码气味吗？如果是这样，还有什么更好的方法？

9 code-smell 

今天，在工作中，我的一位同事审查了我的代码，并建议我删除仅设置属性，而改用一种方法。 当我们俩都忙于其他事情时，他告诉我看Property Design《框架设计指南》一书中的部分。在书中，作者只是说要避免： setter的属性比getter具有更广泛的可访问性 现在，我想知道为什么不建议使用仅设置属性？有人可以帮我澄清一下吗？

9 design  code-quality  code-reviews  code-smell 

c＃中的null-coalescing运算符使您可以缩短代码 if (_mywidget == null) return new Widget(); else return _mywidget; 向下： return _mywidget ?? new Widget(); 我一直发现，我想在C＃中拥有一个有用的运算符，它将允许您返回对象的属性，或者如果对象为null则返回其他值。所以我想替换 if (_mywidget == null) return 5; else return _mywidget.Length; 带有： return _mywidget.Length ??! 5; 我不禁想到该操作符不存在一定的原因。它有代码味吗？有没有更好的方法可以写这个？（我知道空对象模式，但是用它来替换这四行代码似乎有点过分。）

9 c#  code-smell  null