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

 
Ihor Herasko:

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

则建议写。

当没有附加条件时,这种方法有很大的帮助。

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

软件公司与我们讨论的内容有什么关系!?代码不会停止工作,这里不需要cospirology。

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

是更难读到的。

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

在这种情况下,一行的代码比六行的代码更容易阅读。此外,它更符合逻辑,因为它没有以任何方式被约束在一个循环内。也就是说,你可以复制和粘贴第一个案例,而不必担心第二个案例。

 
fxsaber:

上面的Lots[]例子是一个宝库,说明了代码如何既可以是超级大的,又可以是完全可以理解的。

是你觉得这段代码可以理解。但是,一个只看了文档和看到你的代码的人就会想,为什么数组的大小是8,而文档中只包含6个订单类型

而且,我个人还发现,如果把条件分开,也更容易阅读,即像这样。

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

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

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

我也比这样更舒服。

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)
{
}

但我认为这是一个品味和习惯的问题。没有人需要强加或证明什么。

另一方面,我同意你的说法。

MT4-история торгов отсортирована по времени закрытия и это правило меняться не будет.

而且我认为这是符合逻辑的,我不记得有其他的时间。

 
Alexey Kozitsyn:

对你来说,这个代码是可以理解的。但是,刚刚翻阅过文档并看到你的代码的人,会立刻想知道为什么数组的大小是8,而文档中的订单类型 却只有6。

因此,你看到了一个简单的代码是如何在人们的头脑中产生正确的问题的!在这之后,你应该相信文件中写的一切吗?

 
fxsaber:

而在这之后,你是否应该相信文件中的一切?

你应该这样做,这是RTFM 编程的一个基本原则。

RTFM
  • lurkmore.to
RTFM (изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству») — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства.
 
Igor Makanu:

应该的,这是RTFM 编程的一个基本原则

现实情况与这一原则相矛盾。

 
fxsaber:

软件公司与我们讨论的内容有什么关系!?

那么,你还能举出谁作为权威呢?

代码不会停止工作,这里不需要cospirology。

是的,在MT4中,有99%的概率是这样的,因为MT4几乎被埋没。但是,如果试图在跨平台上使用这样的特技,你会立即遇到一个消失的缺陷,导致一个致命的错误。

在这种情况下,一行的代码比六行的代码更容易阅读。此外,它更符合逻辑,因为它不以任何方式与需要在一个循环内的需求相联系。也就是说,第一种情况可以很容易地复制,第二种则不能。

如果我们谈论的是一个特定的案例,这可能是真的,因为给出的代码几乎是每个EA的标准。但如果你把一些更复杂的东西,写成一行就很难读懂。

为什么要听来自外太空的诅咒,而这些诅咒来自与你的代码一起工作的人?))

 
Ihor Herasko:

那么,你还能举出谁作为权威呢?

奇怪的是,这里触及到了权威的概念。

是的,在MT4中,有99%的概率是这样,因为MT4几乎被埋没。但是,如果试图在跨平台上使用这样的特技,你会立即遇到一个消失的缺陷,导致一个致命的错误。

在MT5中的书写是相同的。

如果我们谈论的是一个特定的案例,它可以是这样,因为给定的代码几乎是每个EA的标准。但是,如果你采取更复杂的东西,当它被写成一行时,就很难阅读。

还有一些结构是如果 -> 其他 如果 -> 其他。我不明白为什么条件运算符中的一个布尔表达式必须以最原始的形式给出。

 
Alexey Kozitsyn:

对你来说,这个代码是可以理解的。但是,刚刚翻阅过文档并看到你的代码的人,会立刻想知道为什么数组的大小是8,而文档中的订单类型 却只有6。

而且,我个人还发现,如果把条件分开,也更容易阅读,即像这样。

我也比这样更舒服。

我认为这是一个品味和习惯的问题。没有人需要强加或证明什么。

另一方面,我同意你的说法。

而且我认为这是符合逻辑的,我不记得有其他的时间。

这些是关键词。

就个人而言,我对继续的拼写感到很恼火。

他们有什么用????如果你阅读

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)

一切都读作俄语。

如果订单被选中,而且订单符号是 "我们的",魔术师也是我们的...那么我们就用大括号做所有事情。

但这听起来不太像俄罗斯人。

如果没有选择权证,请滚开...

如果搜查令的标志不是我们的,那就滚蛋吧......

等等。

我们要给自己发多少次...................

显然,这在mql3中是有意义的。这是一种减少检查病情时间的方法。然后从头到尾检查所有的条件。然而,这种情况早就解决了;如果检查遇到一个未完成的条件,进一步的检查就会停止。而所有这些伎俩完全没有意义。

 
Alexey Viktorov:

这些是关键词。

就我个人而言,我对继续的拼写感到恼火。

他们有什么用????如果你阅读

都是用俄文写的。

如果订单被选中,而且订单符号是 "我们的",魔术师也是我们的...那么我们就用大括号做所有事情。

但这听起来不太像俄罗斯人。

如果没有选择权证,请滚开...

如果搜查令的符号不是我们的,那就滚蛋吧......

等等。

我们要给自己发多少次...................

这在mql3中一定是有意义的。这是一种减少检查条件的时间的方法。当时,所有的条件都被从头到尾检查了一遍。然而,这种情况早就解决了;如果检查时偶然发现一个条件没有得到满足,进一步的检查就会停止。而所有这些伎俩完全没有意义。

你自己也同意,这是一个习惯问题。例如,我就对不必要的嵌套感到厌烦,我总是用return、continue来删除它。而不是 "下地狱",很容易习惯于阅读 "条件1和2得到满足"。

if(!condition1 || !condition2)
   continue;
 
Vladislav Boyko:

例如,我很讨厌不必要的嵌套,我总是用返回、继续来删除它

我对"布尔否定法 NOT(!) "很恼火,它不仅要花费CT时间,而且读逻辑表达式变成了读 "前后")。

我总是在bool函数中返回 "true "作为最期望的响应,举个例子:我用这种方式检查服务器的可用性。

bool ServerDisable(int count=10){
   for(int i=0;i<count;i++){
      if(IsConnected())
         if(IsTradeAllowed())
            if(!IsTradeContextBusy()){RefreshRates(); return(false);}
      Sleep(157);
   }
   Print(__FUNCTION__," Торговый сервер не отвечает");
return(true);}

我称其具有相当的可读性和逻辑性。

if(ServerDisable()) return;

如果服务器繁忙--退出,我通常在交易功能中使用,没有必要用请求来打扰服务器,因为它很忙。

正如他们所说--这是一个品味问题,但正如你所知:品味不同))))。

原因: