你试图让你的代码看起来漂亮吗？

Question

我可能是一名肛门程序员，但我喜欢从远处看起来不错的代码。 我刚刚发现自己正在排列一个 CSS 样式，而不是这样：

#divPreview {
    text-align: center;
    vertical-align: middle;
    border: #779 1px solid;
    overflow: auto;
    width: 210px;
    height: 128px;
    background-color: #fff"
}

它现在看起来像：

#divPreview {
    width: 210px;
    height: 128px;
    overflow: auto;
    text-align: center;
    vertical-align: middle;
    border: #779 1px solid;
    background-color: #fff";
}

我几乎总是按照大小顺序编写数字比较，就像

if (0 < n && n < 10)

而不是

if (0 < n && 10 > n)

最后我会倾向于安排 if-then-else 代码，以便THEN 部分比 ELSE 部分小（因为较重的东西会落到底部，对吗？）

if (afflicted == true) {
  GetSome();
  HelpRight();
}
else {
  NowPlease();
}

呃！

if (afflicted == false) {
  HowMuchTrouble();
}
else {
  IsItToDo();
  ThisReally();
}

啊啊，

我可以继续举更多的例子，但你明白了……

问题：我是唯一一个患有神经症的人吗？ 你的编码问题是什么？

Answer 1

根据我的经验，漂亮的代码通常运行得很好，而丑陋的代码通常会以难以发现的方式崩溃。 确实，那种关注细节（例如代码的外观）的头脑也是那种关注更重要的细节的头脑。

也就是说，以 CSS 样式重新排序元素，使它们从短到长是疯狂的。

Answer 2

肯定条件总是在 if-else 语句中首先出现。 美在于内在。

if (afflicted) {
    GetSome();
    HelpRight();
} else {
    NowPlease();
}

Answer 3

让代码看起来“好”很重要，这就是我们制定约定和风格指南的原因。 目的是使代码易于阅读并使错误的代码看起来错误。 我想说，这里的一些例子超出了这个范围，没有什么价值。

CSS 属性的顺序

#divPreview {
        width: 210px;
        height: 128px;
        overflow: auto;
        text-align: center;
        vertical-align: middle;
        border: #779 1px solid;
        background-color: #fff";
}

我发现保持属性顺序一致比确保它们按每个选择器的长度升序排列更有用。 这一惯例使您可以更轻松地找到所需的人。

条件语句的顺序

这里的示例对我来说很有意义，因为它清楚地表明 n 介于 0 和 10 之间。

if (0 < n && n < 10)

if/else 块的顺序

最后我会倾向于安排
if-then-else 代码，以便 THEN
部分小于 ELSE 部分
（因为较重的东西会流向
底部，对吧？）

我认为首先拥有积极条件（或更预期的条件）更有意义。 并且“== true”位是多余的。

if (afflicted) {
  GetSome();
  HelpRight();
}
else {
  NowPlease();
}

Answer 4

我可能会更进一步这样做：

#divPreview {
        width            : 210px;
        height           : 128px;
        overflow         : auto;
        text-align       : center;
        vertical-align   : middle;
        border           : #779 1px solid;
        background-color : #fff";
            }

Answer 5

应该

if (!afflicted)
{
    HowMuchTrouble();
}
else 
{
    IsItToDo();
    ThisReally();
}

买一台漂亮的打印机，并接受强迫症治疗;-)

Answer 6

我的看法有点不同。 代码的格式应该是为了可读性，而不一定是“漂亮”——尽管这两者通常可能是同一件事。

但作为一种反例，

if(x != null)
    y=x.getParam();
else
    y=0;

它比更漂亮的更具可读性：

y = x == null ? 0 : x.getParam();

我知道这一点是有争议的，我完全理解它，我喜欢那个运算符和所有的东西，但是对于 95% 的程序员来说（包括下一个阅读你的文章的程序员）代码）需要更多的时间来解析。

事实上，我什至在 ruby​​ 的优雅方面遇到了麻烦：

y = x.getParam() if x

仅仅是因为我习惯于通过扫描代码的左侧行来查看控制语句。

我不得不承认，当我看到这个语法时，我的膝盖有点发软（我认为它来自 hascal），

