天天看点

Java编码约定被认为是有害的

在Oracle网站上有Java编程语言指南的正式代码约定 。 您可能希望这份超过20页的文档将是有关Java语言的最佳实践,提示和技巧的最完整,最全面和最权威的来源。 但是一旦你开始阅读它,失望和愤怒就会增加。 我想指出本指南中最明显的错误,不良做法,不良和过时的建议。 如果您是Java的初学者,只需不用学习本教程,而是寻找更好,最新的参考资料。 让恐怖开始吧! 2.2通用文件名 :

GNUmakefile

生成文件的首选名称。 我们使用

gnumake

来构建我们的软件。

gnumake

建立Java项目? 蚂蚁被认为是老派, 行家也被认为是老派。 谁使用

make

来构建WAR,JAR,生成JavaDoc ...? 3.1.1开头注释 : 所有源文件都应以c样式注释开头,该注释列出了类名称,版本信息,日期和版权声明:将类名称放入注释中以开始文件吗? 如果我改变主意并稍后重命名课程怎么办? 那“ 日期 ”应该代表什么? 有人使用各种占位符通过版本控制系统自动插入文件的最后修改时间。 好吧,VCS可以告诉您文件的创建时间或最后修改时间-一次又一次地修改同一行会使合并变得非常痛苦。 4 –缩进 : 应使用四个空格作为缩进单位。 缩进的确切结构(空格与制表符)未指定。 制表符必须每8个空格(而不是4个)正确设置。 可能是文档中最违反直觉的部分。 有些人喜欢空格,其他人(包括我)则喜欢制表符。 品味和团队安排有关。 但是本指南建议同时使用两者,有时用制表符替换空格。 是“ 未指定 ”。 我的建议:使用选项卡,让每个开发人员将其IDE配置为具有所需的大小凹痕。

4.1线长

避免使用超过80个字符的行,因为许多终端和工具无法很好地处理它们。

80个字符? 我的笔记本电脑可以轻松容纳三倍。 在一行中争取使用120-140个字符,但不要使用硬包装。 我个人只是显示垂直边距,

右行的长度由可读性决定。 顺便说一句,以下是来自各种库和框架的类的几个示例:

  • SQLIntegrityConstraintViolationException

    (JDK

    SQLIntegrityConstraintViolationException

    个字符)
  • AbstractInterruptibleBatchPreparedStatementSetter

    (Spring框架,50个字符)
  • AbstractDataSourceBasedMultiTenantConnectionProviderImpl

    (休眠,56个字符)
  • PreAuthenticatedGrantedAuthoritiesWebAuthenticationDetails

    (Spring Security,58个字符)

而且我们假设整行可以容纳80个字符吗?

5.1.2单行注释 :

if (condition) {

    /* Handle the condition. */
    ...
}
           

以防万一代码不够自我描述,我建议使用更好的注释:

if (condition) {

    /* This block is executed if condition == true. */
    ...
}
           

5.1.3尾随评论 :

if (a == 2) {
    return TRUE;            /* special case */
} else {
    return isPrime(a);      /* works only for odd a */
}
           

您的意思是(并且即使没有评论也不要告诉我它的可读性较差)?

return a == 2 || isPrime(a);
           

6.1每行编号 :

int level; // indentation level
int size;  // size of table
           

当我们有注释时,为什么要使用描述性变量名! 考虑一下这个:

int indentationLevel;
int tableSize;
           

在该部分的后面: 绝对不要在同一行上声明变量和函数。 例:

long dbaddr, getDbaddr(); // WRONG!
           

当然,这是错误的,甚至无法编译。 我很惊讶没有提到“ 不要在变量名中放置空格 ”是一种好习惯……

6.3放置 :

仅在块的开头放置声明。 […]不要等到第一次使用变量时才声明它; 它会使混乱的程序员感到困惑[…]这是编码约定希望您编写代码的方式:

int min;            //inclusive
int max;            //exclusive
int distance;
List<String> list;  //one per each item

min = findMin();
max = findMax();
distance = max - min;
list = new ArrayList<>(distance);
//...
           

这是应如何编写以避免混淆:

