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

时间：2008-11-14 17:36:32

标签： coding-style pretty-print

我可能是一名肛门程序员，但我喜欢从远处看起来很好的代码。我发现自己排队了一个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();
}

aahhh

我可以继续提供更多例子，但你明白了......

问题：我这里的神经症患者一个人吗？什么是你的编码纠结？

34 个答案:

答案 0 :(得分：74)

任何代码样式都会让您在代码更改时重新排序。

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

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

想象一下这段代码：

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工具可以忽略行内的空格。这很棒，但并非所有diff工具都能做到这一点。如果您要对齐字段或参数，请确保您：

  1. 不是手动执行
  2. 您的差异工具可以忽略空格更改

答案 1 :(得分：23)

根据我的经验，漂亮的代码通常效果很好，而丑陋的代码经常以难以置信的方式打破。这种关注代码外观细节的思维方式也是一种注重更重要细节的思维方式。

也就是说，重新排序CSS风格的元素，以便它们短至长，这就是疯狂。

答案 2 :(得分：21)

if-else语句中的正面条件总是如此。美在于。

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

答案 3 :(得分：16)

让代码看起来“好”很重要，这就是为什么我们有常规和样式指南。它的目的是使代码易于阅读并使错误的代码看起来错误。我会说这里的一些例子超出了这个范围并增加了一点价值。

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代码，以便那么   part小于ELSE部分   （因为较重的东西去了   底部，对吧？）

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

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

答案 4 :(得分：11)

我可能会更进一步做到这一点：

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

答案 5 :(得分：9)

应该是

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

买一个漂亮的打印机，接受OCD治疗; - ）

答案 6 :(得分：5)

我认为它有点不同。代码应该被格式化以便于阅读，不一定是“漂亮” - 尽管这两者通常可能是相同的。

但作为反案，

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

比更漂亮的人更可读：

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

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

事实上，我甚至遇到了红宝石相当优雅的问题：

y = x.getParam() if x

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

我必须承认，当我看到这种语法时，我的膝盖有点弱（我认为它来自hascal）

y = x?getParam();

这种优雅甚至可以压倒我疲惫不堪的观念。

最后，尽管格式化可以非常巧妙地在代码中显示模式，但如果你的代码中甚至有模式，那么你可能做得不对。

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

顺便说一下，你的第一个例子是数据，而不是代码 - 数据也非常需要格式化 - 甚至可能更多。

答案 7 :(得分：3)

代码应易于阅读，易于维护。 “漂亮”完全符合这些要求，只要你不太喜欢它。

答案 8 :(得分：2)

很多事情都适合我。

空间与否：...... 

   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" );

我必须在编码时做出很多像这样的决定。它主要是有帮助的，但是如果没有这些权利，我的思想就不会让我更加前进。我正在恢复： - ）

答案 9 :(得分：2)

对我来说，编写可读代码是最好的。无论格式如何，只要它可以被其他程序员读取/当他们接管编程时，它就很漂亮。

总是有评论。

答案 10 :(得分：2)

我喜欢我的代码，但不是它干扰可读性的地方。

我更喜欢在if语句中首先放置“happy path”，然后是异常路径。如果我期望某条路径比其他路径更频繁地发生，那么它首先会发生。它不需要像krosenvold更喜欢的“积极”条件。这样，它就像我的用例一样。

（blizpasta用异常路径之前的快乐路径击败了我。他提到优化，我故意避免它......我更喜欢我的代码非常可读。优化是最后的。）

在CSS中，我首先选择“结构”或布局属性，这样我就可以快速看到 某些东西将要结束的东西，然后才会看到它的样子。我会重新组织你的第一个CSS示例看起来像你的第二个，但出于我的原因 - 不是你的。 ：）

答案 11 :(得分：2)

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

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

答案 12 :(得分：2)

我过度使用我的OCD格式，但我仍然认为保持代码尽可能可读是很重要的，除非你有一个非常令人信服的理由不这样做。最大的原因：你在6个月前写的代码可能也是由别人写的。帮自己一个忙，保持代码清洁和一致。

答案 13 :(得分：1)

我是这样的。但我更倾向于最小化。 Css绝对是我的榜样。这里添加太长了，但基本上，我把它全部命令。

为什么？

因为我必须在飞行中做更多比我想要的更改。 Alpha命令中的所有内容允许我快速滚动并在一个分组中获得需要更改的内容，而不是使用搜索并在任何地方找到它。

对你们所有人来说可能只有纳秒，但它为我节省了很多挫败感和以后失去的时间。

答案 14 :(得分：1)

字母排序更好;它在复杂的CSS文件中的好处远远大于小文件。

答案 15 :(得分：1)

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

答案 16 :(得分：1)

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

答案 17 :(得分：1)

你的榜样应该是：

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

遵循名称的宽度而不是整个线宽。 ;）

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

答案 18 :(得分：1)

我没有看到你的css例子中的重点...史蒂夫有一个更可读的例子。

至于if语句 - 我认为没有押韵或理由将最重的人放在最底层。我通常首先考虑更常见的情况。

答案 19 :(得分：0)

垂直参数的对齐看起来很不错，但对我而言，它会使我不愿意将声明扫描为声明。

