Questions tagged «code-quality»

作为编写迭代器的一部分，我发现自己正在编写以下代码（剥离错误处理） public T next() { try { return next; } finally { next = fetcher.fetchNext(next); } } 发现它比阅读起来稍微容易一些 public T next() { T tmp = next; next = fetcher.fetchNext(next); return tmp; } 我知道这是一个简单的示例，在可读性方面的差异可能不会那么大，但我对这样的一般情况感兴趣：在没有涉及异常的情况下，使用try-finally是否不好？如果在简化代码时实际上是首选。 如果不好，为什么？风格，性能，陷阱...？ 结论 谢谢大家的回答！我猜得出的结论（至少对我而言）是，如果第一个示例是通用模式，则它可能更具可读性，但事实并非如此。因此，使用超出其目的的构造所带来的混乱，以及可能造成混淆的异常流，将胜过任何简化。

30 java  code-quality  exceptions  readability 

当您与倾向于编写风格上很差的代码的人一起工作时，您会怎么办？我正在谈论的代码在技术上通常是正确的，结构合理的，甚至在算法上可能是优雅的，但看起来却很丑陋。我们有： 不同命名约定和标题的混合（underscore_style和camelCase和UpperCamel以及CAPS全部或多或少地随机应用于同一函数中的不同变量） 奇异且不一致的间距，例如 Functioncall (arg1 ,arg2,arg3 ); 注释和变量名中很多拼写错误的单词 我们有一个很好的代码审查系统，可以正常工作，因此我们可以仔细研究并修复最糟糕的问题。但是，发送包含50行“在此处添加空格。正确拼写'itarator'。更改此大写字母等”的代码审核确实很琐碎。 您如何鼓励这个人更加小心并与这些细节保持一致？

30 coding-style  code-quality  teamwork  code-reviews 

