코딩 스타일 정보 - 페이지 2

 

여기서 다음 두 가지 중 하나를 선택해야 합니다.

1) 코드를 작성하기 쉽고 가독성이 좋다.

2) 프로그램 실행 속도.

개인적으로 나는 항상 두 번째 옵션을 선호했기 때문에 전역 수준에서 모든 변수를 선언하고 가능하면 함수를 사용하지 않으려고 합니다(나는 이것이 계산 속도에 미치는 영향을 오랫동안 알아차렸습니다). 여기서 Expert Advisor가 컴퓨터에서 며칠 동안 회전하고 때로는 최적화가 필요한 경우 등을 이해해야 합니다. 따라서 컴퓨팅 속도와 낮은 리소스 소비가 매우 중요합니다.

이제 외부에서 다양한 프로그래밍 언어를 살펴보겠습니다. 예를 들어, Basic은 코딩하기 쉽고 가독성이 높지만 계산 속도가 빠릅니다. 이제 C++와 비교해 보겠습니다. 여기에서 극이 이미 변경되었습니다. 코딩은 더 어렵지만(코드 가독성이 나빠짐) 계산 속도는 크게 향상되었습니다. 그리고 어셈블러를 사용하면 코드를 거의 읽을 수 없습니다...

또 다른 점은 같은 언어로 작성된 프로그램도 이러한 기준에 속하고 코드의 가독성이나 프로그램의 속도 중 하나를 선택해야 하는 경우가 이상하다는 것입니다(여기서 이상한 점은 없지만 변수 선언은 시간 낭비; 함수를 참조하고 매개변수를 전달하십시오 - 시간 비용). 그러나 이것은 그런데 mql4뿐만 아니라 ...

 

나는 첫 번째 것을 선호하는데, 아마도 MQL4에서 가독성과 속도 사이에서 선택해야 하는 계산이 너무 광범위하기 때문일 것입니다. 나는 틱으로 플레이하지 않으므로 미친 계산 속도가 필요하지 않습니다.

반면에 나중에 수정하지 않아도 되는 그런 어드바이저는 상상하기 어렵습니다.

 
Mathemat >> :

나는 틱을 하지 않는다

여기에 일부 기능이 이미 등장하고 있습니다. 나는 절대적으로 동의합니다. 시작 가격으로 플레이한다면 프로그램의 아키텍처가 변경되어야 합니다. 예를 들어 공개 가격으로 플레이할 때 글로벌 수준에서 변수를 선언하고 다음 막대가 나타날 때까지 메모리에 보관하는 것은 의미가 없습니다.

프로그램의 코딩 스타일은 의도한 용도에 적합해야 합니다. 코딩 규칙은 모든 곳(함수, 변수 등)에서 동일하지만 프로그램 코드에서 이러한 규칙을 사용하는 빈도와 스타일은 프로그램이 사용되는 계산에 따라 특정 최종 작업에 따라 다릅니다. 코딩 규칙을 적용하는 각 경우에는 고유한 개별 접근 방식이 필요합니다.

 

강력히 추천합니다: http://astyle.sourceforge.net/ - C-텍스트 포맷터이지만 MQ4에서 훌륭하게 작동합니다.

단 하나의 명령: AStyle.exe -b -t -p before.mq4 는 "포장된" 텍스트를 사탕으로 바꿉니다.


 

오랫동안 여기에서 유사한 유틸리티를 제공하여 포럼 소유자가 여기 또는 메타 인용을 제공했습니다. 그러나 이제 볼 필요가 없습니다. 감사합니다. Sergey . 그리고 디자인 스타일은 내가 선호하는 것과 동일합니다.

 

한때 나는 "어떤 스타일의 프로그래밍을 선택할 것인가"에 대해 고민했습니다. 경험이 거의 없었기 때문에 간단하게 문제를 해결했습니다. FreeBSD 소스를 열고 Old School 프로그래머가 사용하는 스타일을 주의 깊게 살펴보았습니다. 그땐 뭔가 불편해 보였는데 왜 그런 솔루션을 선택했는지 이해가 갑니다.

