为什么冗长对编程语言不利？ [关闭]

#1 楼

目标是快速理解

“详细”的意思是“使用太多单词”。问题是什么“太多”。

好的代码应该一目了然。如果大多数字符直接用作代码的目的，这会更容易。

信号与噪声

如果语言是冗长的，则更多的代码就是噪声。比较Java的“ Hello World”：

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

”

print "Hello World!"

隐秘vs清晰

另一方面，语言过于简洁也会消耗精神能量。比较Common Lisp中的以下两个示例：

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

评论

---

我要说的是后者是关于微观级别的可读性（我们通常更喜欢冗长的表示法），而前者则是关于宏观级别的可读性（我们通常更简洁）

– jk。
2012年3月23日13:52

---

对于实际上执行某项操作的任何程序，Java常常具有更高的可读性，尤其是在良好的库使用情况下。

–user1249
2012年3月23日14:38在

---

实际上，宏详细程度的更好示例可能是围绕缺少语言功能的模式

– jk。
2012年3月23日14:42

---

我要说的Java例子也不是最好的例子。诸如定义类和方法之类的事情在代码高尔夫中很重要，但在实际应用中却很少。它不像Java需要大量代码来输出几个单词，这几行是创建程序所必需的，这是不同的。

–马尔科姆
2012年3月23日的15:00

---

+1区分信号与噪声以及隐蔽与清晰

–说话
2012年3月23日15:48

---

#2 楼

一眼就能看到和解析多少代码

x++而不是set(x,Integeradd(get(x),1))

评论

---

我相信这是最终原因。在有限的空间（如纸或监视器）上的可读性。

–user1249
2012年3月23日14:37

---

+1，并且完全同意，我使用一台13英寸的笔记本电脑进行编码，但随后此站点再次将3台显示器作为其徽标...必须有点相关:)

– ZJR
2012年3月23日14:45

---

@ZJR-参见编辑。

–马丁·贝克特（Martin Beckett）
2012年3月23日14:48在

---

那么set方法在这里做什么？它实际上是设置了某些内容（即第一个x参数）还是返回了某些内容（即调用后对x的赋值）？我要说的是，在冗长的示例中发生了一些奇怪的重复。

– Jesse C. Slicer
2012年3月23日15:08

---

这里缺少的一件事是表意文字的实用性-符号可能比文字更有意义。例如。 +比加号更有意义。 =优于平等。这当然可以走得太远（并且已经被多种语言使用），但是当适度使用时，它非常强大。

–mcmcc
2012年3月23日18:56

---

#3 楼

如果语言的冗长性损害了代码的可读性，那就不好了。 br />

If something Then
End If

if(something)
{}

它可以归结为程序员所熟悉和熟悉的东西。

#4 楼

看一下AppleScript，我认为它是目前最冗长的语言之一，可以认为它是最新的，尝试在其中编写一些琐碎的东西，然后回来并争辩说冗长性是该语言的一个很好的特征。

如果您每天都不做的话，尝试记住关键字去向及其含义的所有语义都是很重要的。

只看这个小例子中的所有关键字噪声：

 tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell
 

在bash中使用传统的Unix工具授予相同的内容将是简洁的，但对于大多数OSX用户而言却是神秘的，因此必须取得平衡。

#5 楼

我认为您需要首先提出一个问题，然后问：为什么有些人认为简洁的代码很好？

我的回答是，有两个基本原因：

原因为何简洁可以变得更好

其中包括更具可读性，就像使短句子比繁琐冗长的句子更易于理解。通常，试图模仿英语语法的编程语言最终会费时费力，需要大量的代码才能执行最简单的操作。通常，您会发现一种语言对一种书面语言的模仿程度越高，那么就越难以哄骗该语言执行逻辑上复杂的操作。

原因为何精简可能更糟

某些语言（我正在考虑Perl）使用了一系列奇怪的符号（它们似乎几乎是任意选择的）作为其语法的一部分。对于不熟悉这些象形文字的任何人，该语言将变得难以理解。犯下不容易发现的错字错误也变得容易。正则表达式也许可以概括这种简洁性。

