代码应该简洁/简洁吗？

Question

在编写数学证明时,一个目标是继续压缩证明.证明变得更优雅,但不一定更具可读性.压缩意味着更好的理解,因为你清除了不必要的字符和冗长.

我经常听到开发人员说你应该让代码足迹尽可能小.这可以非常快速地产生不可读的代码.在数学方面,这不是一个问题,因为这个练习纯粹是学术性的.然而,在时间就是金钱的生产代码中,让人们试图弄清楚一些非常简洁的代码正在做什么似乎没有多大意义.对于更详细的代码,您可以获得可读性和节省.

你什么时候停止压缩软件代码？

Answer 1

我尝试达到一定程度的冗长程度,我的程序语句就像任何程序员都能理解的句子一样.这确实意味着对我的代码进行大量重构,使其成为故事的所有短片,因此每个动作都将在一个单独的方法中描述(更进一步的级别可能是另一个类).

意思是我不会因为它可以用更少的表达来减少我的字符数.这就是代码高尔夫比赛的目的.

还有一些关于调试的说法.较短的代码可以消除您想要放置断点的区域,这是一个缺点. (9认同)
+1:代码有意义.软件是知识捕获.软件是证据依赖于引理和公理的一种组合. (5认同)
如果您没有构建API,请不要担心长函数名称.拥有带有长描述性名称的短(代码行)函数,您会对代码的"自我记录"变得惊讶.(如果您正在构建API,或任何不是"工作函数"的东西,您还需要尊重那些必须输入您的函数名称的人) (2认同)

Answer 2

我的规则是说出你的意思.我看到人们出错的一种常见方式是"减少力量".基本上,他们用似乎跳过步骤的东西取代了他们正在思考的概念.不幸的是,他们将概念从代码中删除,使其更难阅读.

例如,改变

for (int i = 0; i < n; i++)
    foo[i] = ...

至

int * p = foo, q = foo+n;
while ( *p++ = ... < q );

是一个强度降低的例子,似乎可以节省步骤,但它省略了foo是一个数组的事实,使得它更难阅读.

另一个常见的是使用bool而不是enum.

enum {
    MouseDown,
    MouseUp
};

有这个

bool IsMouseDown;

遗漏了这是一台状态机的事实,使得代码难以维护.

所以我的经验法则是,在你的实现中,不要深入到比你想要表达的概念更低的层次.

Answer 3

您可以通过查看冗余并消除它或通过聪明来使代码更小.做前者而不是后者.

Answer 4

这是Steve McConnell的一篇好文章 - 最佳实践http://www.stevemcconnell.com/ieeesoftware/bp06.htm

我认为简短/简洁是来自编写良好的代码的两个结果.有很多方面可以使代码很好,许多结果来自编写良好的代码,实现两者是不同的.你没有计划一个小脚印,你计划一个简洁的功能,并做一件事非常好 - 这应该导致一个小脚印(但可能不会).以下是编写代码时我会关注的简短列表:

单一功能 - 一个功能应该只做一件事,一个简单的交付,多功能的功能是错误的,不容易重复使用
松散耦合 - 不要从一个函数内部扩展到全局数据,也不要太依赖其他函数
精确命名 - 使用有意义的精确变量名称,神秘的名称就是这样
保持代码简单而不复杂 - 不要过度使用语言特定的技术哇,有利于给别人留下深刻印象,难以理解和维护 - 如果你确实添加了一些'特别'的评论,那么至少人们可以在诅咒之前欣赏它你出去
均匀评论 - 许多评论将被忽略,过时几乎没有任何意义
格式化 - 以代码的外观为傲,正确缩进代码有帮助
与代码维护人员的思维一起工作 - 想想维护你正在编写的代码是什么样的
害怕或懒惰重构 - 第一次没有什么是完美的,清理你自己的烂摊子

Answer 5

找到平衡点的一种方法是寻求可读性而不是简洁性.程序员不断地直观地扫描代码以查看正在完成的工作,因此代码应该尽可能地流动.

如果程序员正在扫描代码并点击难以理解的部分,或者需要付出一些努力来直观地解析和理解,那就不好了.使用常见的易于理解的结构很重要,除非必要,否则要远离模糊和不经常使用.

人类不是编译器.编译器可以吃东西并继续前进.人类在精神上消耗的代码并不像清楚理解的代码一样快.

有时很难在复杂的算法中生成可读代码,但在大多数情况下,人类可读性是我们应该寻找的,而不是聪明.我认为代码的长度也不是真正的清晰度,因为有时候一个更简洁的方法比一个简洁的方法更具可读性,有时简洁的方法比长方法更易读.

此外,评论应该只是补充,而不应该描述您的代码,您的代码应该描述自己.如果你必须评论一条线,因为它不明显做了什么,那就不好了.大多数有经验的程序员阅读英文解释所需的时间比阅读代码本身要长.我认为Code Complete这本书扼杀了这个家.