代码应该简短/简洁吗？[关闭]

StackOverflow https://stackoverflow.com/questions/952194

  •  11-09-2019
  •  | 
  •  

题

在编写数学证明时，一个目标是继续压缩证明。证明变得更加优雅，但不一定更具可读性。压缩可以帮助您更好地理解，因为您可以删除不必要的字符和冗长的内容。

我经常听到开发人员说您应该使代码占用空间尽可能小。这很快就会产生不可读的代码。在数学中，这不是一个问题，因为练习纯粹是学术性的。然而，在时间就是金钱的生产代码中，让人们尝试弄清楚一些非常简洁的代码在做什么似乎没有多大意义。对于更详细的代码，您可以获得可读性并节省成本。

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

有帮助吗？

解决方案

我试图达到冗长的水平，我的程序语句读起来像一个句子的任何程序员可以理解。这确实意味着重重构我的代码，使得它的一个故事的所有短块，所以每一个动作将在一个单独的方法（甚至进一步的电平可能是另一个类）进行说明。

这意味着我不会降低我的字符数，只是因为它可以用更少的表达。这就是代号高尔夫球比赛是。

其他提示

我的规则的说你是什么意思的。我看到人们出错的常用方法是“减量化的力量。”基本上，他们取代他们的东西，似乎跳过步骤思维的概念。遗憾的是，他们离开概念出的自己的代码，使得它更难阅读。

例如，改变结果

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

到

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

是一个强度降低，这似乎保存步骤的一个例子，但它留下了一个事实，即foo是一个数组，使得它更难阅读。

另一种常见的一种是使用布尔代替枚举的。

enum {
    MouseDown,
    MouseUp
};

有了这个是

bool IsMouseDown;

遗漏了一个事实，即这是一个状态机，使得代码难以维护。

所以我的经验法则是，在您的实现，不挖下来比你试图表达的概念较低水平。

可以使代码通过观看冗余和消除它更小，或通过被巧妙。做前者而非后者。

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

我认为简短/简洁是编写良好的代码的两个结果。使代码变得优秀有很多方面，并且编写良好的代码会产生很多结果，认识到两者是不同的。您不打算占用较小的足迹，您计划的是一个简洁的函数，并且可以很好地完成单一任务 - 这应该会导致占用空间较小（但可能不会）。以下是我在编写代码时要关注的简短列表：

  • 单一功能 - 一个功能应该只做一件事，交付简单，多功能功能有缺陷且不易重用
  • 松散耦合 - 不要从一个函数内部触及全局数据，也不要严重依赖其他函数
  • 精确命名 - 使用有意义的精确变量名称，神秘的名称就是这样
  • 保持代码简单而不复杂 - 不要过度使用特定于语言的技术哇，有利于给别人留下深刻的印象，难以轻松理解和维护 - 如果你确实添加了一些“特殊”的评论，这样至少人们可以在咒骂之前欣赏它你出去
  • 均匀评论 - 很多评论会被忽略并且过时，少数评论没有意义
  • 格式化 - 对代码的外观感到自豪，正确缩进的代码会有所帮助
  • 以代码维护人员的心态工作 - 想想维护您正在编写的代码会是什么样子
  • 一定要害怕或懒于重构——第一次没有什么是完美的，清理你自己的烂摊子

要找到一个平衡点的一种方式是寻求可读性而非简洁的烦躁。程序员不断扫描代码视觉上看到的是正在做什么，所以代码应该尽可能地流动很好。

如果程序员扫描条形码，并打一节，是很难理解，或需要一些努力的进行分析和理解，这是一件坏事。使用普通公知的构建体是重要的，从模糊和不经常使用的，除非必要的。

远离

人类不是编译器。编译器可以吃的东西，并继续前进。晦涩代码不精神上人类消费尽可能快地清楚地理解代码。

有时，它是很难在一个复杂的算法来生成可读的代码，但在大多数情况下，人的可读性，我们应该寻找什么，而不是小聪明。我不认为的码长是真的清晰度的量度或者，因为有时一个更详细的方法比的简明方法更可读的，有时一个简明的方法是比长一个更具有可读性。

此外，意见只能补充，而不应描述你的代码，你的代码应该说明自己。如果你有发表意见的线，因为它并不清楚做，这是不好的。它需要更长的时间最有经验的程序员比它读取的代码本身阅读英文解释。我觉得这本书代码完成锤子这个家。

至于对象名称去，在这个思维已经通过引进新的编程语言演变了。

如果您乘坐“大括号”的语言，开始与C，简洁被认为是智慧的灵魂。所以，你将有一个变量来保存名为“LV”贷款值，例如。当时的想法是，你是输入大量的代码，所以保持按键到最低限度。

然后出现了微软认可的“匈牙利表示法”，其中的变量名称的第一个字母被意在指示其基础类型。一个可能使用“flv”和一些这样，以指示该贷款值通过浮法变量表示。

使用的Java，然后C＃，范式已经成为清晰度之一。贷款值变量一个好名字将是“loanValue”。我相信这样做的部分原因是在最现代的编辑命令完成功能。由于其不需要键入整个名字了，你可能会因为需要为描述性的，以及使用尽可能多的字符。

这是一个很好的趋势。代码需要理解。评论往往添加作为一种事后，如果在所有。他们还没有更新代码进行更新，使他们成为过时。描述性， 精心挑选的，变量名是为了让其他人知道你是编码关于第一，最好的和最简单的方法。