我完全痴迷地剪掉并粘贴了一小段我：

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() ;
}

答案 20 :(得分：0)

在代码格式方面，我也受到强迫症的影响。我和史蒂夫在一起，选择你的房产是要走的路。 

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

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

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

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

我看待它的方式是，如果我在代码的某一部分花费了大量时间，我宁愿它不会打扰我的视觉敏感度并分散我对手头任务的注意力。此外，我认为它为代码提供了一个整洁和专业的触摸，有助于加快未来的增强。

答案 21 :(得分：0)

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

在Visual Studio中，我明智地使用 Ctrl + K然后按Ctrl + D （Autoformat代码）以使所有内容正确对齐/间隔。我不像你那样强迫症，但是：）

答案 22 :(得分：0)

如果您尝试手动设置代码格式，很多人都会提到diff工具会显示不必要的差异。但是，好的diff工具会忽略空格，所以这不是问题。

更重要的一点是，一个人编写的代码应该由一个人阅读。因此，尽量使其尽可能可读。如果额外的whitepsaces可以澄清你的代码，那就去做吧。无论如何，大多数空格都用于可读性。例如，缩进纯粹是美学的大多数语言。

答案 23 :(得分：0)

我在原帖上改变的一件事就是有条件的。作为造型偏好的问题，我看起来不是一个有条件的，而是一个逻辑的。最常见的情况是第一种情况，并将进展到最不常见的情况。适用于我的代码中的 if 语句和 switch 语句。

答案 24 :(得分：0)

我知道在投入生产之前我会阅读该代码的次数可能接近15次。花时间格式化代码，或许看起来我只是让代码看起来很漂亮，但对我来说，它让我的思绪在几秒钟内完成代码的思考，然后再继续下一步。

没有结构整齐且一致的代码对我来说是一个警告，开发人员不能充分理解问题，清楚地表明他的意图，或者那些执行该代码的开发人员并不关心。如果我有选择的话，我宁愿不和这样的人一起工作。 我相信是史蒂夫麦康奈尔说，编译器并没有真正开始代码看起来如何，但它是我们人类的机制，在大脑的限制和局限内工作。

任何人都可以编写看起来很复杂的代码。但是需要一个优秀的开发人员来处理一段复杂的代码并将其转化为每个人都指向它的内容并说，哦，是的，这很容易理解。

答案 25 :(得分：0)

对我来说很可读。

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

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

我停下来

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

我的痴迷是：比较操作员之前和之后的空间以及开口支撑前的新线（人们不使用这种方式并且更喜欢开头支撑同一线路的方法很奇怪）。

答案 26 :(得分：0)

我也进行了数值比较，因为它对我来说看起来更像数学，而且我更容易将它想象成一个数字线。

虽然您的一些特殊风格尚未优化。例如，如果您根据案例中的语句数量在switch语句中排列案例，则无法通过将更可能的案例置于最高位置来优化案例。

我不进行网络编程，但我想可以按照你的方式重新排列css代码，因为它们出现的顺序无关紧要？执行顺序在非网络编程中很重要，但在重新安排语句时必须注意副作用。

答案 27 :(得分：0)

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

#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();

  }
}

答案 28 :(得分：0)

通常没有什么害处让它看起来“漂亮”，但在大多数情况下使用适度。例如，我更喜欢每次将相同的项目组合在一起而不是对它们进行排序。对齐运算符和值很好，但不要更改顺序。

至于“if”陈述。我总是把期望放在第一位，而特殊的排在最后。

答案 29 :(得分：0)

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

答案 30 :(得分：-1)

我没有标签对齐，但每当我宣布一堆东西（例如整数）而不是像：

int num = 5, num2 = 7, num3;

我喜欢安排它，以便任何具有初始值的变量（如num2，不，我的术语不太好）最后，如果有多个，则按大小排列（或按字母顺序排列或其他）： 

int num3, num = 5, num2 = 7;

除此之外，我真的很讨厌 function（）{约定。我更喜欢：

function()
{
    // Code here.
}

它看起来更整洁，更容易阅读。

答案 31 :(得分：-1)

我没有资格评估你的神经症，但我可以告诉你，我经常被发现以这种方式写作：

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

我喜欢你做的其他一些事情，但我并不认为他们中的任何一个。这实际上取决于背景和最重要的是突出和/或易于掌握。

我必须承认，我从不需要查看差异（我也不使用调试器），所以我不羞于重新格式化修订版本的外观，调整以使更改融入保留的样式。< / p>

答案 32 :(得分：-2)

按字母顺序排序

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

我更喜欢自己的行括号

If (a)
{
}

而不是

if (a) {
}

但是现在C＃已经自动实现了属性我发现自己正在使用自己的自动代码格式化规则。

public class Employee
{
    public string FirstName { get; set; }
    public string LastName { get; set; }

}

答案 33 :(得分：-2)

一个小风格的怪癖实际上可以帮助确保正确性是将任何常量放在if检查的左侧。这完全可以防止意外使用赋值等于而不是比较等于。

说

if (3.14159 == foo) {
//Do stuff
}

可能看起来有点奇怪，但如果有人试图用

更改pi的值，则会出现编译器错误 
if (3.14159 = foo) {  //No good.
//Do stuff
}
相关问题
最新问题