y = x?getParam();

这是一种优雅的程度，甚至可以压倒我厌倦的看法。

最后，虽然格式化对于在代码中显示模式确实很巧妙，但如果您的代码中甚至有模式，那么您可能做得不对。

每当您的代码中有模式时，请寻找重构机会。 尝试识别数据并将其取出，然后将模式的重复部分分解为某种消耗数据的循环。

顺便说一句，您的第一个示例是数据，而不是代码——数据也非常需要格式化——甚至可能更需要格式化。

Answer 7

代码应该易于阅读且易于维护。 “漂亮”完全符合这些要求，只要你别太可爱就行。

Answer 8

我对强迫症格式化有些过度，但我仍然认为保持代码尽可能可读很重要，除非你有真正令人信服的理由不这样做。 最大的原因是：您 6 个多月前编写的代码可能是其他人编写的。 帮自己一个忙，保持代码整洁和一致。

Answer 9

我也喜欢我的代码漂亮，但不喜欢它影响可读性。

我更喜欢将“快乐路径”放在 if 语句中，然后是异常路径。 如果我预计某条路径比其他路径更频繁地发生，那么它就会先行。 它并不需要像克罗森沃尔德所喜欢的那样是一个“积极”的条件。 这样，它读起来就像我的用例。

（blizpasta 在异常路径之前的 happy-path 击败了我。他提到了我故意避免优化的地方......我更喜欢我的代码漂亮且可读。优化排在最后。）

在 CSS 中，我更喜欢“结构性”或首先布局属性，这样我就可以快速看到某些东西将在哪里结束，然后才知道它会是什么样子。 我会重新组织你的第一个 CSS 示例，使其看起来像你的第二个，但出于我的原因 - 不是你的。 :)

Answer 10

你并不孤单:-)我经常使用对齐练习（就像史蒂夫的回答一样）：

foo     = egg     + spam
foobar  = sausage + spam

越容易阅读越好。

我尝试系统地做的另一件小事是根据运算符优先级对表达式中的术语进行分组，即

if (a<b && c<d) ...
x = a*b + c*d

而不是

if (a < b && c < d) ...
x = a*b+c*d

Answer 11

很多事情对我来说都是有背景的。

空间或不空间...

   puts "ragu"+"pattabi"  
   puts "ragu " +"pattabi"
   puts "ragu " + " pattabi"

折叠多少...

hr = my_intf->do_the_thing_with( i_1,
                                 i_2,
                                 i_3 );

hr = my_intf->do_the_thing_with( "enter_the_dragon", 1965,
                                 "return_of_the_dragon", 1972 );

hr = my_intf->do_the_thing_with( "enter_the_dragon", "bruce lee", "chinese" );

当我编码时，我“必须”做出很多这样的决定。 这对我很有帮助，但如果没有把这些做好，我的大脑不会让我继续前进。 我正在康复:-)

Answer 12

对我来说，编写可读的代码是最好的。 不管格式如何，只要其他程序员在接手编程时能够读懂，那就很漂亮了。

并且总是有意见。

Answer 13

我总是让我的代码看起来很漂亮。 我发现它更容易阅读。 我格式化所有变量及其值，使它们对齐，并使用空格将事物逻辑地分组在一起。 我还尝试按照变量的使用顺序以及它们所属范围的顶部来声明变量。

Answer 14

我没有看到你的 css 示例中的要点...史蒂夫有一个更易读的示例。

至于 if 语句 - 我认为没有任何押韵或理由将最重的放在底部。 我通常把更常见的预期情况放在第一位。

Answer 15

您的示例应该是：

#divPreview {
    width: 210px;
    height: 128px;
    border: #779 1px solid;
    overflow: auto;
    text-align: center;
    vertical-align: middle;
    background-color: #fff";
}

遵循名称的宽度而不是整体线宽。 ；）

但是，是的，你疯了。 ：P

Answer 16

