对MetaEditor的易用性的建议 - 页 6

新评论
 
Комбинатор:
))好吧，你知道如何无礼，我已经明白了，但我没有看到对你的观点的证实或对我的观点的反驳。

贝林斯基当然不会在公共场所这样表达自己。所以不接受任何投诉。

也没有理由为你提到的当局不能给予的 "呕吐反射 "辩护。

 
Alexey Viktorov:

这是复制的代码。

我说的是参数和字符之间的逗号后的空格。

它读起来更顺口

比这。


所以我举了一个相反的例子 ))

下面是我的一个代码例子，直接来自现场

    void SetThresholds(double &thresholdOpen[], double &thresholdClose[])
    {
        int signalIdx = 0;  ///////////////// !!!!!!!!!!!!!!!! пока задано жестко
        CSignalFilter *signal = (CSignalFilter*)m_SignalArr.At(signalIdx);
        if (CheckPointer(signal) != POINTER_INVALID)
        {
            signal.SetThresholds(thresholdOpen, thresholdClose);
        }
    }

***

 

在以前的场合已经注意到了，为了新的听众，我再讲一遍。

客观地说，有一些事实上的风格标准。现在（在过去的10年里）只有2种主要的语言有类似C++/Java的语法。这些风格是由Combinator发出的。它们被用于软件行业的绝大多数公司。它们已经证明了自己，它们经过了试验和测试，它们符合逻辑，可以理解，并且为绝大多数专业编码人员 所熟悉。

试图推广其他东西，没有好处，只有缺陷，是一种失败。不承认这些缺陷，不过是固执己见。他们是客观的。很明显，MQ自己也在使用和迷恋这种风格，但这只是另一个错误。有时软件就是这样拒绝修复已知的错误，说已经有一堆第三方产品盯上了这个错误的行为。实际上，在所有这些情况下，我们应该寻找一种解决方案，允许我们保留旧的行为，以便向后兼容，但用所谓的 "协议升级 "或分叉进行修复。在样式方面，有一个简单的解决方案：一个 可定制的样式器。这可以说是已经做了一百次了。

顺便说一下，在MQ风格中，问题不仅涉及到括号的位置，而且还涉及到注释的风格--根据定义，它们不能覆盖代码，现在在MQ风格中观察到了这一点。

 
Alexey Volchanskiy:

所以我举了一个相反的例子 ))

下面是我的一个代码例子，直接来自现场

***

那么自作聪明是为了什么？

 
Stanislav Korotky:

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Вот это стиль! :)

Sergey Kravchuk, 2009.11.24 11:27


Вот кусочек кода из MACD Sample.mq5 по-ихнему и по-моему:

