对巴解组织的看法很有意思

fxsaber 2021.01.31 11:20 #81

Igor Makanu:

我有99%的把握，这些代码将以同样的速度在处理器层面上执行到一个战术--处理器有优化、并行和其他什么在微指令层面上运行的东西

当你写任何质量的代码时，依靠 "编译器会把它刷成最佳的"，难道你不会在这里得到负面的效果吗？

你可以肯定的是，编译器会用一种写作风格做正确的事情。对于另一种风格，你只需相信编译器会更聪明。

考虑到跨平台、不同的编译器等，我选择注意我在代码中的做法。

Igor Makanu 2021.01.31 11:32 #82

fxsaber:

当任何高质量的代码都是以 "编译器会把它刷到最优 "的期望来写的，这难道不会产生负面的影响吗？

我的例子几乎没有任何质量问题，它们是典型的结构--我长期以来一直在比较githab上的来源，tst1和tst2的例子，都被程序员积极使用。

这就是为什么我认为编译器的开发者很久以前就学会了标准的代码结构，这对编译器来说不是一个问题。

负面影响--正如上面@TheXpert 所写的，公司对代码格式有要求，但要求一般都是一样的--代码必须能让其他团队成员理解，甚至包括那些刚来的....。

fxsaber:

有了一种写作风格，你就可以确定，编译器会做正确的事情。有了另一种风格，你只需相信编译器会更聪明。

现在更聪明的不是编译器，而是处理器本身，我认为，如果我们谈论的是高性能代码--主要的性能开销不是在函数调用，而是在内存读取（内存访问）--如果你能用小的计算值代替数据/变量存储，你将（在处理器微指令优化层面）有一个小的收益

...但其余的，我想，都是邪恶的))))。

SZZY：还有在编译器层面上的代码优化，我读了一点--都是在一个猜测的层面上，在PC铁上我定期读，我读了很长时间，我写了意见。

fxsaber:

考虑到跨平台、不同的编译器等，我选择注意我在代码中的做法。

那么我没有选择--简而言之："我是一个艺术家--我就是这么看的"）），我希望我没有冒犯。

Valeriy Yastremskiy 2021.01.31 11:43 #83

我有一个规则，5年后的代码必须是可以理解的，如果不能理解，就是坏代码。

而如果被他人理解，则非常好。

fxsaber 2021.01.31 11:59 #84

Valeriy Yastremskiy:

我有一个规则，5年后的代码必须是可以理解的，如果不能理解，就是坏代码。

而如果被他人理解，则非常好。

这里（和这里）是非常好的代码。但我不明白。我的大脑很久以前就停止了生长。

Valeriy Yastremskiy 2021.01.31 12:13 #85

fxsaber:

这里（和这里）是非常好的代码。但我不明白。我的大脑很久以前就停止了生长。

这些主题很复杂，不是每个人都能理解，）更不用说代码了。

Georgiy Merts 2021.01.31 13:10 #86

哦，真是个好话题...而没有我...这不是好事...必须大声说出来。

关于标题中的文章--正确的前提（代码必须尽可能是确定性的）被用在一个非常愚蠢的地方，把加法运算和累积运算作为例子进行比较。而结论是，加法运算是确定的，它总是返回相同的结果，而累加则不是，因为结果总是不同。

但是，请原谅我...它们是不同的操作，在这两种情况下，结果都是完全正确的，而且正是分别从加法和累加中所期望的!

即使是随机数发生器的例子--也不能被称为 "非决定性的"，如果人们认为它是一个具有随机成分的操作。

在我看来，整个非决定性的事情就是作者从代码中期望的东西根本不是代码的目的。

第二件事是代码的可读性 - 我发现 "问号 "操作非常有害，难以理解。用条件运算符代替 "问题"，可以得到效率绝对相同的可执行代码。在这种情况下，源代码明显变得更加庞大，但也更加清晰。我认为这是一个很大的优点。

我总是试图将所有这些众多的逻辑表达式拆分成一系列带有中间结果的独立操作。即使这样的代码会导致可执行代码的效率降低，但在我看来，更好地理解的好处要重要得多。

Maxim Kuznetsov 2021.01.31 14:02 #87

而这是面向圣诞树的编程领域 :-)

void OnStart()
  {
   if(condition)
     {
      if(other_condition)
        {
         for(loop_stmt)
           {
            if(wtf)
              {
               while(repeats)
                 {
                  if(oh_shit)
                    {
                     if(really_fck)
                       {
                        deep_nesting();
                       }
                    }
                 }
              }
           }
        }
     }
  }

Georgiy Merts 2021.01.31 14:30 #88

Maxim Kuznetsov:

而这是面向圣诞树的编程领域 :-)

如果条件是简短的表达，那就很好。虽然，你可以把它们分成不同的功能。

而在这种情况下的反向括号中，我总是在开头的括号标题中加一个注释，以使其明确。

Andrey Khatimlianskii 2021.02.01 07:29 #89

fxsaber:

有了一种写法，你就能确定编译器会做正确的事情。有了另一个，你所要做的就是相信编译器会更聪明。

在执行这项工作时，不会有任何区别。

if ( a() ) return(true);
if ( b() ) return(true);
return(false);

和这个。

return( a() || b() );

我完全支持易于阅读和调试的代码。

Vitaly Muzichenko 2021.02.01 08:19 #90

Andrey Khatimlianskii:

这样做不会有任何区别。

和这个。

我完全支持易于阅读和调试的代码。

就可读性和杂乱性而言，我一点也不喜欢这种设计

if ( a() ) return(true);
if ( b() ) return(true);
return(false);

对巴解组织的看法很有意思 - 页 9