代码的样式应该可读、可维护且顺序一致。 就我个人而言，我发现任意间距的代码很难阅读。 为什么要强迫读者扫描屏幕/页面上的代码以将语句的各个部分放在一起？ 语句中代码块的顺序应按照逻辑顺序、可读性进行定位，有时还需要进行调整以进行优化。 不必要的间隔是浪费时间，并且使代码更难阅读，而不是更容易。 没有人读过麦康奈尔的书吗？

Answer 17

在某种程度上我是。 但我更倾向于最小化。 CSS 绝对是我的例子。 这里添加的内容太长了，但基本上，我对它们进行了阿尔法排序。

为什么？

因为我必须即时做出比我想要的更多的改变。 Alpha 对其中的所有内容进行排序使我可以快速滚动并在一组中找到所有需要更改的内容，而不是使用搜索并到处查找它。

对你们来说这可能是纳秒，但它为我节省了很多挫败感和后来损失的时间。

Answer 18

按字母顺序排列效果更好； 它在复杂 CSS 文件中的好处比在小文件中大得多。

Answer 19

我也进行数值比较，因为它对我来说看起来更数学化，而且我更容易将其可视化为数轴。

不过，您的一些特殊风格将不会得到优化。 例如，如果您要根据案例中的语句数量来排列 switch 语句中的案例，则无法通过将更可能的案例放在顶部来优化它。

我不进行网络编程，但我想按照您的方式重新排列CSS代码是可以的，因为它们出现的顺序并不重要？ 尽管执行顺序在非 Web 编程中很重要，但在重新排列语句时必须小心副作用。

Answer 20

让它看起来“漂亮”通常没有坏处，但就像大多数事情一样，要适度。 例如，我希望每次都将项目保持相同的顺序，并将类似的项目组合在一起，而不是对它们进行排序。 对齐运算符和值很好，但不要更改顺序。

至于“if”语句。 我总是把期待的结果放在第一位，将特殊的结果放在最后。

Answer 21

当涉及到代码格式时，我也患有强迫症。 我同意史蒂夫的观点，最好的办法就是列出你的属性。

var myObj = {
    anInt: 3993,
    aFunction: function() {alert('woot');},
    aString: "Random",
    aBool: false
}

这让我有点痛。 有些人可能不喜欢它，但这让我感觉好多了：

var myObj = {
    anInt:      3993,
    aBool:      false,
    aString:    "Random",

    aFunction:  function() {
                    alert('woot');
                }
}

我的看法是，如果我在代码的某个部分花费大量时间，我希望它不会打扰我的视觉感受并分散我的注意力手头的任务。 另外，我认为它给代码带来了整洁和专业的感觉，有助于加快未来的增强。

Answer 22

我认为好的代码看起来漂亮并且有很好的注释是绝对必要的。
当人们要求我调试没有结构的代码时，我无法忍受。

Answer 23

我更喜欢保持简单的格式风格。 块缩进，并按逻辑/优化排序。 我使用 IDE 的格式化程序（至少在 Visual Studio、Eclipse 和 Netbeans 中），但是，对于带有缩进子项的每种样式，我使用 CSS 一行：

#header {}
  #header h1 {}
  #header h2 {}

#nav {}
  #nav ul {}
  #nav li {}
    #nav li a {}
    #nav li a:hover {}

#content {}
  #content p {}

#footer {}

---

class A {

  private int b = 3;
  private int c = 2;

  public void method(string str) {

     if(str != null && str.length > 5) 
         DoStuffWithString();
     else 
         ShowInvalidError();

  }
}

Answer 24

对我来说漂亮是可读的。

       int anInt    = 10;
     float aFloat   = 1.2155;
MyOwnClass myObject = null;

看起来很漂亮，但是一段时间后阅读这样的代码是很痛苦的。
在这种情况下添加新变量是一件痛苦的事情。

我停止

int anInteger = 10;
float aFloat = 1.2155;
MyOwnClass myObject = null;

我的痴迷是：比较运算符之前和之后的空格以及左大括号之前的新行（奇怪的是为什么人们不使用这种方式而更喜欢在同一行上的左大括号方法）。

Answer 25

我知道在将代码投入生产之前我可能会阅读该代码近 15 遍。 花时间格式化代码，也许看起来我只是让代码看起来更漂亮，但对我来说，它让我的大脑有几秒钟的时间来思考代码，然后再继续下一步。

结构不整齐且一致的代码对我来说是一个警告，表明开发人员没有充分理解问题，无法清楚地表明他的意图，或者编写该代码的开发人员根本不在乎。 如果可以选择的话，我宁愿不与这样的人一起工作。
我相信史蒂夫·麦康奈尔说过，编译器并不真正关心代码的外观，但它是我们人类在大脑的范围和限制内工作的一种机制。

任何人都可以编写看起来很复杂的代码。 但是，需要优秀的开发人员才能将一段复杂的代码变成每个人都会指着它说的东西，哦，是的，这很容易理解。

Answer 26

我与原始帖子不同的一件事是条件。 我认为这不是一个造型偏好问题，而是一个逻辑条件。 最常见的情况是第一种情况，然后会发展到最不常见的情况。 适用于我的代码中的 if 语句和 switch 语句。

Answer 27

许多人提到，如果您尝试手动格式化代码，差异工具将显示不必要的差异。 然而，好的 diff 工具会忽略空格，所以这不是问题。

更重要的一点是，人编写的代码意味着人可以阅读。 因此，请尝试使其尽可能具有可读性。 如果额外的空格可以澄清您的代码，那么就这样做。 无论如何，大多数空格都是为了可读性而使用的。 例如，对于大多数语言来说，缩进纯粹是为了美观。

Answer 28

我喜欢确保代码行之间有足够的间距，并且我有注释来解释事情。 这就是我整理的程度。

在 Visual Studio 中，我明智地使用 Ctrl+K 然后 Ctrl+D（自动格式代码）以使所有内容正确对齐/间隔。 不过，我不像你那么强迫症:)

Answer 29

参数的垂直对齐看起来不错，但对我来说，它分散了我将声明作为语句进行扫描的注意力。

我完全着迷地剪切并粘贴了我的一个片段：

public static String intArrayToString( final int[] array ) {

    if ( array.length == 0 ) {

        return "[]" ;
    }

    StringBuffer sb = new StringBuffer() ;

    sb.append( "[ " ).append( array[ 0 ] ) ;

    if ( array.length > 1 ) {

        for ( int i = 1 ; i < array.length ; i++ ) {

            sb.append( ", " ).append( array[ i ] ) ;
        }
    }
    return sb.append( " ]" ).toString() ;
}

很多间距：这是由于编写了大量示例代码，并且是纯粹为了可读性而编写的翻转。

我希望你的第二个例子的形式是规范的，我在大学时被教导要像在数字线上一样编写这些比较：

if ( 0 < n && n < 10 ) {

    doSomething() ;
}

至于最后一个例子，我会省略布尔比较。 一个真实的案例，然后一个错误的案例：

if ( afflicted ) {

    doSomething() ;

} else {

    doSomethingElse() ;
}

Answer 30

任何在代码更改时让您重新排序的代码风格都是不好的。

它会搞砸差异。 您正在使用版本控制系统，对吗？

还有一些其他的东西可以让你的代码更漂亮，但会搞砸差异。

想象一下这段代码：

int foo = 42;
int fooBar = 1024;

现在让我们通过排列 = 符号来使其更漂亮：

int foo    = 42;
int fooBar = 1024;

但是然后我们添加另一个变量：

int foo              = 42;
int fooBar           = 1024;
String nowLetsBeEvil = 6400;

现在如果您进行比较，所有 3 行都发生了变化，而只有最后一行发生了变化。

还有更多，在方法之间排列参数是不好的

sqrt(x + y, x - z);
sqrt(x    , x    );

逗号和分号排列得很好，但是如果您更改了代码，则必须手动重新格式化所有 sqrt 行在一起并再次搞砸差异。

基本上，永远不要手动格式化。 始终使用 IDE 或漂亮的打印机强制执行代码样式。 但也永远不要选择当代码没有更改时格式会改变的代码样式

编辑：

如评论中所述，某些比较工具可以忽略行内的空格。 这很棒，但并非所有 diff 工具都能做到这一点。 如果您要对齐字段或参数，请确保：

1. 不要手动执行
2. 您的 diff 工具可以忽略空白更改