mql4语言的特点、微妙之处以及技巧 - 页 12

新评论
 
Ihor Herasko:

在许多软件公司，这样的代码会让他们的手指都被打掉。无论何时何地，首先要做的是避免 "不必要的阅读"。例如，如果你在输入一个函数时使用一个条件。

则建议写。

这种方法对反对附加条件非常有帮助。

再一次，它是一个痛苦的屁股。因为没有人检查OrderType()函数返回什么。或者，也许它返回-1或6？这是进入编译器属性的一个例子，你应该永远远离它。你自己举了很多跨平台代码的例子。那么，为什么在这种情况下你要远离它呢？一个新的MQ编译器出来后，这段代码将不再能正确工作。

与继续相同的情况。像这样的代码。

是更难读到的。

而在这两种情况下，执行的效率却是一样的。

这完全是一种无奈。

if (!OrderSelect(i, SELECT_BY_POS))
   continue;

if (OrderSymbol() != Symbol())
   continue;

if (OrderMagicNumber() != m_nMagicNumber)
   continue;
 
Vitaly Muzichenko:

这完全是一种无奈，不是吗？

什么是尖锐的？超表达式的一行是它变得艰难的地方。人类不是计算机，他们不需要处理其余的条件。人类与计算机不同，必须将整个表达式计算到最后，然后才能理解其第一个组成部分导致了一个错误的结果。

在一个条目中，一切都由简单的条件分解，这种计算是不必要的：第一个条件没有得到满足--消失。

你需要的是节省时间，而不是节省绳索。但他们只是为简洁而战，这实际上是将操作和条件打包成彼此。如果这个包装能给你带来可观的生产力收益，我可以理解。但它并没有。最大的增长在测量误差之内。人们关心的是节省字符串，但他们完全没有想到要节省理解和调试代码的时间。

 
Ihor Herasko:

罐子是什么？一行超级表达式--这就是它的艰难之处。人不是电脑，所以他可以立即理解，没有必要处理其余的条件。人类与计算机不同，必须将整个表达式计算到最后，然后才能理解其第一个组成部分导致了一个错误的结果。

在一个条目中，一切都由简单的条件分解，这种计算是不必要的：第一个条件没有得到满足--消失。

你需要的是节省时间，而不是节省绳索。但他们只是为简洁而战，这实际上是将操作和条件打包成彼此。如果这个包装能给你带来可观的生产力收益，我可以理解。但它并没有。最大的增长在测量误差之内。人们关心的是节省字符串，但他们完全没有想到要节省理解和调试代码的时间。

我不会说这是一个难以理解的超级表达式。

if(!OrderSelect(i, SELECT_BY_POS) || OrderSymbol() != Symbol() || OrderMagicNumber() != m_nMagicNumber)
   continue;

哦，"计算周期短 "是一个基本的东西，在阅读条件时 "自动 "考虑到了，不需要任何精神努力去做。

同样，纯属主观意见。

 
Vladislav Boyko:

你自己也同意，这是一个习惯问题。

我还要说一遍。我并不鼓励任何人改变他们的习惯，寻找毡尖笔的味道差异。

伊戈尔-马卡努。

正如你所说的--这是一个品味问题，但正如你所知：所有毡尖笔都是不同的))))。

成群的毡尖笔只有颜色不同，它们的味道是一样的。
 
Vladislav Boyko:

我不会说这是一个难以读懂的超级名词。

而且在这里不需要调用任何东西。到目前为止，我的对手（包括你）还没有提出一个论点，说这种表达方式比行式分解更容易阅读。

然而，从我这里，已经提出了多达三个论点。

  1. 一条长线 不适合在视野中出现。至少需要最少的头部旋转（增加处理时间）。一条短线和后面的短线不需要那么多努力。
  2. 在长长的队伍中，更容易犯错而不被发现。分成行的做法减少了出现这种错误的概率。
  3. 一条长线是无法调试的。把它拆成字符串就可以了。
没有主观的偏好。一切都是以实际意义为依据的，仅此而已。是的，有些人可能觉得用右脚跟挠左耳更方便，但这并不意味着这种方法很实用。在自然界中，一切都受制于实用性，那些更实用的人可以生存。
 
Ihor Herasko:

而且在这里没有必要说出任何名字。到目前为止，我的对手（包括你）还没有提出一个论点，说这种表达方式比行式分解更容易阅读。

然而，从我这里，已经提出了多达三个论点。

  1. 一条长线 不适合在视野中出现。至少需要最少的头部旋转（增加处理时间）。一条短线和后面的短线不需要那么多努力。
  2. 在长长的队伍中，更容易犯错而不被发现。分成行的做法减少了出现这种错误的概率。
  3. 一条长线是无法调试的。把它拆成字符串就可以了。
没有主观的偏好。一切都是以实际意义为依据的，仅此而已。是的，有些人可能觉得用右脚跟挠左耳更方便，但这并不意味着这种方法很实用。而在自然界中，一切都受制于实用性，那些更实用的人就能生存。

伊戈尔，如果眼睛在眼窝里不动，要转头，就可以这样写。

if(OrderSelect(i, SELECT_BY_POS)
&& OrderSymbol() == _Symbol
&& OrderMagicNumber() == m_nMagicNumber)
 {
  // Делаем что надо...
 }

还有，我遇到过多少短句的错误...........显然，错误的数量和概率并不取决于线的长度。

人们只能同意进行调试。但这个习惯是在mql4中出现调试器之前养成的，不是每个人都能改变习惯。

 
Alexey Viktorov:

伊戈尔，如果眼睛在眼窝里不动，要转头，可以这样写。

还有，我遇到过多少短句的错误...........显然，错误的数量和概率并不取决于线路的长度。

人们只能对调试表示赞同。但这个习惯是在mql4中的调试器之前养成的，不是每个人都能改变习惯的。

你可以这样做，但用这种方式查看一个程序块，你必须滚动屏幕2次，这比在一个屏幕上看到所有代码更糟糕。(不涉及你，这只是一个例子）。

 
fxsaber:

不幸的是，这个神话在论坛的历史中找不到任何支持。此外，开发商一直明确表示他们的立场是，作为一个原则问题，不能进行这种改变。

有这样一件事。分拣产生了影响。

该讨论可能是在旧的metatrader4.com论坛上进行的（最近仍然开放，现在它重定向到mql5.com）。

 
Andrey Khatimlianskii:

它是这样的。分拣受到影响。

讨论一定是在老的metatrader4.com论坛上进行的（最近仍然开放，现在重定向到mql5.com）。

它是，它是。就像现在的历史订单 数量，如果你设置了 "今天"，那么OrdersHistoryTotal()将返回今天关闭的订单数量。如果 "历史 "选项卡没有显示任何旧的订单，那么即使通过票据也无法获得。

 
Alexey Viktorov:

它是，它是。就像现在的历史订单 数量一样，如果你设置 "今天"，OrdersHistoryTotal()将返回今天关闭的订单数量。如果 "历史 "选项卡没有显示任何旧的订单，那么它是不可用的，即使是通过票据。

这是关于分类的问题。那时，如果不是按时间排序，你就无法按索引找到最后一个--它是排序后的最后一个。

而现在，历史的深度并不取决于选定的标签？在我看来，它仍然是如此。

1...5678910111213141516171819...35
新评论
原因: