Questions tagged «readability»

可读性衡量代码易于阅读和理解。

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

6
为什么嵌套循环被认为是不好的做法?
我的讲师今天提到,可以在Java中“标记”循环,以便在处理嵌套循环时可以引用它们。因此,我在不了解该功能的情况下查找了该功能,并在很多地方对该功能进行了解释,然后警告并阻止嵌套循环。 我真的不明白为什么吗?是否因为它影响代码的可读性?还是更具“技术性”?

9
while(true)和循环中断-反模式?
考虑以下代码: public void doSomething(int input) { while(true) { TransformInSomeWay(input); if(ProcessingComplete(input)) break; DoSomethingElseTo(input); } } 假设此过程涉及有限但与输入有关的步骤数;循环的目的是由于算法而自行终止,而不是设计为无限期地运行(直到被外部事件取消为止)。因为检查循环是否应该结束的测试是在逻辑步骤的中间,所以while循环本身目前不检查任何有意义的事情;而是在概念算法的“适当”位置执行检查。 有人告诉我这是错误的代码,因为由于循环结构未检查结束条件,所以它更容易出错。弄清楚如何退出循环会更加困难,并且由于将来的更改可能会意外地忽略或破坏中断条件,因此可能会引发错误。 现在,代码的结构如下: public void doSomething(int input) { TransformInSomeWay(input); while(!ProcessingComplete(input)) { DoSomethingElseTo(input); TransformInSomeWay(input); } } 但是,这会重复调用代码中的方法,这违反了DRY。如果TransformInSomeWay后来被其他方法替换,则必须找到并更改这两个调用(在更复杂的代码中可能不那么明显地存在两个调用)。 您也可以这样写: public void doSomething(int input) { var complete = false; while(!complete) { TransformInSomeWay(input); complete = ProcessingComplete(input); if(!complete) { DoSomethingElseTo(input); } …

16
简单是否会始终提高可读性?
最近,我正在为我们的公司开发一套编码标准。(我们是一个新团队,正在为公司扩展一种新语言。) 在我的初稿中,我设定了编码标准的目的是提高可读性,可维护性,可靠性和性能。(我忽略了可写性,可移植性,成本,与以前的标准的兼容性等) 编写本文档时,我的目标之一是推动代码简化的想法。想法是每行只能有一个函数调用或操作。我希望这将提高可读性。我从以前的语言中继承了这个想法。 但是,我对这种推动背后的假设提出了质疑: 简单是否会始终提高可读性? 是否存在编写更简单的代码会降低可读性的情况? 这很明显,但是“简单”并不是说“易于编写”,而是每行更少的内容。

4
魔术字符串/数字的用法
这是一个颇具争议的话题,我想与程序员一样多。但是,为此,我想知道业务(或您的工作场所)中的常见做法。 在我的工作场所,我们有严格的编码准则。其中一部分专门用于魔术字符串/数字。它指出(对于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 …

5
返回不良样式/危险后使用finally子句进行工作吗?
作为编写迭代器的一部分,我发现自己正在编写以下代码(剥离错误处理) 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是否不好?如果在简化代码时实际上是首选。 如果不好,为什么?风格,性能,陷阱...? 结论 谢谢大家的回答!我猜得出的结论(至少对我而言)是,如果第一个示例是通用模式,则它可能更具可读性,但事实并非如此。因此,使用超出其目的的构造所带来的混乱,以及可能造成混淆的异常流,将胜过任何简化。


8
有没有一种编程范例可以促进使依赖关系对其他程序员来说非常明显?
我在一个数据仓库中工作,该数据仓库通过许多流和层为多个系统提供源,并且具有迷宫般的依赖关系,将各种工件链接在一起。几乎每天我都会遇到这样的情况:我运行某些东西,它不起作用,运行大量代码,但是几个小时后,我意识到我已经设法将现在所知的一小部分概念化为流程图需要一天的稍后时间,所以我问一个人,他们告诉我必须先运行另一个流,并且如果我在这里检查(表明其他编码依赖项的巨大堆栈中某些看似任意的部分),则我将看到了这个。真令人沮丧。 如果我能够向团队建议,如果我们做更多的事情来使对象之间的依赖关系更加可见和明显,而不是将它们深深地嵌入到递归代码级甚至数据中,那可能是个好主意。之所以必须存在,是因为它被另一个流填充了,也许是通过引用一个众所周知的,经过测试的软件范例进行的,那么我也许可以使我的工作变得简单,而其他所有人都可以简化很多。 向我的团队解释这种好处是很困难的。他们倾向于按照现状接受事物,而不是“想大”,因为他们看到了能够以新方式概念化整个系统的好处–他们并没有真正看到是否可以为大型系统建模高效,那么就不太可能遇到内存效率低下,流停止唯一约束和重复键,废话数据的情况,因为这样可以更轻松地进行设计以符合原始视觉,并且以后不会遇到所有这些问题我们现在正在经历,我知道这与以往的工作不同寻常,但他们似乎认为这是不可避免的。 那么,有谁知道一个强调依赖关系并促进系统通用概念模型以确保长期遵守理想的软件范例?目前,我们几乎陷入了混乱,每个冲刺的解决方案似乎都是“只是在这里,这里和这里添加此东西”,而我是唯一一个担心事情真的开始崩溃的人。

11
避免使用Postfix增量运算符
我已经读到由于性能原因(在某些情况下),我应该避免使用后缀增量运算符。 但这不影响代码的可读性吗?在我看来: for(int i = 0; i < 42; i++); /* i will never equal 42! */ 看起来比: for(int i = 0; i < 42; ++i); /* i will never equal 42! */ 但这可能只是出于习惯。诚然,我没有看到很多用处++i。 在这种情况下,性能是否牺牲了可读性?还是我只是盲目的,++i可读性比i++?

7
指定可选参数名称,即使不是必需的?
请考虑以下方法: public List<Guid> ReturnEmployeeIds(bool includeManagement = false) { } 和以下调用: var ids = ReturnEmployeeIds(true); 对于刚接触该系统的开发人员来说,很难猜得出是什么true。您要做的第一件事是将鼠标悬停在方法名称上或转到定义(都不是丝毫大的任务)。但是,出于可读性考虑,编写以下代码是否有意义: var ids = ReturnEmployeeIds(includeManagement: true); 在编译器不需要您时,是否有任何地方正式讨论是否明确指定可选参数? 以下文章讨论了某些编码约定:https : //msdn.microsoft.com/zh-cn/library/ff926074.aspx 与上面的文章类似的东西会很棒。

2
使用where条件vs Continue保护子句过滤foreach循环
我已经看到一些程序员使用此: foreach (var item in items) { if (item.Field != null) continue; if (item.State != ItemStates.Deleted) continue; // code } 而不是我通常使用的位置: foreach (var item in items.Where(i => i.Field != null && i.State != ItemStates.Deleted)) { // code } 我什至看到了两者的结合。我真的很喜欢“继续”的可读性,尤其是在更复杂的条件下。性能上甚至有差异吗?通过数据库查询,我假设会有。常规列表呢?

4
插件应该使用什么:钩子,事件或其他东西?
考虑一个允许插件对其程序流做出反应的应用。 我知道两种方法可以实现:钩子和事件 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) { …

2
提供执行相同操作的不同功能签名是一个好主意吗?
这是一个用三个值构造的C ++类。 class Foo{ //Constructor Foo(std::string, int, char); private: std::string foo; char bar; int baz; }; 所有参数类型都不同。 我可以重载构造函数,因此顺序无关紧要。 class Foo{ //Constructors Foo(std::string, char, int); Foo(std::string, int, char); Foo(char, int, std::string); Foo(char, std::string, int); Foo(int, std::string, char); Foo(int, char, std::string); private: std::string foo; char bar; int baz; }; 但这是个好主意吗? 我开始这样做是因为我知道一个类/函数需要什么东西。 我并不总是记得他们接受了什么命令。 …

7
'var'和null合并运算符'??'应该走多远 在不影响可读性的情况下进行娱乐?
该问题是从Code Review Stack Exchange 迁移而来的,因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我知道问题的标题是非常主观的,但是??我的同龄人遇到了使用运算符的问题,而与此同时,我对申请var新的即将出现的代码并不满意/不满意。 使用??operator 给出的参数是,它占用了代码的可读性。 我的问题是,开始使用时会发生同样的事情var吗?

12
如果长函数具有内部结构,是否可以接受?
当使用支持嵌套函数(例如Python和D)的语言处理复杂算法时,我经常编写大型函数(因为算法很复杂),但是通过使用嵌套函数来构造复杂代码来减轻这种情况。即使大型功能(超过100行)仍通过使用嵌套功能在内部进行了结构合理,仍然被认为是邪恶的? 编辑:对于那些不熟悉Python或D的人,这些语言中的嵌套函数还允许访问外部函数范围。在D中,此访问权限允许外部范围内的变量发生突变。在Python中,它仅允许读取。在D中,可以通过声明显式禁用对嵌套函数中的外部范围的访问static。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.