冗长的优点和表现力的缺点

Java太冗长了！ 谁没有以前在互联网上偶然发现过这样的声音？ 那个吹嘘[在那儿插入表达语言]的人很快就取代了Java，因为它更加简洁：它可以用一行代码代替那10行Java代码。 啊，力量！

不幸的是，为了使简洁与权力（以及冗长与缺乏权力）相关联，这些人采取了许多捷径，一旦把它们放到视野中，便毫无意义。 本文旨在通过外科方式解构此类捷径以暴露其弱点。 并且由于我喜欢事实辩论，并且不仅在互联网上有巨魔，所以这篇文章将与安迪·佩特雷拉（Andy Petrella）的不同观点相关联。

详细还不错

拥有比必要更多的数据可以防止由于间接通信而导致的消息损坏。 这是两个简单但准确的示例：

• 在网络工程中，有一个DBIt或交付确认位的概念。 它只是当前序列的所有0或1的摘要，即使网络质量不够高，也可以确保已正确传输已传送的数据包。
• 在现实生活中，银行帐户具有2位数的控制键（至少在我所知道的大多数欧洲国家中）。 同样，这是为了避免将资金汇入错误的帐户。

对于“冗长”的语言来说完全相同。 它降低了理解错误的可能性。

更简洁不是（必要）更好

如果说单线好于10条线，则意味着短线好于10条线：可悲的是事实并非如此。

让我们采用Java中常见的代码结构：

publicList<Product>getValidProducts(List<Product>products){

    List<Product>validProducts=newArrayList<Product>();

    for(Productproduct:products){
        if(product.isValid()){
            validProducts.add(product);
        }
    }
    returnvalidProducts;
}

在这种情况下，我们有一个Product列表，并希望过滤掉无效的产品。

减少冗长的简单方法是将所有内容都设置在同一行上：

publicList<Product>getValidProducts(List<Product>products){List<Product>validProducts=newArrayList<Product>();
    for(Productproduct:products){if(product.isValid()){validProducts.add(product);}}returnvalidProducts;}

不够简洁？ 让我们重命名混淆样式的变量和方法：

publicList<Product>g(List<Product>s){List<Product>v=newArrayList<Product>();
    for(Productp:s){if(p.isValid()){v.add(p);}}returnv;}

我们极大地减少了代码的冗长性-我们将所有内容都编码在一行中！ 谁说Java太冗长？

表现力暗含

我以前已经在<a title =“隐式危险 ”中写过：那些相同的参数可以用于编程。

让我们重写之前的Java 8片段：

publicList<Product>getValidProducts(List<Product>products){
    returnproducts.stream().filter(p->p.isValid()).collect(Collectors.toList());
}

更加简洁和富有表现力。 但这需要您，我和每个人 （对不起，我无法抗拒）对API有所了解。 Scala运算符等也是如此。 这是我的老朋友的上下文：

• 地球上几乎每个人都知道+运算符
• 几乎每个软件开发人员都知道++运算符
• Elvis运算符可能是Groovy开发人员所熟知的，但是大多数程序员可以很容易地推断和记住Elvis运算符
• 虽然：/运算符（ aka foldLeft() ）需要Scala和FP知识

因此，从上到下，操作员需要越来越多的知识，从而减少了越来越多的人能够读取您的代码。

#Code的读取次数远多于其编写的次数： #readability的代码！

-尼古拉斯·弗兰克尔（Nicolas Frankel（我相信很长一段时间以来，@ Home）（@nicolas_frankel） 2013年9月2日

在编写要读取的代码时，可读性成为代码质量的主要因素。

因此， 您要解决的受众越多，代码应越冗长 。 是的，因为您将不会使用高级功能或完美的表达能力，所以经验丰富的开发人员可能会认为这只是普通的代码，您的技能也不会受到赞誉...但是自我并不是您编写代码的原因，对吗？

摘要

在这篇文章中，我试图证明， 少即是多并不适用于这些点编程：

• 详尽防止沟通失误
• 尽管编译器/解释器不需要空格和制表符，但它们确实提高了可读性
• 表现力要求您和您的读者分享一些共同的和隐含的理解

如果这篇文章使您认为冗长毕竟还算不错，我将感到满意。

现在是时候阅读Andy的帖子（如果您还没有，请自己决定）。

翻译自: https://blog.frankel.ch/on-the-merits-of-verbosity-and-the-flaws-of-expressiveness/