표준 기능/접근법의 대체 구현 - 페이지 9

새 코멘트
 
fxsaber :

문제가 더 이상 발생하지 않고 안전하게 잊어버렸습니다. 한 번 작성한 코드로 돌아갈 필요가 없을 때 좋습니다. 작동 - 중요한 것.

괜찮은. 나 자신은 항상 이것을합니다 (그리고 이번에도 볼 수 있듯이).

갑자기 무언가가 바뀌면 문제가 발생합니다. 코드가 명확하고 명확하지 않은 위치에 주석이 잘 달렸을 때 일부 변경 사항이 있는 오류의 원인을 쉽게 식별할 수 있습니다. 그러나 그러한 경우 "잊었다" - 수정하는 것이 훨씬 더 어렵습니다.

네, 이런 경우가 드물다는 것은 분명합니다... 하지만 이러한 매우 드문 경우는 개인적으로 저를 매우 긴장하게 만듭니다. 그래서 그런 상황에서 최대한 이해하기 쉬운 코드를 작성하려고 노력하고, 눈에 띄지 않는 부분에 대해서는 자세하게 댓글을 달고 있습니다.

 
fxsaber :

지금은 전혀 이해할 수 없는 내 코드의 예입니다. 그리고 이해를 위해서는 많은 요소들을 잘 살펴보아야 합니다.


보시다시피 코드/스타일은 매우 간단합니다. 그러나 동일한 코드를 다시 작성할 수 있는 경우에만 오류 또는 부재를 감지할 수 있습니다. 이것은 정말 오랜 시간이 걸릴 것입니다. 왜냐하면. 문제를 완전히 이해해야 합니다.

따라서 생성 단계에서 복잡한 것은 핥아(스트레스 테스트 작성) mqh를 연결하는 간단한 형태로 사용하는 것이 원칙입니다. 보시다시피 이해의 복잡성은 스타일이나 간결성에 의해 항상 결정되는 것은 아닙니다.


순수한 언어 구성의 또 다른 예인 TypeToBytes가 있습니다. 완전히 다른 차원에서 이해하기에는 어려움이 있습니다. 그리고 거기에서 매크로가 없으면 나는 시들 것입니다. 즉, 매크로를 사용하기 때문에 소스 코드에 매우 빠르게 들어가는 것으로 나타났습니다. 매크로는 대부분 간결함을 위한 것이 아니라 이해를 위한 것이기 때문입니다.


그리고 간단하지만 잊어버릴 수 있는 많은 함정을 고려해야 하는 또 다른 경우가 있습니다. 이것은 MT4Orders에서 일어나는 일입니다. 따라서 일부 행에는 자신에게만 적용되는 주석이 수반됩니다. 코드를 이해하는 데 도움이 됩니다.


그러나 이것들은 모두 mqh이며 작업에 참여할 필요가 없습니다. 그리고 차량 코드는 mqh를 사용하여 매우 간단하게 작성됩니다. 일반 iHigh 기능의 소스 코드를 보기 위해 올라가지 않습니다. 그러나 그는 실제로 괴물입니다. 당신은 그들을 사용합니다. 라이브러리에서도 마찬가지입니다. 동일한 일반 성경을 사용하기 위해서는 완전한 이해가 필요하지 않습니다.


MT4 Expert Advisors 및 해당 MT5 포트에 대해서는 KB를 참조하십시오. MT5 포트는 이해하기 힘든 작업입니다. 간결함의 냄새가 나지 않을 뿐만 아니라(코드가 원본보다 몇 배 더 큼) mqh 파일에서 고려되지 않은 MT5 함정의 덜거덕거림도 있습니다.

솔직히, 나는 여기서 논쟁할 것이 없습니다. 분명히, 프로그래밍에 대한 접근 방식에서 시작하면 모든 것이 정확하지만(과도하고 정당하지 않은 코드 압축의 경우를 제외하고), 내 접근 방식에서 시작하면 많은 것이 잘못된 것입니다.