此外，有些人喜欢通过编写简洁的代码来炫耀，因为坦率地说，他们认为这使它们看起来很聪明。您有时会在StackOverflow上看到这一点，人们通常会以非常易读的方式提交非常紧凑的答案。这是一种“使您的同伴印象深刻”的知识，但是优秀的程序员意识到“编码高尔夫”并不是创建可维护软件的方法。

#6 楼

@frowing，我建议研究冗长性问题的一种方法是认识到编程始终是找到和表达解决方案的两种截然不同的样式的某种组合。

第一种也是更冗长的样式是面向语言的（语言）编程。这种风格在句子结构中结合了类名词词和动词类词，旨在以与编写良好段落相同的方式阅读和理解。语言编程是最通用的编程风格，因为语言本身是通用的。出于同样的原因，长期的程序支持始终需要强大的语言组件，因为新程序员首先要寻找的是对正在做的事情的概念性理解。通常，离您创建程序的环境越远，语言的编程风格就越重要，这是为了确保下一个试图理解您的代码的人不会误解您的假设和概念。 。您自己的示例，该示例使用一种更加语言化的编程风格来减少API中的歧义，这就是该原理的一个很好的例子。

第二种更简洁的样式是面向数学的（数学）编程。这种推理方式也依赖于语言，因为例如变量类似于名词，而运算符类似于动词。但是，数学推理可以利用我们的大脑惊人且高度并行的能力对视线范围内的对象进行复杂的空间转换。通过将名词和动词表示为紧凑，独特的符号，可以将它们安排在结构良好的虚构对象（方程式）中，然后我们可以使用高度平行的视觉功能对这些虚构对象进行旋转，替换，移动，倒置和其他转换对象。结果是极大地放大了我们一次可以处理的案例数量，因为每个符号都可以代表紧密相关的对象的整个类别。

请注意，要有效地进行视觉处理，您需要使假想物体的尺寸和特征与真实物体尽可能相似。如果所需的视野太宽，或者不能像在对象上使用可移动标记那样使用符号，或者必须“阅读字母”并将其转换为单词，则可靠地执行复杂转换的能力将下降即使对于一个非常出色的数学家来说，也很快。风格。这不是因为等式已经发生了很大的变化，而是因为这样展开它几乎可以使视觉理解方式几乎不可能。但是，与此同时，完全不熟悉短符号的新程序员可能会更喜欢冗长的版本，该版本提供更多的语言信息，以初步了解代码的作用。

那又是什么呢？我会推荐吗？

使用这两种样式，但请注意使用每种样式的原因。
例如，任何有可能与外界交互的东西都应在某种程度上强化冗长，即使仅在内联注释的形式与代码混合，并且还应包括自动检查是否正确使用。隐秘的，尤其是定义不完整的符号在这种界面上毫无用处，因为几乎可以肯定它们在某些时候会被误解。由于无法识别软件接口单位是以磅还是牛顿表示的1999年火星气候观测器的损失，这是一个特别明显的例子，说明过分依赖软件或硬件接口上的原始数字是很危险的。
<相反，本质上具有深厚算法和数学意义的任何形式的编程，都是支持数学推理方式的一种很好的简洁编程。如果新手必须维护这样的代码，通常对他们而言，学习数学符号而不是尝试将代码转换为更冗长的形式会更好。当然，在任何时候都应该有容易获得的文档来解释这些开发人员可以使用的数学部分，但这是一个单独的问题。

在这两种极端情况下，程序员拥有相当多的能力谨慎。我建议您看一下如何长期维护代码，并设法满足最有可能长期维护代码的人们的需求。

#7 楼

许多人暗示了我认为应该明确陈述的内容。