final int minInclusive = findMin();
final int maxExclusive = findMax();
final int distance = maxExclusive - minInclusive;
final List<String> listOfItems = new ArrayList<>(distance);
//...
           

除此之外,我们最终可以(使用nomen est omen )使用

final

关键字。 本节后面的代码示例显示了类字段缺少

private

修饰符(默认为包私有访问)的情况。 包私人领域?

7.3返回声明 :

return (size ? size : defaultSize);
           

也许您没有注意到,但是从上下文中我们可以看出

size

defaultSize

都是

boolean

类型。 没错,

size

defaultSize

可以为

true

false

(!)这是违反直觉的! 从这样的文档中,我不仅期望句法正确性,而且期望有意义的代码和良好实践! 此外,表达可大大简化, 一步一步 :

size ? size : defaultSize
size ? true : defaultSize
size || defaultSize
           

7.5声明 :

空的

for

语句(其中所有工作都在初始化,条件和更新子句中完成)应具有以下形式:

for (initialization; condition; update);
           

'

for

语句 '? 为什么要使用空的

for

语句? 这是令人困惑的 ,应避免,不应在官方语言指南中予以鼓励和描述。

奖励测验:此代码在C语言中的用途是什么?

while(*dst++ = *src++);
           

我相信每个计算机程序员都应该理解上面的代码片段。 即使您使用Ruby或TSQL进行编程。

7.8 switch语句 :

每次遇到

case

(不包括

break

语句)时,请在

break

语句通常所在的位置添加注释。

我了解意图,但做法是错误的。 不要记录意外的和容易出错的代码片段,而要避免它们。 不要依赖失败,根本不要使用它。

8.1空行 :

在以下情况下,应始终使用一个空白行:

[…]

  • 在方法的局部变量及其第一条语句之间
  • 在块[…]或单行[…]注释之前
  • 一种方法内部的逻辑部分之间,以提高可读性

看来作者建议使用空行来分隔“ 方法的逻辑部分 ”。 好吧,我称这些部分为“ 方法 ”。 不要将语句分组在方法内部的块中,对其进行注释或彼此分开。 而是将它们提取到单独的,命名良好的方法中!

在变量声明和第一个语句之间放置空白行听起来像是从C语言书中摘录的。

8.2空格 :

  • 除以外的所有二进制运算符

    .

    应该用空格将其操作数分隔开。 空格绝对不能将一元运算符(例如一元减号,增量('

    ++

    ')和减量('

    --

    '))与其操作数分开。 例:

[…]

while (d++ = s++) {
  n++;
}
           

这甚至无法在Java中进行编译 …

9 –命名约定 (仅PDF版本 ):

char *cp;
           

cp

是Java中

char

指针的一个好名字。 等等, 什么 ? Java中的

char

指针 ?

10.1提供对实例和类变量的访问 :

没有充分的理由就不要公开任何实例或类变量。 真的, 真的是很好的理由! 我曾经使用过

public

场所吗?

10.4变量赋值 :

if (c++ = d++) {        // AVOID! (Java disallows)
    ...
}
           

极好的建议:请避免使用甚至无法在Java中编译的构造。 这使我们的生活变得更加轻松!

10.5.2返回值 :

if (booleanExpression) {
    return true;
} else {
    return false;
}
           

应该改为

return booleanExpression;
           

圣牛, 我同意!

摘要

并不是Java编程语言的官方代码约定是完全错误的。 它们只是过时和过时的。 在二十一世纪的第二个十年中,我们拥有了更好的硬件,对代码质量的更深刻理解以及更现代的智慧资源 。 代码约定…上一次发布是在1999年,它们受到C语言的极大启发,没有意识到数以百万计的开发人员尚未编写的代码行。 就像设计模式一样,代码约定应该随着时间的流逝而出现,而不是明确给出。 因此,请不要再引用或遵循官方指南的建议。

参考: Java 和社区博客上的JCG合作伙伴 Tomasz Nurkiewicz 认为Java编码约定有害 。

翻译自: https://www.javacodegeeks.com/2012/10/java-coding-conventions-considered-harmful.html