标准功能/方法的其他实现方式 - 页 9

[Georgiy Merts]

fxsaber:

到了问题不再发生的地步，安全地忘记了这个问题。当你不需要回到曾经写过的代码时，这很好。它是有效的--这是最主要的。

这就对了。我自己总是这样做（这次也是如此，你可以看到）。

如果事情突然发生变化，问题就会出现。当代码清晰，非明显的地方有很好的注释时，一些变化中的错误原因就很容易找到。但是，在这种 "忘记了 "的情况下--要进行纠正就更难了。

是的，当然，这是个罕见的情况......但是这些非常罕见的情况--我个人非常紧张。这就是为什么在这种情况下，我尽可能地写出清晰的代码，并在不明显的地方给出详细的注释。

[Реter Konow]

fxsaber:

我的代码的一个例子，现在我完全不明白。而且有很多因素需要被很好地理解。

正如你所看到的，代码/风格非常简单。但是，只有当我能够重新写一遍同样的代码时，我才能发现其中的错误或没有错误。这真的会花去我很多时间，因为我需要完全进入问题。

这就是为什么原则是在创建阶段对复杂的东西进行清理（写压力测试），并通过插入mqh以简单的形式使用。正如你所看到的，复杂性并不总是由风格或简洁决定的。

还有一个纯粹的语言构造的例子--TypeToBytes。那里的理解复杂性是一个相当不同的水平。而这正是我在没有宏的情况下会枯萎的地方。正是因为有了宏，你才能相当迅速地进入源代码。因为宏的使用往往不是为了简洁，而是为了理解。

还有一种情况是，你必须考虑很多不复杂但容易被遗忘的隐患。这就是MT4Orders的情况。这就是为什么那里的一些线条伴随着只针对自己的评论。这有助于理解你的代码。

但请注意，这些都是mqh，你不需要进入。而TC的代码是用mqh写的，非常简单。你没有研究常规iHigh功能的源代码。而他们确实是怪物。你只需使用它们。你对图书馆也应该这样做。同样的泛用书目来使用并不要求你完全理解它。

看看MT4 EAs的QB和他们的MT5端口。MT5端口是一个难以理解的缺陷。它不仅没有闻到接近简洁的味道（代码比原来的大很多倍），而且还有令人震惊的MT5陷阱，这些陷阱在mqh-files中没有得到说明。

说实话，我在这里没有什么可争论的。显然，基于你的编程方法，一切都正确（也许只有过度和不合理的代码压缩的情况例外），但如果你采取我的方法，很多都是错的。

1.当然，难以发现的错误甚至可能隐藏在非常简单的代码中。但在难写的代码中，它们更难找到。考虑到解读意义所涉及的精神努力。如果你需要做大量的工作（编写大量的函数，建立新的机制，成功地将它们整合到现有的机制中），节省时间和精力是主要的。这不是关于代码的 "美"。不是关于风格。你需要以这样的方式来编写你的代码，即你可以在半夜阅读它，并尽可能快地理解它。你开始寻找理想的编码方法，以便从自己身上获得最大的结果。并看着它。

return((int)((Value > 0) ? Value / Points[digits] + HALF_PLUS : Value / Points[digits] - HALF_PLUS) * Points[digits]);

你马上就会明白以这种方式写的所有缺点。

1.大量的人物。

2.过度的 "包装"。

3.未加注释的数学运算。

在你醒着的时候，你将无法处理这个代码。也很难应付过度劳累和非常疲惫的情况。想象一下，你每天都在这样工作。你立即转身离开这样的代码。

2.不要看别人的代码，直接把它插进去？

我相信，大型的、严肃的、最重要的、高质量的程序不是仅仅通过组装别人的积木来创造的。 你不可能通过只创造它的一小部分和附加其他部分来创造一个高效的程序。这将是一个 "混乱"。

它可以而且将发挥作用。但这些都是 "临时 "方案。

我不相信由块组成的程序的有效性（开发者甚至不看这些块）。这是个虚构的故事。该方案将是蹩脚的，解决方案将是无效的。会有很多问题。如果程序员作为一个团队工作，并解决一个共同的任务，这是很好的，但如果使用的解决方案是 "漂浮 "在不同人的不同程序之间（他们甚至不看他们），从效率的角度来看，这没有什么。