详尽度倾向于在微观层次上进行理解-它通常导致单个陈述易于阅读和理解。详细程度还倾向于降低对理解它所必需的语言的熟悉程度（至少在某种程度上）。即使是完全的非程序员，最冗长的语言（例如COBOL）也至少可以阅读。

趋向于相反：它有助于从宏观的角度理解，尤其是对于那些掌握最多语言的程序员而言熟悉该特定语言。同时，对特定语言的不熟悉甚至会阻止甚至是初级的理解，即使对于本来非常有经验的程序员也是如此。

因此，可读性在很大程度上取决于目标受众。一方面，考虑一个由几乎专门从事该项目工作的人编写和维护的大型复杂项目，其中大多数人具有丰富的编程背景和受过教育（例如，许多博士学位）。

在相反的极端情况下，考虑一个相当简单（尽管可能仍然很大）的项目，该项目主要由真正专注于业务的人员维护与软件相关联，而不是与软件本身相关联。这几乎肯定会支持更冗长的语言。

#8 楼

我不再阅读技术书籍，而是使用Strunk和White撰写的Styles *。基本概念是“精确”和“不要说太多”。其他所有内容都是注释。

适用于编程，它的意思是非常精确，但是没有不必要的绒毛。多余的绒毛可以是语法，但也可能比传达含义所需的单词更多。 （当然也不要太过歧义）


我引用了原始版本，因为它是最简洁的。 :-)

#9 楼

归根结底，任何“不同”的事物都会引起人们的how叫。我对C样式的语法很满意，因此可以与其他共享类似语法的语言（C ++，Java，C＃）一起使用。因此，我倾向于偏向于这种特殊样式。

Perl是一个示例，您可以在其中编写非常简洁的代码。对于初学者来说，Perl忍者编写的代码简直就是魔术。

COBOL就是一个太冗长的例子。

#10 楼

我曾经在某处读到过，大量的冗长争论来自于新程序员与老手。使用的类比是，当我们学习新东西时，我们会告诉自己一个“故事”来通过它（想想您何时在HS中学习代数）。随着经验的积累，我们不再需要一个故事来解释各个组成部分，而是获得了更多的理解。我们的代码变得更紧凑，更简洁，注释仅解释了必要的内容，而不是重复代码的内容。

我发现我和同事之间是对的。她编写的代码带有很多注释，这些注释解释了代码行以及大量的空白。因此，如果我正在阅读它，我发现我只能在一个屏幕上放几行代码。这使理解每一行变得容易得多，但是使整个函数变得困难得多。

我倾向于编写没有多余空格或注释的代码。这使得查看整个过程变得容易得多，但是您必须能够简单地“获取”单个代码“ words”。如果您试图在每个单词都单独出现的情况下阅读此答案，并且有很多空格/注释/多余的单词，那么理解每个单词会容易得多，但要理解整个单词就困难得多。

#11 楼

爱因斯坦说对了：“使事情尽可能简单，但不要简单。”

这同样适用于代码。如果您可以通过删除重复的和不必要的冗长元素来简化代码，那是一件好事。

另外，一些案例研究表明，以代码行衡量的程序员生产力或多或少是一个常数。每个LOC的错误数量也是如此。因此，如果其他所有条件保持不变，则切换为允许您在每行代码中执行更多操作的语言可以认为是生产率的提高。

话虽如此，该行业中有一种趋势可能会设计并使简单的事物复杂化。在关系数据库中填充联系人详细信息等简单的事情。我已经看到了针对该特定问题的一些可笑的复杂和误导性的解决方案（咳嗽MDA）。诸如Scala和Ruby之类的语言就是功能强大的工具的典范，这些工具在某些人的手中会导致难以理解，过于复杂且难以维护的代码。仅仅因为您可以通过几次按键操作就可以使用多个间接级别，但这并不意味着您必须用那个特殊的锤子敲打每个钉子。

如果使用得当，您将获得漂亮的干净代码，即简短易懂。如果使用不当，则最好将相关人员限制在使用视觉基本语言或类似限制的语言中，以防止进一步的损害。

