Questions tagged «code-quality»

当您需要遍历读取器的地方时，要读取的项目数是未知的，唯一的方法是保持读取直到结束。 这通常是您需要无限循环的地方。 还有就是始终true表示必须有一个break或return声明的某处块内。 int offset = 0; while(true) { Record r = Read(offset); if(r == null) { break; } // do work offset++; } 有双读for循环方法。 Record r = Read(0); for(int offset = 0; r != null; offset++) { r = Read(offset); if(r != null) { // do work } } …

13 c#  code-quality  readability 

我们正在对已有20年历史的旧代码库进行一些重构，并且我正在与我的同事讨论代码中的注释格式（plsql，java）。 没有默认的注释格式，但是在大多数情况下，人们会在注释中执行以下操作： // date (year, year-month, yyyy-mm-dd, dd/mm/yyyy), (author id, author name, author nickname) and comment 我想要的将来和过去评论的建议格式是： // {yyyy-mm-dd}, unique_author_company_id, comment 我的同事说，我们只需要评论，并且必须将所有过去和将来的评论重新格式化为这种格式： // comment 我的论点： 我说出于维护原因，知道何时以及谁进行了更改非常重要（即使此信息在SCM中也是如此）。 该代码是有效的，因此有历史。 因为没有更改日期，如果不打开SCM工具并搜索较长的对象历史记录，就无法知道何时进行更改。 因为作者非常重要，所以改变作者比改变作者更可信 敏捷性原因，无需打开和浏览SCM工具 人们会更害怕更改某人15年前所做的事情，而不是最近创建或更改的事情。 等等 我同事的论点： 历史在SCM中 开发人员不得直接在代码中了解代码的历史记录 软件包的长度为15,000行，而且非结构化的注释使这些软件包更难以理解 您认为最好的方法是什么？还是您有更好的方法来解决此问题？

13 java  c#  programming-practices  code-quality  comments 

在上一个有关与可读性相关的简单性的问题中，有很多答案可以帮助我看到我对代码简单性的定义和理解是不正确的。 如何定义代码的简单性？哪些软件度量和指标可用于度量代码的简单性？

13 code-quality 

我是一个新手程序员，通常当我在自己的项目上工作时，我总是感到我的代码设计不是最好的，我讨厌这种感觉。我最终花时间查找事物，但是随后我却很容易被很多细节所淹没，例如可供选择的设计模式以及何时使用抽象类或接口。我是否应该尝试一次学习所有内容？

13 code-quality 

在为UNIX的CLI编写工具时，应如何使程序打印出帮助和/或用法？ 我通常使用fprintf(stderr, "help text here");，但是有几个问题。 首先，我不确定是否应该使用stderr。可以，还是应该使用stdout？ 可以想象，帮助文本很长，具体取决于该工具有多少选项。现在，我通常只需"strings like that\n"在第二个参数中输入几个即可。但是，这用五十行或更多行帮助文本填充了我的源代码。根本不容易管理。我该怎么办呢？ 当工具不是用C或类似C的语言编写时，我倾向于在可能的情况下使用here-docs（在Perl中最为明显）。我不能在C语言中使用它，但是我可以使用类似的东西吗？ 我正在考虑将其放在a的headerfile.h内部#define HELP "help text here"，我从未在野外看到它，也不知道我是否应该真正使用它。 理想情况下，我可以将文本放在外部文件中并包含它。但是，使用#include它似乎是错误的。那我该怎么办？ 这个想法是要有一个易于管理的帮助文本。将其包含在源代码中并不是很方便。

13 programming-practices  code-quality 

首先让我创造一个名词： 代码目标：早上检查代码，然后静静地检查其他开发人员前一天在文件中所做的所有更改（尤其是您最初开发的代码文件），并修复格式，逻辑，重命名变量，重构长方法等），然后将更改提交给VCS。 我已经确定了这种做法的优点和缺点： Pro：经常保持代码质量/可读性/一致性 Pro：由于其他开发人员对原始代码不太熟悉，因此已修复了一些错误。 缺点：经常是那些追求目标的开发人员的时间浪费。 缺点：偶尔会引入一些错误，这些错误会引起开发人员的愤怒，他们以为他们前一天编写了没有错误的代码。 骗局：其他开发人员对过多挑剔的行为感到恼火，并开始不喜欢为目标投标人的代码做出贡献。 免责声明：公平地说，我实际上不是开发经理，而是实际上正在执行“目标管理”的开发人员。 在我的辩护中，我认为这样做是有充分理由的（为了使我们的超大型代码库保持良好运转），但我非常担心它还会带来负面气氛。我也绝对担心我的经理将需要解决这个问题。 那么，如果您是经理，您将如何解决这个问题？ 更新：我并不是说这个问题太过本地化，但是有人问过，所以也许会有一些启发性的背景。三年前，我被分配了一个巨大的项目（200K LoC），直到最近（一年之前），该项目中才添加了其他开发人员，其中一些人不熟悉体系结构，其他人仍在学习该语言（C＃）。我通常必须回答产品的整体稳定性问题，当对代码库的核心体系结构部分进行令人惊讶的更改时，我尤其紧张。养成这种习惯的原因是，起初我对其他开发人员的贡献感到乐观，但是他们犯了太多错误，这些错误导致了严重的问题，直到几周后才发现。通常这些“

12 version-control  code-quality  management  teamwork  team 

创建库时，当不是由同一类的其他方法调用，而是由其他库通过反射调用时，我是否必须确保私有方法必须按预期工作？ 例如，如果私有方法private DoSomething(int number)期望： number 是一个非零的正整数，并且： 私有变量string abc不是null也不是空字符串， 和完全的，丑陋的失败，如果这两个条件不匹配，我必须处理这些故障，即使我知道，在类的所有方法将 always¹分配非空值abc调用之前DoSomething，并通过这种积极的非零整数方法？ 换句话说，不是通过反射进行不安全调用保护的代码可以被认为是低质量代码，还是属于使用反射来确保调用不会中断任何内容的调用方？ 注意：我的问题仅涵盖一组标准库。这不包括必须高度安全的代码（即，当有人可能通过使用反射来使其表现出意外行为或崩溃时感兴趣）。 ¹因为正确记录了该类，所以因为有足够的单元测试来确保任何其他开发人员都不会破坏此方法，等等。

12 code-quality  defensive-programming  reflection 

争论代码生成，我正在寻找一些提高代码质量的方法示例。为了阐明代码生成的含义，我只能谈论我的一个项目： 我们使用XML文件描述数据库架构中的实体关系，因此它们可帮助我们生成ORM框架和HTML表单，可用于添加，删除和修改实体。 在我看来，由于减少了人为错误，它提高了代码质量。如果某些东西实现不正确，则会在模型中将其破坏，这是很好的，因为由于更多生成的代码也被破坏了，因此错误可能会更快出现。 由于要求我提供代码质量的定义，因此让我澄清一下，我的意思是软件质量。 软件质量：这不是一个属性，而是相互影响的许多属性，例如效率，可修改性，可读性，正确性，健壮性，可理解性，可用性，可移植性等。

12 development-process  code-quality  quality 

我认为自己是编程语言爱好者。当我发现错误的代码（尤其是我自己的代码）时，很难理解，更改和测试。 我的同事们并不了解，或者不在乎。我为自己无法提高代码质量而感到沮丧。 当代码质量和可维护性不符合我的标准时，感到沮丧是正常的吗？如果是这样，您如何处理？

12 code-quality  maintainability 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我相信是。为什么？ 我遇到了许多软件工程师，他们认为它们在某种程度上优于QA工程师。我认为，如果他们在一段时间内担任质量检查工程师的工作，并且意识到这是一种独特而有价值的技能，可能会有助于打破这种信念。 软件工程师测试自己的程序的能力越强，在整个软件开发生命周期中进行代码时所花费的时间成本就越少。 软件工程师花更多的时间思考程序如何崩溃，他们在开发它们时会更多地考虑这些情况，从而减少最终产品中的错误。 软件工程师对“完整”的定义总是很有趣的……如果他们花时间担任质量检查工程师，那么这个定义可能会与软件设计者更加接近。 请注意，我在上面的建议中只考虑了很小的时间范围，因为我知道有人在某个职位上工作而不是被雇用，这绝对是失去该开发人员的秘诀。 你们怎么想

12 code-quality  skills  qa 

我目前的工作主要是为我们正在处理的各种应用程序编写GUI测试代码。但是，我发现我倾向于在测试中复制和粘贴很多代码。原因是我正在测试的区域趋于足够相似以至于需要重复，但还不够相似以至于无法将代码封装到方法或对象中。我发现，当我尝试更广泛地使用类或方法时，测试变得更加笨重，有时甚至一开始就很难编写。 取而代之的是，我通常从一个部分复制大量测试代码并将其粘贴到另一部分，然后进行我需要的任何细微更改。我不使用更结构化的编码方式，例如使用更多的OO原理或函数。 其他编码人员在编写测试代码时有这种感觉吗？显然，我想遵循DRY和YAGNI原则，但是我发现测试代码（无论如何都用于GUI测试的自动测试代码）会使这些原则难以遵循。还是我只需要更多的编码实践和更好的整体服务系统？ 编辑：我正在使用的工具是SilkTest，这是一种称为4Test的专有语言。同样，这些测试主要针对Windows桌面应用程序，但是我也使用此设置对Web应用程序进行了测试。

12 testing  code-quality  maintenance  test-automation 

我在公司代码库（.NET 3.5应用程序）的各处看到以下代码模式： bool Foo(int barID, out Baz bazObject) { try { // do stuff bazObject = someResponseObject; return true; } catch (Exception ex) { // log error return false; } } // calling code BazObject baz = new BazObject(); fooObject.Foo(barID, out baz); if (baz != null) { // do stuff …

12 c#  code-quality  coding-style 

我是一名电气工程师，我不知道自己在做什么。请保存我的代码的未来维护者。 最近，我一直在研究一些较小的程序（在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 

我是一个拥有5个团队的开发团队的成员，该团队共有大约40个开发人员。我们遵循Scrum方法，并进行了3周的冲刺。我们有一个持续集成设置（Jenkins），其构建流程需要几个小时（由于进行了广泛的自动化测试）。基本上，开发过程运行良好。 但是，我们观察到进入新的Sprint几天后，我们的构建通常会变得不稳定，并且会一直不稳定，直到Sprint结束“提交停止”为止。这样做的不利影响是，构建步骤步入了管道，尤其是UI- / Webtest 几天没有执行（因为仅在“绿色”构建时触发）。因此，新引入的错误通常仅在冲刺的后期才检测到。 每个提交都通过一组基本测试进行验证。验证后，更改将在代码检查（德语）后推送至主版本 基本单元测试每30分钟运行一次，持续时间少于10分钟 集成测试每2h运行一次，持续时间1h UI / Webtest在成功的集成测试中运行，持续时间数小时 取决于谁在冲刺期间负责构建稳定性（每个冲刺都要移交责任），可能会有中间的临时“提交停止”以使构建恢复稳定。 因此，我们想要： 我们的开发团队可以在不受阻碍的冲刺期间开发和提交更改 如果构建步骤失败，我们将放弃构建过程，因为后续的构建结果意义不大 我们的构建过程可为开发人员及时提供质量反馈 给定（2），点（1）和（3）似乎相互矛盾。有没有人有一个很好的做法来应对这个问题？ （我们目前正在松开要点（2），即使在失败的构建步骤中也允许继续构建。我还没有任何反馈意见，这如何影响我们的质量） 谢谢西蒙

11 testing  scrum  code-quality  jenkins 

我真的很喜欢这篇文章，它使代码/营地处于比您发现的状态更好的状态 -在现实世界中，保持代码整洁似乎是一种实用的方法。 我也非常喜欢要素分支，它是一种独立开发要素的方法，这样，如果您不喜欢它，就可以轻松地将其合并等。 但是，如果我在功能分支上工作，并且发现一些难看的代码，是否应该解决它？ 感觉有很多缺点需要解决： 当我将分支合并回去时，差异将变得混乱，变量重命名或函数提取会变得混乱 如果放弃了该功能，则必须选择清除提交（根据其附近的代码如何进行混乱的合并而改变可能有效或无效），重新执行或放弃它。 另一方面，如果我在文件中时不执行此操作，那么很明显，我会在合并分支的几天之内忘记执行此操作。 我被警告说这是基于观点的（我认为标题仅包含事实should），但是我觉得有一个答案（肯定有人使用这两种方法，所以他们必须有答案）。此外，有关的问题development methodologies都是话题，我认为它们需要一定的意见。

11 refactoring  code-quality  branching