1. 물론 찾기 어려운 버그는 매우 간단한 코드에서도 숨길 수 있습니다. 그러나 쓰기 어려운 분야에서는 그것을 찾는 것이 훨씬 더 어렵습니다. 의미를 풀기 위한 정신적 노력을 고려하십시오. 많은 작업을 수행해야 하는 경우(많은 기능 작성, 새로운 메커니즘 구축, 기존 메커니즘에 성공적으로 통합) 시간과 노력을 절약하는 것이 가장 중요합니다. 그것은 코드의 "아름다움"에 달려 있지 않습니다. 스타일용이 아닙니다. 한밤중에 눈을 떴을 때 스스로 읽고 최대한 빨리 이해할 수 있도록 코드를 작성해야 합니다. 자신을 최대한 활용하기 위해 코드를 빌드하는 완벽한 방법을 찾기 시작합니다. 그리고 이것을 보면:

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

그러한 기록의 모든 단점을 즉시 이해합니다.

1. 등장인물이 많다.

2. 과도한 "포장".

3. 주석이 없는 수학 연산.

그러한 코드를 묻는 것은 압도할 수 없습니다. 힘의 한계까지 일하고 매우 피곤하면 마스터하기도 어렵습니다. 매일 이렇게 일한다고 상상해보십시오. 그러한 코드에서 즉시 외면할 것입니다.


2. 남의 코드 안보고 그냥 접속?

나는 크고 진지하며 가장 중요한 고품질 프로그램은 다른 사람들의 블록에서 간단한 조립으로 만들어지지 않는다고 믿습니다. 일부만 만들고 나머지를 연결하면 효과적인 프로그램을 만들 수 없습니다. 비네그레트가 있을 것입니다.

작동할 수 있으며 작동할 것입니다. 그러나 이들은 "무릎 꿇는" 프로그램입니다.

나는 개발자가 보지도 않는 블록으로 구성된 프로그램의 효율성을 믿지 않습니다. 이것은 픽션입니다. 프로그램은 절름발이이며 솔루션은 비효율적입니다. 많은 문제가 있을 것입니다. 프로그래머가 한 팀으로 작업하여 공통 문제를 해결하면 좋지만, 다른 사람들(아직도 살펴보지 않는)의 다른 프로그램 사이에 "떠다니는" 솔루션이 사용된다면 이는 관점에서 볼 때 넌센스입니다. 효율성의.

 
Реter Konow :

작동할 수 있으며 작동할 것입니다. 그러나 이들은 "무릎 꿇는" 프로그램입니다.

내 출판물을 KB에서 볼 수 있습니다. 누군가 사용하고 있어야 합니다.

나는 나 자신을 위해 그리고 무릎을 꿇고만 씁니다. 출판물은 부산물입니다.

 
Georgiy Merts :

따라서 LONG_MAX 를 확인하십시오 - double을 long으로 변환하기 전에도 있어야 합니다. 반올림 함수는 정수에 맞지 않는 값을 위해 설계되지 않은 것이 분명합니다. 그리고 그것은 문제를 바꾸지 않습니다.

함수가 double을 반환하고 이를 long으로 변환하면 동일한 오버플로 위험이 발생합니다.

개인적으로, 반올림 직전에는 항상 경계 값에 대한 assert-check가 있으며, 프로그램 논리에 따라 항상 정수의 최대값보다 큰 값이 변환에 올 수 없도록 항상 확인합니다.

당신은 종종 char에 long을 캐스팅합니까? double과 동일합니다. 이것은 계층 구조의 마지막 단계입니다. 들어갈 수 없습니다. 대부분의 경우 이것이 필요하지 않습니다. 표준에서는 모든 것이 함께 작동합니다. 위계질서를 무너뜨리거나 땀을 흘리지 마십시오.

LONG_MAX/MIN에 대한 검사를 추가하십시오. 그러면 성능 테스트가 그렇게 장밋빛이 되지 않을 것이라는 내용이 있습니다. 그리고 그 사람은 std 교체를 선택했는데, 이는 전체 값 범위에서 작동해야 함을 의미합니다.

 
pavlick_ :

당신은 자주 char에 long을 캐스팅합니까? double과 동일합니다. 이것은 계층 구조의 마지막 단계입니다. 들어갈 수 없습니다. 대부분의 경우 이것이 필요하지 않습니다. 표준에서는 모든 것이 함께 작동합니다. 위계질서를 무너뜨리거나 땀을 흘리지 마십시오.

LONG_MAX/MIN에 대한 검사를 추가하십시오. 그러면 성능 테스트가 그렇게 장밋빛이 되지 않을 것이라는 내용이 있습니다. 그리고 그 사람은 std 교체를 선택했는데, 이는 전체 값 범위에서 작동해야 함을 의미합니다.

long to ulong (또는 그 반대) - 항상.

긴 문자는 드뭅니다.

정수 연산과 부동 연산의 결과가 크게 다르기 때문에 변환이 필요합니다. 그리고 실행 속도는 이론적으로 정수 데이터가 더 빠릅니다.

범위 검사에 관해서는 - 강조했지만 ASSERT할 가치가 있습니다. 즉, 이러한 검사는 DEBUG 버전에서만 작동합니다. 모든 공개 기능을 시작할 때 들어오는 모든 매개변수는 항상 assert를 사용하여 허용 가능한 범위에 대해 확인되며 이는 두 번 이상 도움이 되었습니다. RELEASE 버전 - 물론 확인 없이 이미 작동합니다.

 
fxsaber :

내 출판물을 KB에서 볼 수 있습니다. 누군가 사용하고 있어야 합니다.

나는 나 자신을 위해 그리고 무릎을 꿇고만 씁니다. 출판물은 부산물입니다.

나는 당신의 경험과 전문성을 의심하지 않습니다.

간단히 말해서, 몇 년 동안 힘들고 매일 프로그래밍하고 개발하는 과정에서 특정 코드, 솔루션 또는 접근 방식의 이점을 과대평가하기 시작합니다. 그리고 종종 매우 이상한 결론에 도달합니다... 이상하지만 방대한 연습으로 입증되었습니다.

저는 제 관점을 공유했을 뿐입니다.

 
Georgiy Merts :

정수 연산과 부동 연산의 결과가 크게 다르기 때문에 변환이 필요합니다.

나는 어떤 상황에서 복식으로 뭔가를 제대로 할 수 없는지 상상할 수 없습니다. Lua(quik에 연결됨)에는 정수 유형 이 없고 double만 있고 아무것도 없습니다.

 
pavlick_ :

나는 어떤 상황에서 복식으로 뭔가를 제대로 할 수 없는지 상상할 수 없습니다.

카운터.

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

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

double 은 전체 범위 내 정보를 잃지 않습니다. 이것은 long 의 경우가 아닙니다 .

Особенности языка mql5, тонкости и приёмы работы
Особенности языка mql5, тонкости и приёмы работы
  • 2018.01.15
  • www.mql5.com
В данной теме будут обсуждаться недокументированные приёмы работы с языком mql5, примеры решения тех, или иных задач...
 
fxsaber :

카운터.

글쎄, 당신은 여전히 너무 많이 계산해야합니다)). 그리고 정말로 원한다면 옵션이 아닌 것은 무엇입니까?

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

글쎄, 당신은 여전히 너무 많이 계산해야합니다)). 그리고 정말로 원한다면 옵션이 아닌 것은 무엇입니까?

예, 변태가 가능하다는 것은 분명합니다. 하지만 그만한 가치가 있습니까?

변수의 의미에 따라 정수값만 있어야 한다면 부동값을 쓸 수 없도록 정수여야 한다고 생각합니다. 변수의 유형 또는 반환 값 자체는 이미 변수에 대한 중요한 정보와 부분적으로 알고리즘에 대한 정보를 전달합니다. 모든 곳에서 부동 값을 사용하면 이 정보가 손실됩니다.

그리고 내 생각에 알고리즘에 따라 정수도 부호 있는 또는 부호 없는 것으로 선언되어야 하며, 또한 반드시 길지 않을 수도 있고, 아마도 "더 짧을 수도" 있습니다. 코드를 보기 위해 - 즉시 이해할 수 있는 범위 이 변수가 허용 하는 값 .

Lua에 정수 값이 없다는 사실은 제 생각에는 심각한 마이너스입니다.

12345678910111213
새 코멘트