编写数学证明时，一个目标是继续压缩证明。证明变得更加优雅，但不一定更具可读性。压缩转化为更好的理解，因为您消除了不必要的字符和冗长。
我经常听到开发人员说您应该使代码占用空间尽可能小。这会很快产生不可读的代码。在数学中，这不是一个问题，因为该练习纯粹是学术性的。然而，在时间就是金钱的生产代码中，让人们试图弄清楚一些非常简洁的代码在做什么似乎没有多大意义。对于更冗长的代码，您可以获得可读性和节省。
什么时候停止压缩软件代码？
【问题讨论】：
干燥：不要重复自己。这将为您提供既简洁又安全的代码。多次编写相同的代码是使其难以维护的好方法。
现在这并不意味着您应该为任何看起来很相似的代码块创建一个函数。
一个非常常见的错误（恐怖？）例如，分解代码执行几乎相同的事情，并通过向函数 API 添加标志来处理出现之间的差异。起初这可能看起来无害，但生成的代码流难以理解且容易出错，甚至更难重构。
如果您遵循常见的重构规则（查看代码异味），您的代码将变得越来越简洁，因为许多代码异味都与检测冗余有关。
另一方面，如果您不遵循任何有意义的准则而尝试使代码尽可能短，那么在某些时候您将不得不停下来，因为您再也看不到如何减少代码了。
试想一下，如果第一步是删除所有无用的空格......在大多数编程语言中的该步骤代码将变得如此难以阅读之后，您将没有太多机会找到任何其他可能的增强功能。
上面的例子很讽刺，但与你在不遵循任何明智的指导方针的情况下尝试优化大小时得到的结果相差无几。
【讨论】：
就对象名称而言，随着新编程语言的引入，对此的思考已经发生了演变。
如果您采用“花括号”语言，从 C 开始，简洁被认为是智慧的灵魂。因此，例如，您将有一个变量来保存名为“lv”的贷款值。当时的想法是您要输入大量代码，因此请尽量减少击键次数。
随后出现了 Microsoft 认可的“匈牙利表示法”，其中变量名称的第一个字母表示其基础类型。有人可能会使用“fLV”或类似的词来表示贷款价值是由一个浮点变量表示的。
随着 Java，然后是 C#，范式变得清晰。贷款价值变量的好名字是“loanValue”。我相信部分原因是大多数现代编辑器中的命令完成功能。由于不再需要输入完整的名称，因此您可以使用尽可能多的字符来进行描述。
这是一个很好的趋势。代码需要易于理解。评论通常是事后才添加的，如果有的话。它们也不会随着代码的更新而更新，因此它们已经过时了。描述性的、精心挑选的变量名是让其他人知道您的编码内容的首选、最佳和最简单的方法。
我有一位计算机科学教授说：“作为工程师，我们不断创造出以前从未存在过的事物类型。我们给它们起的名字会一直存在，所以我们应该小心命名事物有意义的。”
【讨论】：
只要您对代码进行注释，您就可以使代码尽可能简短或紧凑。这样你的代码可以优化但仍然有意义。如果还不清楚，我倾向于在描述性变量和方法的中间位置停留。
【讨论】：
是的。总是。
【讨论】：
相对于冗长/漫无边际？当然！
但它太短太简洁以至于难以理解，那么你就走得太远了。
【讨论】：
这是 Steve McConnell 的一篇好文章 - 最佳实践http://www.stevemcconnell.com/ieeesoftware/bp06.htm
我认为简短/简洁是编写良好代码的两个结果。编写好的代码有很多方面，写得好的代码有很多结果，意识到两者是不同的。你不打算为一个小的足迹，你计划一个简洁的功能，并且做得非常好 - 这应该导致一个小的足迹（但可能不会）。以下是我在编写代码时会关注的简短列表：
【讨论】：
简洁的代码和性能之间不一定存在相关性。这是一个神话。在像 C/C++ 这样的成熟语言中，编译器能够非常有效地优化代码。在这些语言中，有必要假设代码越简洁，性能就越好。像 Ruby 等较新的、性能优化较少的语言缺乏 C/C++ 编译器的编译器优化功能，但仍然没有理由相信简洁的代码性能更好。现实情况是，在代码投入生产并进行分析之前，我们永远不知道代码在生产中的性能如何。如果从代码中的足够多的位置调用简单、无害的函数，可能会成为巨大的性能瓶颈。在高并发系统中，最大的瓶颈通常是由糟糕的并发算法或过度锁定引起的。这些问题很少通过编写“简洁”的代码来解决。
底线是：一旦性能分析确定它是瓶颈，性能不佳的代码总是可以重构。只有易于理解的代码才能有效地重构。写得“简洁”或“聪明”的代码通常更难重构和维护。
编写代码以提高可读性，然后在必要时重构以提高性能。
我的两分钱...
【讨论】：
代码优化与编码风格几乎没有关系。文件包含的 x 空格或新行少于开头的事实并不能使它更好或更快，至少在执行阶段是这样 - 您使用编译器通常忽略的白色字符格式化代码。它甚至使代码变得更糟，因为它变得无法让其他程序员和您自己阅读。
更重要的是代码的逻辑结构要简洁明了，例如测试条件、控制流、假设、错误处理或整体编程接口。当然，我也会在此处包含智能且有用的 cmets + 文档。
【讨论】：
找到平衡的一种方法是寻求可读性，而不是简洁。程序员不断地以视觉方式扫描代码以查看正在执行的操作，因此代码应尽可能流畅。
如果程序员在扫描代码时碰到了难以理解的部分，或者费了些力气在视觉上解析和理解，那是一件坏事。使用常见且易于理解的结构很重要，除非必要，否则不要使用模糊且不经常使用的结构。
人类不是编译器。编译器可以吃掉这些东西并继续前进。晦涩的代码不会像清晰理解的代码那样迅速地被人类在精神上消耗掉。
有时很难用复杂的算法生成可读的代码，但在大多数情况下，我们应该寻找的是人类可读性，而不是聪明。我也不认为代码的长度真的是衡量清晰程度的标准，因为有时更冗长的方法比简洁的方法更具可读性，有时更简洁的方法比长的方法更具可读性。
另外，cmets 应该只是补充，而不应该描述你的代码，你的代码应该描述它自己。如果你必须评论一行，因为它不明显做了什么，那很糟糕。大多数有经验的程序员阅读英文解释比阅读代码本身需要更长的时间。我认为 Code Complete 这本书很适合这一点。
【讨论】：
努力重构，直到代码本身阅读良好。你会在这个过程中发现自己的错误，代码会更容易被“下一个人”理解，并且你不会因为在 cmets 中维护（后来忘记更改）你已经表达过的东西而感到负担代码。
如果失败...当然，请给我留言。
不要在评论中告诉我“什么”（这就是代码的用途），告诉我“为什么”。
【讨论】：
代码应该简短、具体、集中。 cmets 中你总是可以用很多词来解释你的想法。
【讨论】：
我的规则是说出你的意思。我看到人们出错的一种常见方式是“降低力量”。基本上，他们用似乎跳过步骤的东西代替了他们正在考虑的概念。不幸的是，他们在代码中遗漏了概念，使其更难阅读。
例如，改变
for (int i = 0; i < n; i++)
foo[i] = ...
到
int * p = foo, q = foo+n;
while ( *p++ = ... < q );
是一个似乎可以节省步骤的强度降低示例，但它忽略了 foo 是一个数组这一事实，从而使其更难阅读。
另一个常见的方法是使用 bool 而不是枚举。
enum {
MouseDown,
MouseUp
};
就这样
bool IsMouseDown;
忽略了这是一个状态机这一事实，使代码更难维护。
所以我的经验法则是，在你的实现中，不要深入到比你试图表达的概念更低的层次。
【讨论】：
我认为有几点决定何时停止优化：
值得花时间进行优化。如果有人花费数周时间却一无所获，是否可以更好地利用这些资源？
优化优先级的顺序是什么。当涉及到代码时，人们可能会关心几个不同的因素：执行时间、执行空间（运行和编译的代码）、可扩展性、稳定性、实现了多少功能等。其中一部分是交易脱离时间和空间，但它也可能是一些代码的去向，例如中间件可以执行即席 SQL 命令还是应该通过存储过程路由以提高性能？
我认为主要的一点是大多数好的解决方案都会有一个适度。
【讨论】：
一般来说，我让事情变得显而易见且易于使用。如果简洁/简短在这方面对我有用，那就更好了。简短的答案通常是最清楚的，所以简短是显而易见的副产品。
【讨论】：
对小代码足迹的需求是汇编语言和第一个稍微高级的语言时代的倒退……小代码足迹是真正迫切需要的地方。但是，这些天来，它并不是必需品。
也就是说，我讨厌冗长的代码。在我工作的地方，我们编写的代码尽可能像自然语言一样阅读，没有任何额外的语法或单词。我们不会缩写任何东西，除非它是一个非常常见的缩写。
Company.get_by_name("ABC")
makeHeaderTable()
和我们一样简洁。
【讨论】：
需要在简短的源代码和性能之间取得平衡。如果它是不错的源并且运行速度最快，那么很好，但对于不错的源，它像狗一样运行，那就糟糕了。
【讨论】：
没有明确的界限可以区分 glib 的代码和华丽的代码。用你最好的判断。让其他人查看您的代码，看看他们理解它的难易程度。但请记住，正确性是第一目标。
【讨论】：
您可以通过查看冗余并将其消除或通过聪明来使代码更小。做前者而不是后者。
【讨论】：
我试图达到某种程度的冗长，使我的程序语句读起来像任何程序员都能理解的句子。这确实意味着要对我的代码进行大量重构，使其成为故事的一小部分，因此每个动作都将在单独的方法中进行描述（更进一步的层次可能是另一个类）。
意思是我不会仅仅因为可以用更少的字符来减少我的字符数。这就是代码高尔夫比赛的目的。
【讨论】：
DoNothing()，它在空的else 语句中充当调试断点持有者。