假设我有一段代码可以连接到互联网并显示类似的连接结果： HttpRequest* httpRequest=new HttpRequest(); httpRequest->setUrl("(some domain .com)"); httpRequest->setRequestType(HttpRequest::Type::POST); httpRequest->setRequestData("(something like name=?&age=30&...)"); httpRequest->setResponseCallback([=](HttpClient* client, HttpResponse* response){ string responseString=response->getResponseDataString(); if(response->getErrorCode()!=200){ if(response->getErrorCode()==404){ Alert* alert=new Alert(); alert->setFontSize(30); alert->setFontColor(255,255,255); alert->setPosition(Screen.MIDDLE); alert->show("Connection Error","Not Found"); }else if((some other different cases)){ (some other alert) }else Alert* alert=new Alert(); alert->setFontSize(30); alert->setPosition(Screen.MIDDLE); alert->setFontColor(255,255,255); alert->show("Connection Error","unknown error"); } }else{ (other handle …

29 object-oriented  code-quality 

关于技术债务的这篇文章有一些优点，包括： 当故事驱动时，处理“技术问题”最有效。代码库可能在任何地方都需要工作，但是由于面向用户的原因，只有在要处理代码的地方才能收到回报。如果没有故事要经过某个棘手的领域，那么在这方面的工作就会被浪费掉。 因此，我更喜欢像往常一样拍摄故事（但可能更少），并遵循“童子军规则”，使故事比您发现的更好。换句话说，无论故事指引到哪里，让我们编写更多测试，让我们更积极地重构。 这种方法至少具有以下优点： 保持“最明智”的故事流； 提供所有团队人才的帮助； 让整个团队学习如何保持代码干净； 将改进的重点放在需要的地方； 不会浪费“可能”需要的改进； 我已经看到代码质量对长期生产力有很大的影响，所以我相信应该处理技术债务。我认为上面的帖子很有道理，但是我对最后两点不太确定。我有兴趣了解清除技术债务带来的收益的真实经验，即使这与用户故事无关。 通过清理代码库和消除技术债务，您看到了哪些积极的好处？您使用什么方法来完成工作？

29 code-quality  refactoring  clean-code  technical-debt 

我们这里有一个庞大的遗留代码库，其中包含您无法想象的错误代码。 现在，我们定义了一些质量标准，并希望在全新的代码库中实现这些标准，而且还可以通过触摸旧代码来实现。 而且，我们使用Sonar（代码分析工具）来执行这些操作，而Sonar已经有数千次违规。 现在开始讨论降低对遗留物的侵犯。因为它是遗产。 讨论是关于可读性规则。像它可以有多少个嵌套的ifs / for..。 现在，我该如何反对降低传统代码的编码质量？

28 code-quality  static-analysis  legacy-code 

我已经编程了两年，经常发现自己陷入了困境。 有两种解决方案- 一种是简单的，即简单的方法，易于理解和维护。它涉及一些冗余，一些额外的工作（额外的IO，额外的处理），因此不是最佳的解决方案。 但是其他方法则使用复杂的方法，难以实现，通常涉及许多模块之间的交互，是一种高效的解决方案。 当我没有硬性能SLA甚至简单的解决方案都可以满足性能SLA时，我应该争取哪种解决方案？我对开发人员的简单解决方案不屑一顾。 如果您的性能SLA可以通过一个简单的解决方案来解决，那么提出最佳最佳复杂解决方案是一种好习惯吗？

28 design  programming-practices  coding-style  code-quality  performance 

在繁重的jquery / backbonejs Web应用程序中期望100％的代码覆盖率是否可行？当实际代码覆盖率在javascript / jquery中徘徊在92％-95％左右时，由于未达到100％覆盖率而导致冲刺失败是否合理？

28 code-quality  tdd  bdd 

我不会称自己为超级巨星开发者，而是相对经验丰富的开发者。我试图将代码质量保持在较高水平，并且一​​直在寻求对我的编码样式的改进，试图使代码高效，可读性和一致性，并鼓励团队遵循一种模式和方法来确保一致性。我也了解在质量和速度之间取得平衡的必要性。 为了实现这一目标，我向我的团队介绍了同行评审的概念。在github pull-request中两个竖起大拇指以进行合并。很好-但是我认为没有打cc。 我经常看到来自相同同事的同行评论，例如- 在之后添加一个空格会很好 <INSERT SOMETHING HERE> 方法之间多余的多余线条 在文档块中的注释末尾应使用句号。 现在，从我的角度来看-审阅者只是从表面上看待代码美观性-并没有真正执行代码审阅。化妆品规范审查以傲慢/精明的心态传给我。它缺乏实质性内容，但是您不能对此进行过多辩论，因为审阅者在技术上是正确的。我宁愿看到较少的上述评论，而更多评论如下： 您可以通过以下方式降低圈复杂度： 提早离开，避免如果/其他 将数据库查询抽象到存储库 这种逻辑并不真正属于这里 不要重复自己-抽象和重复使用 如果X将其作为方法的参数传递将会怎样Y？ 单元测试在哪里？ 我发现提供修饰类型评论的总是同一类型的人，而我认为给出“基于质量和逻辑”的同行评论总是相同类型的人。 什么是同行评审的正确方法（如果有）。我是否对同一个人感到沮丧，因为他们基本上都是在浏览代码以寻找拼写错误和美学缺陷而不是实际的代码缺陷？ 如果我是正确的-我将如何鼓励同事在建议进行外观修饰的同时找到代码中的错误呢？ 如果我不正确-请赐教。对于真正构成良好的代码审查，是否有任何经验法则？我是否错过了什么代码审查的要点？ 在我看来，代码审查与代码的共同责任有关。如果不解决/检查逻辑，可读性和功能性，我会不愿意给代码竖起大拇指。如果我发现有人在文档块中省略了句号，那么我也不会为可靠的代码块而阻塞合并。 当我检查代码时，每500 Loc可能花费15-45分钟。我无法想象这些简短的评论要花超过10分钟的时间，如果那是他们正在执行的评论的深度。此外，浅薄评论者的赞许是多少？当然，这意味着所有人的拇指都不一样，并且可能需要进行两遍审核。一个拇指要进行深度评价，第二个拇指要进行“抛光”？

27 code-quality  code-reviews  leadership 

我们团队中的所有程序员都熟悉单元测试和集成测试。我们都与之合作。我们都对其进行了书面测试。我们中有些人甚至对他/她自己的代码感到更加信任。 但是，由于某种原因，编写单元/集成测试尚未成为团队任何成员的反思。当不与实际代码同时编写单元测试时，我们所有人实际上都不会感到难过。结果，我们的代码库大部分没有被单元测试发现，并且项目未经生产就进入生产。 当然，这样做的问题是，一旦您的项目投入生产并且已经正常运行，就几乎不可能获得时间和/或预算来添加单元/集成测试。 我的团队和成员自己已经熟悉了单元测试的值（1，2），但它似乎并没有帮助将单元测试到我们的工作流程自然不会。根据我的经验，强制执行单元测试和/或目标覆盖范围只会导致质量测试不佳，并且会降低团队成员的速度，这仅仅是因为没有自发产生这些测试的动力。同样，一旦压力减轻，就不再编写单元测试。 我的问题是：您是否尝试过任何方法来帮助团队内部建立动力/动力，导致人们自然地希望创建和维护这些测试？

27 project-management  unit-testing  code-quality  integration-testing 

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

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

免责声明：我是新来者（这是我工作的第三天），我的大多数队友比我更有经验。 查看代码时，我会看到一些代码气味和不良的工程实践，例如： 命名准则有些不一致 可能时属性未标记为只读 大型类-我注意到一个实用程序类，其中包含数百个扩展方法（对于许多类型）。它超过2500行！ 大型方法-我正在尝试重构一种150行长的方法。 后两者似乎是一个真正的问题。我想说服队友使用较小的类和方法。但是我应该这样做吗？如果是，那怎么办？ 我的团队从主要团队（我们是卫星团队）中获得了导师。我应该先去找他吗？ 更新：由于一些答复询问该项目，因此请知道这是一个有效的项目。恕我直言，这么大的类/方法总是不好的。 无论如何，我永远不想惹恼我的团队。这就是为什么我问-我应该这样做，如果是的话，那么我该如何轻轻地做到这一点？ 更新：我决定根据公认的答案做某事：因为我是新来者，所以我以“新鲜的眼睛”看到一切，我会记下我发现的所有代码气味（位置，为什么不好，我们怎么做）更好，...），但此刻，我只是努力争取团队的尊重：写出“更好的代码”，认识人们，知道我们为什么这样做...在适当的时候，我会尝试向我的团队询问一些新的代码策略（命名准则，较小的类，较小的方法等），并在可能的情况下重构一些旧代码。它应该工作，恕我直言。 谢谢。

27 .net  code-quality  team  refactoring 

我曾与一位同事讨论过如何中断一条return语句以及该语句在两行中计算返回值。 例如 private string GetFormattedValue() { var formattedString = format != null ? string.Format(format, value) : value.ToString(); return formattedString; } 代替 private string GetFormattedValue() { return format != null ? string.Format(format, value) : value.ToString(); } 在代码方面，我在第一个变量中看不到任何值。对我来说，后者更清晰，尤其是对于较短的方法。他的论点是，前一种变体更易于调试-这是一个很小的优点，因为当由于断点而停止执行时，VisualStudio允许我们对语句进行非常详细的检查。 我的问题是，是否仍然需要编写不太清晰的代码，只是为了使调试一目了然？拆分计算和语句后，该变体还有其他参数return吗？

26 coding-style  code-quality  debugging 

我听说过Visual Studio的代码分析，但从未使用过。我已经阅读了MSDN，但仍然不了解代码分析的实际用途。 它与StyleCop不一样吗？ 在某个地方，还提到了FxCop。代码分析有什么区别？ 我需要为每个项目使用代码分析吗？我的同事进行的代码审查是否不足？

26 c#  .net  code-quality  static-analysis 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 短标识符不好吗？标识符长度与代码理解如何相关？在命名标识符时，还需要考虑哪些其他因素（除了代码理解能力之外）？ 只是为了保持答案的质量，请注意，已经对该主题进行了一些研究！ 编辑 奇怪的是，当我提供的两个链接都表明大标识符有害时，每个人都认为长度不相关或倾向于使用更大的标识符！ 断链 下面的链接指向对该主题的研究，但现在已断开，我似乎没有与该文件的复印件，而且我不记得它是什么。我把它留在这里，以防别人弄清楚。 http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

26 code-quality  coding-style 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 在stackoverflow上似乎出现了很多次，人们（尤其是程序员）倾向于使问题的解决方案变得过于复杂，以至于解决方案比原始问题复杂得多？我无论如何都不是专家，但是很多时候我尝试使用最可行的最简单的解决方案（很显然这并非在任何地方都可行），但是我在建议人们认为工作上的简单解决方案方面取得了很大的成功忽略更复杂的解决方案？ 对于程序员来说，这是正常的事情吗？....或者我只是在考虑正确的角度而已。

26 programming-practices  code-quality