[fxsaber]

Реter Konow:

它可以而且将发挥作用。但这是，--方案 "在他们的膝盖上"。

你可以看看我在KB的出版物。一定有人在使用它们。

我只为自己和 "跪着 "写作。出版物是一个副产品。

[pavlick_]

Georgiy Merts:

所以对LONG_MAX 的检查--应该是在将双倍数转换为长倍数之前。 显然，四舍五入函数不是为那些不适合整数的值设计的。而这并不能改变问题。

如果该函数返回双数，然后我们将其转换为长数，我们同样面临溢出的危险。

就个人而言，我总是在四舍五入之前对边界值进行断言检查；此外，程序的逻辑是，我总是确保一个大于整数的最大值的值永远不能到达变换处。

你是否经常向图表中投掷长线？对double也是如此--它是层次结构的最后一层，你不必从它那里投出，而且在大多数情况下你也不必--std有一切可以与它合作的东西。不要投靠等级制度，不要流汗。

增加对LONG_MAX/MIN的检查--有消息告诉我，性能测试将不会那么乐观。而且这个人的目标是std替换，所以它应该对整个数值范围都有效。

[Georgiy Merts]

pavlick_:

你是否经常向图表中投掷长线？dabl也是如此--它是层次结构中的最后一个梯级，没有必要从它那里投出，在大多数情况下，与它无关，std有一切可以与它合作。不要投靠等级制度，不要打扰。

增加对LONG_MAX/MIN的检查，我相信性能测试就不会那么幸运了。而且这个人的目标是std替换，所以它应该对整个数值范围有效。

从长到短（反之亦然）--太频繁了。

长于图表 - 很少。

转换是必要的，因为整数和浮点运算的结果明显不同。据称，整数数据的执行速度也更快。

关于范围检查--我已经强调了它是ASSERT--也就是说，这种检查只在DEBUG版本中工作。在我的例子中，所有的输入参数总是在任何公共函数的开头用断言来检查有效范围，这不止一次地帮助我。当然，RELEASE版本已经不需要任何检查就可以工作。

[Реter Konow]

fxsaber:

你可以看看我在KB的出版物。一定有人在使用它们。

我只为自己和 "跪着 "写作。出版物是一个副产品。

我不是在质疑你的经验和专业精神。

只是在几年的时间里，在疲惫不堪的日常编程和开发过程中，你开始估计一些特定代码、解决方案或方法的优势。而且你经常得出非常奇怪的结论...陌生的，但通过大量的实践证明是合理的。

我只是在分享我的观点。

[pavlick_]

Georgiy Merts:

之所以需要进行转换，是因为整数和浮点运算的结果有很大不同。

我无法想象在哪些情况下不能用配音来做正确的事情。在Lua（附属于quik）中，根本就没有整数类型，只有dubles，而且什么都没有。

[fxsaber]

pavlick_:

我有一个不好的想法，在哪些情况下，有些事情不能在配音上正常进行。

柜台。

void OnStart()
{
  const long Num1 = 9007199254967295;
  const long Num2 = Num1 + 1;

  Print(Num1 == Num2); // false
  Print((double)Num1 == (double)Num2); // true
}

双人不会失去所有的范围内的信息，不再有那么多 的时间。

[pavlick_]

fxsaber:

柜台。

好吧，你还是要数到那么多））。而如果你真的想，这不是一个选项。

double cnt;
double high_cnt;
if (++ cnt == 1 000 000) {
   ++ high_cnt;
   cnt = 0;
}

[Georgiy Merts]

pavlick_:

好吧，你还是要数到那么多））。但如果你真的想，这不是一个选项。

有可能被扭曲，这是可以理解的。但这值得吗？

在我看来，如果变量必须只有整数值，那么它应该是整数，只是为了让人无法将浮点值写入其中。 变量或返回值的类型本身已经包含了关于变量和部分算法的重要信息。如果我们到处使用浮点值，这些信息就会丢失。

而且，即使是整数--在我看来，取决于算法--也必须声明为有符号或无符号，而且不一定是长的，也许是 "短的"--只是为了在看代码时，我们可以立即了解有关变量允许有哪些值的范围。

在我看来，Lua中没有整数值的事实是一个严重的缺点。