为什么有这么多代码是这样的？ - 页 3

新评论
 
RaptorUK:

但这并不意味着，如果他们在语法或逻辑方面寻求帮助，那么代码就不会"......在语法和逻辑上是正确的；"？

是的，你是对的。但在讨论更多（或更少）有效的编码风格/做法的背景下，最重要 的方面是代码在语法和逻辑上是正确的，无论使用何种编码风格。我想另一种说法是，风格必须让位于句法和逻辑正确的代码--主要问题不是代码是否好看，是否容易阅读，而是它在执行编写的任务时在句法和逻辑上是否正确。）

我也同意关于//注释的说法。一个人永远不会有太多的//注释，既可以让原始程序员对代码的各个部分的细节有新的认识，又可以帮助/帮助其他人在完成/实施后对代码的理解。

 
Thirteen:

是的，你是对的。 但在讨论更多（或更少）有效的编码风格/做法的背景下，最重要的方面是代码在语法和逻辑上是正确的，无论使用何种编码风格。 我想另一种说法是，风格必须让位于句法和逻辑上正确的代码--主要问题不是代码是否好看，是否容易阅读，而是，它的句法和逻辑上是否正确，以执行它所写的任务。）

啊，好吧，我明白你的意思了 ......漂亮的代码如果不能工作就没有用 ......但也许它更容易修复？
 
RaptorUK:
啊，好吧，我明白你的意思了......漂亮的代码如果不工作就没有用......但也许它更容易修复？
是的。换句话说，编码风格/实践和演示，主要是程序员的选择，是达到目的的手段（目的是语法和逻辑上正确的代码）。 当代码能够被程序员（以及随后没有写代码的其他人）轻松阅读和理解时，检测和纠正句法和/或逻辑错误就容易得多。
 

我认为大多数编码方式允许编码者想要或需要的可读性，当我的代码完成并工作时，我会关闭它，但如果我需要分享它或讨论它，很容易用几行空格重新打开。我认为编码格式应该支持轻松识别缺失的大括号，以及在有多个分支的复杂if else树时轻松识别if else对。我从未采用过K&R风格，所以我想看看K&R风格的编码者 是如何做的。

 
SDC:

当我的代码完成并开始工作时，我会关闭它，但如果我需要分享它或讨论它，很容易用几行空格把它重新打开。

为什么要把它关闭呢？我真的不明白把代码压扁的意义何在。如果你需要打开它来分享/讨论，这意味着什么？

SDC:

我认为一个编码格式应该支持轻松识别缺失的括号，以及在有多个分支的复杂的if else树时轻松识别if else对。我从未采用过K&R风格，所以我想看看K&R风格的编码者是如何做的。

对于K&R风格，底部括号与条件匹配一致。我个人使用

1.一致的缩进

2.2.对于单句子，要么 用大括号和缩进，要么在条件后面不加括号，即。

if (flag) {
   i++;
}

OR

if (flag) i++;

3.使用一个体面的程序员编辑器来匹配大括号。

匹配大括号是没有问题的--大部分Linux内核 都是用这种风格写的，而且它是Java的标准。虽然我可以看到Allman风格的吸引力，因为在K&R风格下，我经常会在条件后插入一个额外的空行，以消除代码的混乱。嗯，我可能会被转换 :)

 
ydrol:

为什么要把它封闭起来？我真的不明白压扁的代码有什么意义。如果你需要打开它来分享/讨论，这意味着什么？

对于K&R风格，底部支架与条件匹配一致。我个人使用

1.一致的缩进

2.2.对于单句子，要么 用大括号和缩进，要么在条件后面不加括号，即。

3.使用一个体面的程序员编辑器来匹配大括号。

匹配大括号是没有问题的--大部分Linux内核都是用这种风格写的，而且它是Java的标准。虽然我可以看到Allman风格的吸引力，因为在K&R风格下，我经常会在条件后插入一个额外的空行，以消除代码的混乱。嗯，我可能会被转换 :)