그래서 제가 쓰는 규칙은 다음과 같습니다.

int main()

{

   int sum;

   for(int i=0;i<100;i++){

      sum+=i;

      Print("Число равно:", i);

   }

   return(0);

}

1. 함수에서 나는 항상 중괄호에 별도의 줄을 할당합니다. 루프/조건에서 첫 번째 줄에 첫 번째 중괄호를 넣습니다.

2. 저는 다음과 같이 중괄호를 넣는 매우 일반적인 스타일을 싫어합니다.

//+------------------------------------------------------------------+
//| expert start function |
//+------------------------------------------------------------------+
int start()
  {
//----
   
//----

  return(0);
  }
//+------------------------------------------------------------------+

댓글 //---- - 전혀 이해가 되지 않습니다.

3. 루프 자체에서 반복을 위한 변수를 선언하려고 합니다.

4. 기능을 사용하는 것을 좋아하고 프로그램을 여러 부분으로 나누려고 합니다. 그러나 함수당 20줄의 하드 바인딩은 없습니다. 함수가 로컬 작업을 수행해야 한다고 생각합니다. 작업은 크고 때로는 많지 않으므로 기능의 기능이 다릅니다.

5. 함수에서 함수를 사용합니다.

res=OrderSend(Symbol(),OP_BUY,GetVolume(GetPrice(OP_BUY),GetStopLossLevel(GetPrice(OP_BUY))),GetPrice(OP_BUY),3,GetStopLossLevel(GetPrice(OP_BUY)),GetTakeProfitLevel(GetPrice(OP_BUY)),"",GetMagicNumber(OP_BUY),0,Blue);


6. 나는 timing() 함수를 사용합니다:

void Timing()
{
  //Здесь вызываем функции которые необходимо вызывать каждый тик
  //...
  //Здесь вызываем функции которые необходимо вызывать каждую минуту
  if(IsNewMinute()==true){  
  }
  //Здесь вызываем вункции которые достаточно вызывать каждый новый бар
  if(IsNewBar()==true){
     CheckForClosed();
     CheckForOpen();
  }
  //Здесь вызываем функции которые необходимо вызывать каждый новый день, например функцию для расчета свопов
  if(IsNewDay()==true){
  }
}

보시다시피 틱 모델링 방법을 사용하더라도 전체 계산 블록은 틱마다 설정되지 않고 실제로 필요할 때만 호출됩니다.

7. 이유는 모르겠지만 거의 항상 while() 대신 for() 루프를 사용합니다.

8. 나는 중첩된 조건을 사용하는 것을 싫어합니다:

if(param1==1){

   if(param2==2){

      if(param3==3){

         if(param4==4){

            if(param5==5){

               Print("Наконец-то дошли!");

            }

         }

      }

   }

}

대신 다음 코드를 사용합니다.

if(param1!=1)return;

if(param2!=2)return;

...

if(param5!=5)return;

Print("Наконец-то дошли!");

이 방법이 훨씬 편리한 것 같아요.
 

if(param1!=1)return;

if(param2!=2)return;

...

if(param5!=5)return;

Print("Наконец-то дошли!");

원칙적으로 중첩된 if 구문과 동일한 계산을 수행하는 일반 코드입니다. 하지만 어디선가 함수에 반환이 하나만 있어야 한다고 들었습니다. 아마도 혼란스러워하지 않기 위해서일 것입니다. 나는 이 규칙을 엄격하게 따르지 않습니다.

그렇지 않으면 몇 가지 세부 사항을 제외하고 내 접근 방식이 C-4 와 매우 유사합니다.

 
C-4 >> :

2. 저는 다음과 같이 중괄호를 넣는 매우 일반적인 스타일을 싫어합니다.

//+------------------------------------------------------------------+
//| expert start function |
//+------------------------------------------------------------------+
int start()
  {
//----
   
//----
  return(0);
  }
//+------------------------------------------------------------------+

댓글 //---- - 전혀 이해가 되지 않습니다.

