在编写数学证明时，一个目标是继续压缩证明。证明变得更优雅，但不一定更具可读性。压缩意味着更好的理解，因为你清除了不必要的字符和冗长。
我经常听到开发人员说你应该让代码足迹尽可能小。这可以非常快速地产生不可读的代码。在数学方面，这不是一个问题，因为这个练习纯粹是学术性的。然而，在时间就是金钱的生产代码中，让人们试图弄清楚一些非常简洁的代码正在做什么似乎没有多大意义。对于更详细的代码，您可以获得可读性和节省。
你什么时候停止压缩软件代码？
答案 0 :(得分：25)
我尝试达到一定程度的冗长程度，我的程序语句就像任何程序员都能理解的句子一样。这确实意味着对我的代码进行大量重构，使其成为故事的所有短片，因此每个动作都将在一个单独的方法中描述（更进一步的级别可能是另一个类）。
意思是我不会因为它可以用更少的表达来减少我的字符数。这就是代码 - 高尔夫比赛的目的。
答案 1 :(得分：15)
我的规则说出你的意思。我看到人们出错的一种常见方式是“减少力量”。基本上，他们用似乎跳过步骤的东西取代了他们正在思考的概念。不幸的是，他们将概念从代码中删除，使其更难阅读。
例如，更改
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;
遗漏了这个状态机的事实，使代码难以维护。
所以我的经验法则是，在你的实现中，不要深入到比你想要表达的概念更低的层次。
答案 2 :(得分：12)
您可以通过查看冗余并消除代码或通过聪明来减少代码。做前者而不是后者。
答案 3 :(得分：8)
以下是史蒂夫麦康奈尔的一篇好文章 - 最佳实践http://www.stevemcconnell.com/ieeesoftware/bp06.htm
我认为简短/简洁是来自编写良好的代码的两个结果。有很多方面可以使代码很好，许多结果来自编写良好的代码，实现两者是不同的。你没有计划一个小脚印，你计划一个简洁的功能，并做一件事非常好 - 这应该导致一个小脚印（但可能不会）。以下是编写代码时我会关注的简短列表：
答案 4 :(得分：7)
找到平衡点的一种方法是寻求可读性而不是简洁。程序员不断地直观地扫描代码以查看正在完成的工作，因此代码应该尽可能地流动。
如果程序员正在扫描代码并点击一个难以理解的部分，或者需要付出一些努力来进行视觉解析和理解，那就不好了。使用常见的理解结构非常重要，除非必要，否则请远离模糊和不经常使用。
人类不是编译器。编译器可以吃东西并继续前进。人类在精神上消耗的代码并不像清楚理解的代码一样快。
有时很难在复杂的算法中生成可读代码，但在大多数情况下，人类的可读性是我们应该寻找的，而不是聪明。我认为代码的长度也不是真正的清晰度，因为有时候一个更简洁的方法比一个简洁的方法更具可读性，有时简洁的方法比长方法更易读。
此外，评论只应补充，而不应描述您的代码，您的代码应该自我描述。如果你必须评论一条线，因为它不明显做了什么，那就不好了。大多数有经验的程序员阅读英文解释所需的时间比阅读代码本身要长。我认为Code Complete这本书会把这个作为主题。
答案 5 :(得分：3)
就对象名称而言，对此的思考经历了新的编程语言的引入。
如果你采用“大括号”语言，从C开始，简洁被认为是智慧的灵魂。因此，您可以使用变量来保存名为“lv”的贷款值。这个想法是你输入了很多代码，所以要将键击保持在最低限度。
然后是微软批准的“匈牙利符号”，其中变量名的第一个字母用于表示其基础类型。可以使用“fLV”或其他一些来表示贷款值由浮点变量表示。
使用Java，然后使用C＃，范例已经变得清晰。贷款价值变量的一个好名称是“loanValue”。我相信部分原因是大多数现代编辑器中的命令完成功能。由于不再需要输入整个名称，因此您可以使用尽可能多的字符来描述。
这是一个很好的趋势。代码需要易于理解。如果有的话，评论通常会作为事后补充添加。它们也不会随着代码的更新而更新，因此它们会过时。描述性的， 精心挑选的 ，变量名称是让别人知道你编码的第一个，最好和最简单的方法。
我有一位计算机科学教授说：“作为工程师，我们不断创造以前从未存在过的东西。我们给他们的名字会坚持下去，所以我们应该小心命名 有意义 即可。“
答案 6 :(得分：1)
需要在简短的甜蜜源代码和性能之间取得平衡。如果它是一个很好的来源并且运行速度最快，那么很好，但是为了好的来源它会像狗一样运行，然后很糟糕。
答案 7 :(得分：1)
努力重构，直到代码本身读得很好。你将在这个过程中发现自己的错误，代码将更容易为“下一个人”找到，并且你不会因为在评论中维护（后来忘记改变）你已经表达过的内容而负担沉重代码。
当失败时......确定，请给我留言。
并且不要告诉我评论中的“内容”（这就是代码的用途），告诉我“为什么”。
答案 8 :(得分：1)
与长/漫步相反？当然！
但它已经达到了如此短暂和简洁以至于难以理解的程度，那么你已经走得太远了。
答案 9 :(得分：1)
是。总是
答案 10 :(得分：1)
DRY ：不要重复自己。这将为您提供简洁安全的代码。多次编写相同的代码是一种难以维护的好方法。
现在这并不意味着你应该使任何代码块的功能看起来都相似。
一个非常常见的错误（恐怖？）例如，分解代码执行几乎相同的事情，并通过向函数API添加标志来处理事件之间的差异。这可能一开始看起来很麻烦，但是生成的代码流程难以理解且容易出错，甚至更难以重构。
如果您遵循常见的重构规则（查看代码气味），您的代码将变得越来越简洁，因为许多代码气味都是关于检测冗余的副作用。
另一方面，如果您尝试使代码尽可能短而不遵循任何有意义的指导原则，那么在某些时候您将不得不停止，因为您将不再看到如何减少代码。
想象一下，如果第一步是删除所有无用的空格......在此步骤之后，大多数编程语言中的代码将变得如此难以阅读，您将没有太多机会找到任何其他可能的增强。
上面的例子非常具有讽刺意味，但是在没有遵循任何合理的指导原则的情况下尝试优化尺寸时所得到的并不是很远。
答案 11 :(得分：0)
总的来说，我使事情变得明显且易于使用。如果简洁/短促为我服务，那就更好了。通常简短的答案是最清晰的，所以短缺是明显的副产品。
答案 12 :(得分：0)
我的想法有几点决定何时停止优化：
值得花时间进行优化。如果你有人花了几周而没有找到任何东西，那么这些资源有更好的用途吗？
优化优先级的顺序是什么。在代码方面，人们可以关注几个不同的因素：执行时间，执行空间（运行和编译代码），可伸缩性，稳定性，实现了多少功能等。部分原因是交易脱离时间和空间，但也可能是某些代码的去向，例如中间件可以执行临时SQL命令，还是应该通过存储过程进行路由以提高性能？
我认为重点是大多数优秀的解决方案都会有一个审核。
答案 13 :(得分：0)
对于小代码封装的需求是汇编语言和第一个略高级语言的时代的回归......那里有一个真正迫切需要的小代码脚印。这些天来，它不是必需品。
那就是说，我讨厌冗长的代码。在我工作的地方，我们编写的代码尽可能像自然语言一样阅读，没有任何额外的语法或单词。除非它是一个非常常见的缩写，否则我们不会缩写任何内容。
Company.get_by_name("ABC")
makeHeaderTable()
和我们一样简洁。
答案 14 :(得分：0)
代码优化与编码风格几乎没有关系。文件包含x空格或小于开头的新行的事实不会使其更好或更快，至少在执行阶段 - 您使用编译器不会忽略的白色字符格式化代码。它甚至会使代码变得更糟，因为它对其他程序员和你自己来说都是不可读的。
更重要的是，代码在其逻辑结构中要短而干净，例如测试条件，控制流，假设，错误处理或整个编程接口。当然，我还会在这里包含智能和有用的评论+文档。
答案 15 :(得分：0)
简洁代码与性能之间不一定存在关联。这是一个神话。在像C / C ++这样的成熟语言中，编译器能够非常有效地优化代码。在这些语言中有理由需要假设更简洁的代码是性能更好的代码。较新的，性能较差的语言（如Ruby）缺乏C / C ++编译器的编译器优化功能，但仍然没有理由相信简洁的代码表现更好。实际情况是，我们永远不知道代码在生产和生产之前在生产中的表现如何。如果从代码中的足够位置调用，那么简单，无害的函数可能是巨大的性能瓶颈。在高度并发的系统中，最大的瓶颈通常是由不良的并发算法或过度锁定引起的。通过编写“简洁”代码很难解决这些问题。
底线是这样的：一旦性能分析确定它是瓶颈，那么表现不佳的代码总是可以重构。只有易于理解，才能有效地重构代码。编写为“简洁”或“聪明”的代码通常更难以重构和维护。
编写您的人类可读性代码，然后在必要时重构性能。
我的两分钱......
答案 16 :(得分：0)
没有确切的线可以区分作为glib的代码和华丽的代码。用你最好的判断。让其他人查看您的代码，看看他们能够轻松理解它。但请记住，正确性是第一目标。
答案 17 :(得分：-1)
代码应简短，具体，集中。您可以随时在评论中用许多单词解释您的想法。
答案 18 :(得分：-3)
只要您对代码进行评论，就可以将代码设置为简短或紧凑。这样，您的代码可以进行优化，但仍然可以实现。如果仍然不清楚，我倾向于使用描述性变量和方法以及sparce注释留在中间位置。