我只是把它关起来，这样它占用的屏幕空间就少了。我喜欢在屏幕上同时看到尽可能多的内容。我不需要大括号匹配器，我的格式是，如果我把光标放在大括号后面，用箭头键垂直向上运行，当它碰到另一个大括号时，那就是它的配对。

在这段代码中，很容易看到第三个else与第一个if配对，第二个else与第二个if配对，第一个else与第三个if配对，因为每个else后面的括号都垂直地排在其对应的if括号后面。同样，我们也很容易看出哪些if没有else，因为每个if的括号都与else后面的相应封闭括号垂直排列。我并不是说其他人都应该这样格式化代码，只是因为我碰巧喜欢它，但对我来说，它是紧凑和合乎逻辑的。

      if(downtrend)
      {if(High[i] < LineDownBuffer[i+1])
       {if(DeMarkerHighBuffer[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
        }else
        {if(DeMarkerHighBuffer[i] < LineDownBuffer[i+1])
         {LineDownBuffer[i] = DeMarkerHighBuffer[i];
       }}}else
       {if(High[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
         LineUpBuffer[i] = DeMarkerLowBuffer[i];
         downtrend = false;
         uptrend = true;
      }}}else
 
SDC: 我认为大多数的编码风格允许编码者想要或需要的可读性，当我的代码完成并工作时，我会关闭它，但如果我需要分享它或讨论它，很容易用几行空格打开它。我认为编码格式应该支持轻松识别缺失的大括号，以及在有多个分支的复杂if else树时 轻松识别if else对。我从未采用过K&R风格，所以我想看看K&R风格的编码者是如何做的。

我不能为每个使用k&r的编码者回答这个问题。老实说，我越看你的格式，我就越喜欢它。如果我采用Allman的风格，我肯定能看到自己使用你的修改版。大括号互相排列，摆脱了开括号和闭括号占用整行的情况。你可以把光标放在if后面的i上，找到丢失的大括号，不用担心制表符/缩进的大小，紧凑模式{在屏幕上看到你的大部分代码}。所以是的，这很酷，只是乍一看，因为我不习惯，它似乎很混乱。这就是问题的核心所在。

在我看来，很多美国编码员都采用[KnR & Allman]，而Whitesmiths 风格似乎在欧洲人中很流行。Whitesmith也是Mt4的默认风格。现在，这些风格都没有错，只是当我在帮助别人时，我必须不断提醒自己忽略我的K&R风格，多想想Whitesmith。那就是使用代码格式化器。

为什么有人要写 "复杂的if else树"，我不明白。当有人在一个复杂的if_nest中留下所有的留白和格式化，看起来就像他们试图在页面上设计一个蛇形|意大利面条|之字形。第一个if从第1行开始，到第300行结束，其中大约有150或50％的行被大括号挡住了。与其使用 "复杂的if else树"，为什么不直接创建一个函数。然后让第1行实际上以if( false ){ return; }结束。

 

谢谢ubzen，我很高兴有人喜欢我的格式，笑。我经常使用if else，可能是因为当我第一次开始写代码时，有人告诉我if else能使代码更快，所以我养成了这样的习惯。

 
SDC:

谢谢ubzen，我很高兴有人喜欢我的格式，笑。我经常使用if else，可能是因为当我第一次开始写代码时，有人告诉我if else能使代码更快，所以我养成了这样的习惯。

这并不是针对你


像这样的时候，如果有一个正式的强制标准，每个人都按照这个标准工作就好了......那么我们都会做同样的事情，我们都会喜欢你的代码。 在你问之前，不，我将坚持我的Whitesmiths风格 ... ...至少我现在知道该怎么称呼它，谢谢ubzen

 
不客气，SDC 和RaptorUK。编码是一个比赢利更容易讨论的话题_EA.:)
1234
新评论