그리고 저는 반대로 정확히 이 스타일을 선호합니다. 줄 끝에서 중괄호를 찾을 필요가 없습니다. 이것이 바로 많은 사람들이 대괄호를 잃어버리거나(닫는 대괄호를 넣는 것을 잊음) 반대로 추가 닫는 대괄호를 없애는 이유입니다. 일반적으로 이것은 취향의 문제입니다. 종이에는 모든 사람의 필체가 다릅니다. 그리고 모든 사람은 자신의 방식으로 노트를 이끕니다(누군가 각주를 만들고, 누군가 밑줄을 긋고, 누군가 들여쓰기). 가장 중요한 것은 요약 작성자가 정보를 한 눈에 인식하는 것이 편리하다는 것입니다. 언어의 구문을 사용하면 적어도 한 줄에 중괄호를 어디에나 넣을 수 있습니다. 그러나 어떤 이유로 아무도 닫는 중괄호를 넣지 않습니다. 예를 들면 다음과 같습니다.

 if ( param1 = = 1 ) {

   if ( param2 = = 2 ) {

      if ( param3 = = 3 ) {

         if ( param4 = = 4 ) {

            if ( param5 = = 5 ) {

               Print ( "Наконец-то дошли!" ) ; } } } } }
따라서 코드를 쉽게 인식하기 위해 대괄호를 위한 별도의 줄에 공간을 절약하지 않습니다. 모든 대괄호(열기 및 닫기 모두)는 서로의 왼쪽에 있습니다(물론 다음 중첩 블록마다 들여쓰기됨 , 크리스마스 트리 스타일) 및 한 눈에 프로그램의 멋진 부분에 있는 복합 명령문(블록)의 시작과 끝을 평가할 수 있습니다. :)

--------

결국, 대괄호는 복합 연산자(블록)를 지정하기 위해 특별히 필요한 것이지, 주기의 본문을 지정하기 위한 것이 아닙니다. 연산자가 합성어가 아닌 경우 대괄호를 사용하지 않습니다.
 //--Например, так:

if ( param5 = = 5 ) Print ( "Наконец-то дошли!" ) ;


//--Или так:

if ( param5 = = 5 )
  Print ( "Наконец-то дошли!" ) ;

            

여는 대괄호가 오른쪽 어딘가에 있는 복합 연산자를 선택하고 닫는 대괄호를 왼쪽에 두는 경우:

 //---Вот так многие поступают выделяя блок:

if ( param5 = = 5 ) {
   Print ( "Наконец-то дошли!" ) ;
}


//--Т.е. блок выделяют вот так:

             {
   Print ( "Наконец-то дошли!" ) ;
}

---------------

코딩하는 방법, 대괄호를 넣을 위치 등 - 그것은 모두의 취향 문제입니다. 가장 중요한 것은 프로그램을 읽을 수 있고, 오류를 포함하지 않으며, 시스템을 로드하지 않으며(알고리즘이 최적이어야 함) 작성된 기준을 충족한다는 것입니다.

 
Mathemat >> :

오랫동안 여기에서 유사한 유틸리티를 제공하여 포럼 소유자가 여기 또는 메타 인용을 제공했습니다. 그러나 이제 볼 필요가 없습니다. 감사합니다, Sergey. 그리고 디자인 스타일은 내가 선호하는 것과 동일합니다.

예, 하나가 있습니다. :)


코드를 정리하기 위해 두 파일에서 MetaQuotes Styler를 사용합니다. 이 파일은 링크에서 다운로드하여 /Windows/System32 디렉터리에 배포해야 합니다.

다음 명령으로 스타일러를 시작할 수 있습니다.

mqstyler.exe /파일:파일명.mq4
mqstyler.exe /file:"spaces.mq4가 있는 긴 파일 이름"(이름에 공백이 있는 경우)

 

저는 개인적으로 Visual Studio (VC++)를 가져와서 거기에 MQL 코드를 복사하고 도구 없이 Microsoft 규칙에 따라 형식을 지정합니다. 코드 편집기로서 VS도 더 시원합니다(코드 접기?). 아마도 컴파일 명령을 망칠 수 있지만 아직 시도하지 않았습니다.