我的计算机科学教授谁说：“作为工程师，我们正在不断地创造，以前从未存在过的东西种类。我们给他们会坚持的名称，所以我们应该仔细的名字的东西 有意义 即可。“

有需要是短甜源代码和性能之间的平衡。如果是很好的来源，运行速度最快，那么好，但好的源起见，运行像狗，再不济。

努力重构直到代码本身读取良好。你会发现自己的错误的过程中，该代码会更容易神交为“未来的家伙”，你会不会维持（后来忘记更改）在什么你已经表示意见所累代码。

当失败了......当然，给我留下了评论。

和不告诉我在评论“是什么”（这是代码是什么），告诉我“为什么”。

与之相对长/散漫？当然！

但它可以让到它是如此短，因此简洁，很难理解这一点，那么你走得太远了。

是。总是

DRY 的：不要重复自己。这会给你一个代码，既简洁又安全。编写相同的代码几次是一个很好的方法，使之难以维持。

现在，这并不意味着你应该寻找远程的一致好评代码的任何块的功能。

例如一个非常常见的错误（恐怖？）的因式分解代码做近同样的事情，并且通过把一个标志添加到功能API来处理OCCURENCES之间的差异。这可看inocuous在第一，但产生硬代码流理解和错误易发生，甚至难以重构。

如果你遵循共同的规则重构（细算一下代码异味），你的代码将变得越来越简洁的副作用尽可能多的代码气味是关于检测冗余。

在另一方面，如果试图使代码尽可能短不遵循任何meaningfull准则，在某些时候，你将不得不停止，因为你是不会看到任何更多如何减少代码。

如果只是第一步就是去除所有无用空格想象......在大多数编程语言这一步代码之后会变得如此难以阅读，你不会有太多机会找到任何其他可能的增强。

上面的例子是相当歪曲，却远没有那么从你得到了什么努力，以优化尺寸时，没有遵循任何明智的方针。

有可以得出代码是油嘴和代码，如花区分没有确切的行。使用您的最佳判断。有别人看你的代码，看看他们如何能够很容易地理解它。但要记住，正确性是数字1的目标。

在需要小码的脚印是从汇编语言和第一微小高级语言...有小码的脚印，其中一个现实而紧迫的需要的天倒退。虽然这些天来，它与其说是一种必然的。

这就是说，我讨厌冗长的代码。我在哪里工作，我们编写的代码读取尽可能像一个天然的语言，没有任何额外的语法和单词。而且我们不要缩写任何东西，除非它是一个很常见的缩写。 

Company.get_by_name("ABC") 
makeHeaderTable()

大约是简洁，因为我们去。

在一般情况下，我做的事情很明显和易于使用。如果简洁/急促供应我这一目的，就更好了。常短的答案是清亮的，所以是急促的明显的副产物。

我认为有几点可以决定何时停止优化：

  • 值得花时间进行优化。如果有人花费数周时间却一无所获，是否可以更好地利用这些资源？

  • 优化优先级的顺序是什么。当涉及到代码时，人们可能会关心几个不同的因素：执行时间、执行空间（包括运行的代码和编译后的代码）、可扩展性、稳定性、实现了多少功能等。其中一部分是时间和空间的权衡，但也可能是某些代码的去向，例如中间件可以执行即席 SQL 命令还是应该通过存储过程路由这些命令以提高性能？

我认为主要的一点是有一个 适度 大多数好的解决方案都会有。

在代码优化有一点做的编码风格。您格式化与被unsually被编译器忽略白色字符的代码 - 该文件包含X空格或新行不到一开始并没有变得更好或更快，在执行阶段，至少事实。它甚至使代码更糟糕，因为它变得不可读的其他程序员和自己。

这是更重要的是，代码变短和清洁在其逻辑结构，诸如测试条件，控制流，假设，错误处理或整体编程接口。当然，我也想在这里包括智能和有用的意见+文档。

有不一定简洁的代码和性能之间的相关性。这是一个神话。在像C语言成熟/ C ++编译器能够非常有效地优化代码。有原因需要在这些语言的假设，更简洁的代码是性能更好的代码。像Ruby比较新的，性能优化的语言缺乏C / C ++编译器编译器的优化功能，但仍然没有理由相信，简洁的代码是更好的执行。现实情况是，我们永远不知道，直到进入生产和被异形以及代码将如何在生产环境中执行。简单，无毒，功能可以是巨大的性能瓶颈，如果从代码中足够的地方调用。在高并发系统的最大瓶颈通常是由差并发算法或过度锁定引起的。这些问题已通过写作“简洁”的代码几乎解决了。

底线是这样的：代码即表现不佳总是可以一次分析确定其是瓶颈重构。代码只能如果它是很容易理解得到有效重构。被写入为“简洁”或“聪明”的代码通常是更加难以重构和维护。

写您的易读性代码，然后重构性能必要时。

我的两个美分...

<强>代码要短，混凝土，并浓缩。你总是可以解释很多的话你的想法在注释

您可以让你的代码作为短期或紧凑，你喜欢，只要你对此有何评论它。这样，你的代码可以优化，但仍然让SENCE。我倾向于用描述性的变量和方法，并sparce意见停留在中间的某个地方，如果它仍不清楚。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top