真正的技巧在于以简单的方式制作复杂的东西，而不是简单的事情，以复杂的方式。

#12 楼

没有人碰到的东西就是您可以在一个屏幕中容纳的代码量。这样做有几个原因：


在一个文件中处理（或读取）多个功能时，来回滚动较少。
水平滚动（停止读取，单击并拖动滚动条，停止阅读，单击并拖动滚动条...）。
快速扫描，因为没有太多没用的语法阻碍了查找所需内容。

#13 楼

因为更多的代码意味着更多的开发时间和更多的错误。

如果您编写100行代码而不是300行代码。这意味着您需要近1/3的开发时间，而您可能会遇到1/3的潜在错误。

在大多数情况下，您需要平衡效率和简洁性，因为编写更少的代码意味着机器需要做更多的事情会降低效率。

#14 楼

通常，人们喜欢可读/冗长的语言，而不喜欢神秘/简短的语言。但是，我认为大多数人将“冗长”与“混乱”混为一谈。这不是同一回事。例如：while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

是一个非常简洁的陈述。它包含您想知道的一切。但是，由于它的简洁性，所以很难理解。另一方面，同一程序的稍微冗长的版本将很容易理解，因为它更具可读性。当然，这不是语言本身的特性，但是某些语言在编程方式上趋向于冗长，而另一些语言在编程方式上趋于简洁。

对于另一个极端，是http ：//en.wikipedia.org/wiki/Literate_programming
，我认为这是一个非常有趣的概念。

另一个方面是“不必要的冗长”，也称为“混乱”。出于技术原因，缺乏语法功能，API膨胀等原因必须添加的内容。

我认为清晰直观的语法非常重要。它也必须足够冗长以便于阅读。包含太多逻辑的简短语句通常会导致比其他稍长的语句花费更多的时间来解密。另一方面，满是样板行的无用的肿代码根本无法完成某些工作。

#15 楼

详细程度是倾向于使用大量文本的趋势，而简洁则是使用很少的文本...

详细程度不好是因为：


它引入了更多内容出现印刷错误的机会
，这使得在屏幕或纸张上阅读代码和/或在打孔卡上输入代码变得更加困难

这增加了调试时间
这使理解代码的升级/较难维护
，这可能导致意外的代码重复


它增加了语法错误的可能性
它降低了编码的灵活性，因为大多数冗长的语言都是结构化，没有多种方式表达同一件事。
它增加了编码和编译时间
会占用更多的存储空间。

一定程度的冗长是必不可少的为了清楚起见，但是...

最小程度的Verbosity是好的，因为：


人类比单纯地阅读和附加语义值要容易得多符号代码
在v中变量和函数命名，可以更轻松地调试，移植和维护基本语言操作和复杂语言的关键字中的代码，从而减少错误的操作/关键字分配。

对于许多人来说，过于简洁的命令的一些奇妙示例包括val(x$)，str$(x)和chr$(x)的旧BASIC备用代码...从其字符串表示形式返回数字，返回数字的字符串，并返回具有ascii值x的单个字符

C / C ++指针，以及引用运算符&和*与BASIC byref的比较。在C / C ++中，我可以有一个变量X，并传递一个指向该变量的指针，但是我必须记住，哪个是指针，哪个是“使用指针作为它所指向的变量”。从根本上讲，我只是在函数调用中使用byref关键字传递引用，这更加清晰，但灵活性较差：

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

在此代码中，x的内容由于byref标志而被修改。

冗长性对于临时程序员能够更轻松地使用符号意义很重要；与C / C ++相比，BASIC或python更具人类可读性和冗长性，因此对于休闲程序员而言更有用。 C / C ++的简洁性使其对于经验丰富的程序员来说要好得多，他们需要一次查看更多的代码和更复杂的代码，但必须学习各种符号结构约定。远端是APL，几乎完全是人类无法理解的。熟悉给定语言会提高该语言中简洁代码的清晰度-面对C ++代码的原始初学者很可能只能解析公式，即使功能丰富的BASIC或Python代码也太简洁而无法理解，但是applescript可以通常，不使用语言词典就会感到困惑。我在没有故意混淆的情况下遇到的最不清楚的问题是Inform 7 ...