Styler5                                  -|- Мой стиль
-------                                  -|- ---------
bool CSampleExpert:: LongModified()       -|- bool CSampleExpert:: LongModified()
  {                                      -|- {  
   bool res=false;                       -|-   bool res = false;
//--- check for trailing stop            -|-   //--- check for trailing stop
   if( InpTrailingStop>0)                 -|-   if ( InpTrailingStop > 0)
     {                                   -|-   { 
      if( m_symbol.Bid()- m_position. Price -|-     if ( m_symbol.Bid() - m_position. Pric
        {                                -|-     {
         if( m_position. StopLoss()< m_symb -|-       if ( m_position. StopLoss() < m_symb
           {                             -|-       {
            double sl= m_symbol.Bid()- m_a -|-         double sl = m_symbol.Bid() - m_a
            double tp= m_position. TakePro -|-         double tp = m_position. TakeProfi
            //--- modify position        -|-         //--- modify position
            if( m_trade. PositionModify( Sy -|-         if ( m_trade. PositionModify( Symbo
               printf("Long position by  -|-           printf(" Long position by % s to
            else                         -|-         else
              {                          -|-         {
               printf("Error modifying p -|-           printf(" Error modifying positi
               printf("Modify parameters -|-           printf(" Modify parameters : SL
              }                          -|-         }
            //--- modified and must exit -|-         //--- modified and must exit fro
            res=true;                    -|-         res = true;
           }                             -|-       }
        }                                -|-     }
     }                                   -|-   } 
//---                                    -|-   //---
   return( res);                          -|-   return( res);
  }                                      -|- }

无处可学的风格，但右边的版本是 "我的风格"，仿佛是我自己写的。由于某种原因，左边的那个更难读。我不确定这是否是一个习惯问题。


弗拉基米尔-卡尔普托夫。
论坛上，kodobase应该充满了同样设计的代码。

绝对不可能!曾经有一段时间，需要改变方法/字段名的风格来进行出版。例如，不写this.i，而写this.m_i。对班级名称的要求也一样--以字母C开头。幸运的是，常识占了上风，我们不再有这样的要求。

关于交易、自动交易系统和交易策略测试的论坛

对MetaEditor的易用性的建议

Combinator, 2017.09.28 15:00

我使用奥尔曼式。

void f()
{
   // some code
   if (condition)
   {
      // some code
   }
}

或者至少是K&R。

void f() {
   // some code
   if (condition) {
      // some code
   }
}

这两种风格以巨大的优势领先于其他风格。两者都有清晰可读的代码嵌套。你可以看到块的归属，没有格式上的问题。

你的风格在GNU之下，我上面说的缺点。GNU至少有同样的缩进，从卷曲的线条到卷曲的线条。

原来我一直用的是奥尔曼式!K&R--出于某种原因令人讨厌，尽管我看到顶级奥林匹克竞赛的领导人非常喜欢这种风格。

关于交易、自动交易系统和策略测试的论坛

对MetaEditor的易用性的建议

Combinator, 2017.09.28 15:15

当我们谈到这个问题时，ME的 另一个尴尬之处在于依赖注册的自动 完成。

在所有好的编辑器中，它是不分大小写的，所以它使生活更容易。

我完全同意。
 
Rashid Umarov:

你想怎么对待我都可以。我不是一个百元大钞来取悦所有人。

重要的是，我发表的意见已经被听取，甚至可能被考虑。

 
Stanislav Korotky:

在以前的场合已经注意到了，为了新的听众，我再讲一遍。

客观地说，有一些事实上的风格标准。现在（在过去的10年里）只有2种主要的语言有类似C++/Java的语法。这些风格是由Combinator表达的。它们被用于软件行业的绝大多数公司。它们已经证明了自己，它们经过了试验和测试，它们符合逻辑，可以理解，并且为绝大多数专业编码人员 所熟悉。

试图推广其他东西，没有好处，只有缺陷，是一种失败。不承认这些缺陷，不过是固执己见。他们是客观的。很明显，MQ自己也在使用和迷恋这种风格，但这只是另一个错误。有时软件就是这样拒绝修复已知的错误，说已经有一堆第三方产品潜伏在这个错误的行为中。实际上，在所有这些情况下，我们应该寻找一种解决方案，允许我们保留旧的行为，以便向后兼容，但用所谓的 "协议升级 "或分叉进行修复。在样式方面，有一个简单的解决方案：一个 可定制的样式器。这可以说是已经做了一百次了。

顺便说一下，在MQ风格中，问题不仅涉及到括号，而且涉及到注释的风格--根据定义，它们不能胜过代码，这一点现在在MQ风格中被观察到。


我想补充的是关于评论--尝试用任何自动文档系统来处理它们，你会失望的。

 
Alexey Viktorov:

那么自作聪明是为了什么？


br-r-r-r-r，我举了一个没有空格和逗号的代码的例子

删除下划线。

 
Alexey Volchanskiy:

br-r-r-r-r，我举了一个没有空格和逗号的代码的例子

删除下划线

你给了谁一个没有空格的代码的例子？
 
Rashid Umarov:

你确实允许自己'呕吐'。

罗切，堵嘴有什么问题？我也有MQ的风格，我这么说是在讽刺吗？

你想怎么格式化kodobase就怎么格式化，它甚至可以在你加载代码时自动完成，而不会给编码者带来压力。我只记得：我写了代码，为MQ设计了样式，用一个新的名字保存，然后上传供审查。然后我取消造型，继续写作。这不是胡说八道吗？

我没有资源来做一个 可定制的造型器。又没有人让它适合。
但为什么要带着十字架，去告诉大家你的信仰是正确的（绝对没有任何争论！）？

12345678
新评论