Questions tagged «maintainability»

如何知道一个人创建的代码是否易于阅读，理解和维护？当然，从作者的角度来看，该代码具有可读性和可维护性，因为从一开始，作者就对其进行了编写和编辑。但是，必须有一个客观且可量化的标准，我们的行业可以据此衡量代码。 如果在没有原始作者的专业建议的情况下对代码执行以下操作，则可以达到这些目标： 可以阅读代码并从根本上理解逻辑流程。 可以更深入地了解代码在做什么以包括输入，输出和算法。 其他开发人员可以对原始代码进行有意义的更改，例如错误修复或重构。 可以编写新代码，例如利用原始代码的类或模块。 我们如何量化或衡量代码质量，使我们知道代码的可读性，可理解性和可维护性？

336 code-quality  code-reviews  readability  maintainability 

我已经从事软件开发工作多年了。我的经验是，随着越来越多的开发人员参与产品开发，项目变得更加复杂和难以维护。 似乎在开发的某个阶段，软件趋向于变得“骇客”和“骇客”，尤其是当没有一个定义架构的团队成员在公司工作时。 我感到沮丧的是，必须更改某些内容的开发人员很难了解架构的概况。因此，存在解决问题或以与原始体系结构相适应的方式进行更改的趋势。结果是代码变得越来越复杂，甚至变得难以理解。 关于如何保持源代码多年来的可维护性，是否有任何有用的建议？

156 project-management  maintainability 

有时，您会遇到必须扩展/改进某些现有代码的情况。您会看到旧代码非常精简，但是它也很难扩展，而且花时间阅读。 用现代代码代替它是一个好主意吗？ 一段时间以前，我喜欢精益方法，但现在看来，最好牺牲很多优化，而采用更高的抽象，更好的接口和更易读，可扩展的代码。 编译器似乎也越来越好，因此诸如之类struct abc = {}的东西被悄无声息地变成了memsets，shared_ptrs产生的代码几乎与原始指针扭曲相同，模板工作得很好，因为它们产生了超精简代码，依此类推。 但是，有时您仍然会看到基于堆栈的数组和带有一些晦涩逻辑的旧C函数，通常它们不在关键路径上。 如果您必须以某种方式触摸其中的一小部分代码，那么更改这种代码是一个好主意吗？

78 c++  c  refactoring  optimization  maintainability 

我一直在浏览《AvSol编码指南》（C＃），我几乎同意所有内容，但我真的很想知道其他人对一个特定规则的看法。 AV1500 方法不应超过7条语句需要7条以上语句的方法执行的操作过多或职责过多。它还需要人的头脑来分析确切的语句，以了解代码在做什么。用不明原因的名称将其分解为多种小型且重点突出的方法。 你们大多数人都遵循这个规则吗？即使可以大大提高可读性，即使创建新方法（您的代码仍然是DRY）几乎没有什么余地？而且您的电话号码仍然低至7吗？我倾向于10。 我并不是说我到处都违反了这条规则，相反，我的方法体积小且专注于95％，但我说你永远不应该违反这条规则，这真的让我感到震惊。 我真的只是想知道每个人对永不违反此规则的看法（在编码标准上为“ 1”-永不这样做）。但是我认为您很难找到没有的代码库。

78 c#  coding-standards  maintainability 

当我编写代码时，我总是试图使我的代码尽可能的干净和可读。 偶尔会有一段时间，您需要越界，从漂亮的干净代码变为稍微难看的代码，以使其更快。 什么时候可以越过那条线？

67 performance  optimization  quality  readability  maintainability 

我的嵌套函数调用的编码样式如下： var result_h1 = H1(b1); var result_h2 = H2(b2); var result_g1 = G1(result_h1, result_h2); var result_g2 = G2(c1); var a = F(result_g1, result_g2); 我最近转到了一个部门，该部门非常使用以下编码样式： var a = F(G1(H1(b1), H2(b2)), G2(c1)); 我的编码方式的结果是，在功能崩溃的情况下，Visual Studio可以打开相应的转储并指出发生问题的行（我特别担心访问冲突）。 我担心，如果因第一种方式编程的相同问题而导致崩溃，我将无法知道是哪个函数导致了崩溃。 另一方面，行上进行的处理越多，一页上得到的逻辑就越多，从而增强了可读性。 我的恐惧是正确的还是我缺少什么？总的来说，在商业环境中这是首选吗？可读性还是可维护性？ 我不知道它是否相关，但是我们正在使用C ++（STL）/ C＃。

57 c#  c++  coding-style  readability  maintainability 

另一种询问方式是：为什么程序趋于单一？ 我想到的是像Maya这样的动画包，人们将其用于各种不同的工作流程。 如果将动画和建模功能拆分成自己的独立应用程序并分别进行开发，并在它们之间传递文件，那么它们是否会更易于维护？

48 design  architecture  maintainability  application-design 

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

47 code-quality  code-smell  maintainability 

我们都知道，幻数（硬编码值）会对您的程序造成严重破坏，尤其是当需要修改没有注释的一段代码时，您会在哪里划清界线？ 例如，如果您有一个计算两天之间的秒数的函数，您是否要替换 seconds = num_days * 24 * 60 * 60 与 seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE 您在什么时候确定硬编码值意味着什么是完全显而易见的，而不管它呢？

36 refactoring  coding-standards  maintainability 

在回答这个问题时，我开始怀疑为什么这么多的开发人员认为好的设计不应该考虑性能，因为这样做会影响可读性和/或可维护性。 我相信，一个好的设计在编写时也要考虑性能，并且一个好的设计的优秀开发人员可以编写一个高效的程序，而不会对可读性或可维护性产生不利影响。 尽管我承认存在极端情况，但为什么许多开发人员坚持认为高效的程序/设计将导致较差的可读性和/或较差的可维护性，因此，性能不应作为设计考虑因素？

34 code-quality  performance  readability  maintainability 

这是一个颇具争议的话题，我想与程序员一样多。但是，为此，我想知道业务（或您的工作场所）中的常见做法。 在我的工作场所，我们有严格的编码准则。其中一部分专门用于魔术字符串/数字。它指出（对于C＃）： 除了定义符号常量外，请勿在代码中使用数字或字符串的文字值。使用以下模式定义常量： public class Whatever { public static readonly Color PapayaWhip = new Color(0xFFEFD5); public const int MaxNumberOfWheels = 18; } 有例外：几乎可以始终安全地使用值0、1和null。通常，值2和-1也可以。用于记录或跟踪的字符串不受此规则的限制。当文字的含义在上下文中很清楚且不受将来的更改时，允许使用文字。 mean = (a + b) / 2; // okay WaitMilliseconds(waitTimeInSeconds * 1000); // clear enough 理想的情况是在以下情况下一些官方研究论文对代码的可读性/可维护性产生影响： 魔术数字/字符串无处不在 魔术字符串/数字会被常量声明合理地替换（或在不同程度的覆盖范围内）-请不要因为使用“合理地”而对我大喊大叫，我知道每个人都有不同的想法，“合理地”是什么 魔术字符串/数字被多余地替换在不需要的地方（请参见下面的示例） 在与一位同事争论时，我希望这样做具有一些基于科学的论据，而后者将要声明常量，例如： private const char SemiColon = ';'; private …

31 coding-style  refactoring  coding-standards  readability  maintainability 

在一个相当大的项目中有一个源文件，它具有几个对性能极为敏感的功能（每秒被称为百万次）。实际上，先前的维护者决定编写一个函数的12个副本，每个副本的差别都很小，以节省在单个函数中检查条件的时间。 不幸的是，这意味着代码是要维护的PITA。我想删除所有重复的代码，只写一个模板。但是，Java语言不支持模板，我不确定泛型是否适合于此。 我目前的计划是写一个文件，该文件生成该函数的12个副本（实际上是一个只能使用的模板扩展器）。对于为什么必须以编程方式生成文件，我当然会提供很多解释。 我担心的是，这将导致将来的维护人员感到困惑，并且如果他们在修改文件后忘记重新生成文件，或者（如果更糟糕的话）他们以编程方式生成的文件进行修改，则可能会引入讨厌的错误。不幸的是，除了没有用C ++重写整个过程外，我看不到任何解决方法。 这种方法的好处是否大于缺点？我应该改为： 发挥性能优势，并使用单个可维护的功能。 添加有关为何必须重复执行该功能12次的说明，并应承担维护负担。 尝试将泛型用作模板（它们可能无法那样工作）。 大吼大叫的老维护者，使代码的性能取决于单个函数。 其他保持性能和可维护性的方法？ PS：由于该项目的设计不佳，对功能进行性能分析非常棘手……但是，这位前维护人员说服了我，性能下降是不可接受的。我认为他的意思是超过5％，尽管这完全是我的猜测。 也许我应该详细说明一下。这12份副本执行的任务非常相似，但差别很小。在整个函数中的不同地方存在差异，因此不幸的是，有很多很多条件语句。有效地有6种“操作模式”和2种“范例”（由我自己编造的词）。要使用该功能，可以指定操作的“模式”和“范例”。这从来都不是动态的。每段代码仅使用一种模式和范例。所有12个模式范例对都在应用程序中的某个位置使用。这些函数恰当地命名为func1到func12，偶数代表第二个范例，奇数代表第一个范例。 我知道，如果以可维护性为目标，那将是最糟糕的设计。但是它似乎“足够快”，并且这段代码已经有一段时间不需要任何更改了。也值得注意的是原始功能尚未删除（尽管据我所知这是无效代码） ，因此重构将很简单。

29 java  performance  maintainability  templates 

是否在else while不使用大括号的情况下将其视为“安全”的维护方法？ 编写if-else没有括号的代码，如下所示... if (blah) foo(); else bar(); ...带有风险，因为缺少花括号，很容易在不经意间更改代码的含义。 但是，下面是否也有风险？ if (blah) { ... } else while (!bloop()) { bar(); } 还是else while不使用大括号将其视为“安全”的？

26 coding-style  language-agnostic  maintainability 

考虑一个允许插件对其程序流做出反应的应用。 我知道两种方法可以实现：钩子和事件 1.挂钩 在主程序流中使用调用来清空函数。插件可以覆盖这些功能。 例如，Drupal CMS实现了可用于模块和主题的挂钩。这是在file_copy函数中如何实现钩子的示例。 function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) { // ... [File copying routine] // Inform modules that the file has been copied. module_invoke_all('file_copy', $file, $source); return $file; // ... } 模块可以实现modulename_file_copy($file, $source)将由module_invoke_allin 调用的功能file_copy。该功能完成后，file_copy将恢复执行。 2.活动 拥有应用程序分发事件，插件可以监听该事件。收到已订阅的事件后，插件将拦截程序流并执行必要的操作。 例如，一个jQuery画廊插件Fotorama 实现了几个事件。例如，这show是触发fotorama:show事件的方法的一部分。 that.show = function (options) { …

24 readability  maintainability  event-programming  plugins  hooks 

上下文：我是全MS商店中的企业开发人员。 谁能推荐一种客观地衡量一段代码或应用程序可维护性的好方法？ 为什么要进行可维护性：我对小组中的“质量”度量标准感到厌倦，该度量标准仅围绕bug的数量和代码覆盖率而变化。这两个指标都很容易使用，尤其是当您不评估可维护性时。目光短浅和截止日期导致大量技术债务，这些债务从未真正得到解决。 为什么具有客观衡量的能力：我在一个大型企业集团中工作。如果您不能客观地衡量它，就不能让人们对此负责，也不能使他们变得更好。主观测量要么不会发生，要么不会持续发生。 我正在查看VS2010代码指标，但我想知道是否还有其他建议。

23 c#  visual-studio-2010  metrics  maintainability  measurement