在过去，

过去的另一个重要考虑因素是，但不再是对于业余编码员而言，重要的是操作和存储空间。 （它在高端仍然很重要。）请记住，许多语言都被解释了，尤其是BASIC风格，并且有更多种语言在运行时进行了编译，代码空间非常重要，尤其是当磁盘仅容纳128KiB且单个穿孔卡仅80B时。

存在几种解决方案-令牌化在BASIC中极为普遍；单个语言关键字在高位128或控制字符空间中被减少为1或2字节的单词。令牌化还导致字节码编译（如Inform和Z-Machine中一样）。

多目标文件的编译和链接也用于解决空间限制。 100KiB Pascal代码段可能仅编译为5KiB；通过链接多个编译文件，人们可以在无需访问大型驱动器的情况下构建大型应用程序（记住10MiB是如此之大，并且购买昂贵的新车）。

更多的简洁语言得到了更多将代码编码到磁盘和ram的给定块中，从而一次编译更大的块。请记住：1970年代初期的“微型计算机”可能只有64KiB的ram（Honeywell 800的基本安装为4个存储库，每个存储库为2048个字，每个8B）。 APL和类似的符号语言每条指令加上它的操作数接近1B，而每条指令加上操作数的3B-10B要大得多。 （在打孔卡上键入文字是一场噩梦，特别是因为符号本质上是打字球上的字体，并且许多卡片打孔键上都没有符号...）

请记住，无法删除卡...并且在卡上输入了许多程序。尽管并不是很昂贵，但是代码在卡上的压缩程度越高，所需的代码就越少，程序可能就越大，或者价格越便宜。这是BASIC在大多数情况下每行具有多条指令串联的部分原因-引入它是为了节省打孔卡。 （或者说我的Vax Basic编程文本这样说。）虽然我没有为读卡器进行编程，但是我已经用FORTRAN，BASIC，APL和其他几种高度象征性的语言对Honeywell 800进行了打卡。

#16 楼

就像很多事情一样，答案取决于“详细程度”的具体定义。如果定义是冗长意味着多余，那么我会认为它总是不好的。请注意，使用这样的定义，经常引用的Java hello world程序将不符合“冗长”的条件，因为其中没有多余的内容。

#17 楼

程序员倾向于喜欢具有表达能力的语言，因为它允许他们用小段代码编写简单的事情，而这些事情通常必须经常执行。详细的语言往往意味着必须使用许多行代码来一遍又一遍地完成相同的事情。
但是，表达性语言可能要付出一定的代价，因为它们不一定可以像执行更简单的高级语言一样快地执行。
如果我可以举一个C和C ++的对比示例。 C ++为代码编写者提供了更具表达力的功能-他们可以将现实世界对象的思想封装在类中。 C程序员可以实现相同的目的，但是他们确实具有类构造的表达能力来帮助他们-因此，他们通常不得不编写更长，更复杂（以便理解）的代码。但是该代码可能运行得更快（尽管这在很大程度上取决于编译器的质量等等），因为它不使用C ++的“后期绑定”（即运行时重构）来执行代码。 C只是执行编译和链接的代码，C ++必须在运行时（在某些情况下）决定要执行哪些代码。

#18 楼

我认为，这个问题的答案根源于比可读性更根本的理论问题，而且这个答案与格雷戈里·柴廷（Gregory Chaitin）建立的算法信息论有关：
http://en.wikipedia.org/wiki / Algorithmic_information_theory。简而言之，“字符串的信息内容等于该字符串的尽可能短的自包含表示形式的长度”，这意味着最短的程序（即按照其词典长度）可以紧密解决给定问题匹配解决方案所要解决的问题的内在复杂性，因此，它更多地取决于问题的性质而不是问题的表示形式。