저를 믿으세요. 이렇게 쓰는 것은 스타일이나 간결함의 원칙을 위해서가 아니라 정말 저에게 더 쉽기 때문입니다.
가장 간단한 반품을 가져왔습니다. 솔직히 말해서, 나는 그에게 무슨 문제가 있는지 조금도 이해하지 못합니다.
C++ 코드를 전혀 모르기 때문에 읽을 수 없음을 고백합니다. 그러나 사람들은 그것에 씁니다. 그래서 그것은 단지 무지의 문제입니다.
아마도 우리는 코드의 단순성에 대해 다른 생각을 가지고 있을 것입니다.
나는 당신이 프로그래밍 분야에서 훌륭한 전문가라는 것을 이해합니다. 그러나 모든 일에서 최대의 생산성을 추구하면서 노동 생산성 을 잊어서는 안됩니다. 코드 가독성에서 시작됩니다. 가독성 때문에 코드를 압축하려는 욕구를 정당화하는 것이 무엇인지 나에게는 명확하지 않지만 이것이 대규모(독립) 프로젝트에서 완전히 받아들일 수 없다는 사실은 나에게 완전히 명백합니다.
솔직히 말해서 C++이 너무 읽기 어렵다는 것은 참을 수 없습니다. 존재를 쉽게 피할 수 있는 엔터티의 힙입니다. 그리고 그것은 더 좋아질 것입니다. 더 넓습니다.
추신. 개발 시 코드는 가독성 때문이 아니라 최상의 솔루션으로 인해 압축되어야 하며 가능한 한 가독성을 유지해야 한다고 생각합니다. 코드를 이해하는 속도는 자신의 작업 생산성에 매우 중요합니다.
Индекс производительности труда показывает изменение объема выпущенной продукции, приходящегося на одного работника. Этот показатель полезен для предсказания инфляции и прироста объема производства. Если стоимость труда увеличивается соответственно увеличению производительности, и, кроме того, маловероятно увеличение производственных издержек...
특히 이 스타일로 작성하면 한 화면에 수십 가지 이상의 기능을 표시할 수 있으므로 코드 작업이 더 쉬워지기 때문에 몇 분 이상 검색하지 않을 것입니다.
왠지 의심스럽습니다.
다음은 실행 유형을 반환 하는 함수의 실제 코드입니다.
// Для МТ4 - возвращает otfFilingType.
// Для МТ5 - возвращает тип исполнения ордера, равный otfFilingType, если он доступен на символе strSymbol, иначе - корректный вариант.
ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType = ORDER_FILLING_FOK)
{
#ifndef __MQL5__
return(otfFilingType);
#else // __MQL5__
// Функцию предложил fxsaber. Серьезной проверки не было - полагаемся на его авторитет.
const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = (ENUM_SYMBOL_TRADE_EXECUTION)::SymbolInfoInteger(strSymbol, SYMBOL_TRADE_EXEMODE);
const int iFillingMode = (int)::SymbolInfoInteger(strSymbol, SYMBOL_FILLING_MODE);
보시다시피 코드/스타일은 매우 간단합니다. 그러나 동일한 코드를 다시 작성할 수 있는 경우에만 오류 또는 부재를 감지할 수 있습니다. 이것은 정말 오랜 시간이 걸릴 것입니다. 왜냐하면. 문제를 완전히 이해해야 합니다.
따라서 생성 단계에서 복잡한 것은 핥아(스트레스 테스트 작성) mqh를 연결하는 간단한 형태로 사용하는 것이 원칙입니다. 보시다시피 이해의 복잡성은 스타일이나 간결성에 의해 항상 결정되는 것은 아닙니다.
순수한 언어 구성의 또 다른 예인 TypeToBytes가 있습니다. 이해하는 데에는 전혀 다른 수준의 어려움이 있습니다. 그리고 거기에서 매크로가 없으면 나는 시들 것입니다. 즉, 매크로를 사용하기 때문에 소스 코드에 매우 빠르게 들어가는 것으로 나타났습니다. 매크로는 대부분 간결함을 위한 것이 아니라 이해를 위한 것이기 때문입니다.
그리고 간단하지만 잊어버릴 수 있는 많은 함정을 고려해야 하는 또 다른 경우가 있습니다. 이것은 MT4Orders에서 일어나는 일입니다. 따라서 일부 행에는 자신에게만 적용되는 주석이 수반됩니다. 코드를 이해하는 데 도움이 됩니다.
그러나 이것들은 모두 mqh이므로 참여할 필요가 없습니다. 그리고 차량 코드는 mqh를 사용하여 매우 간단하게 작성됩니다. 일반 iHigh 기능의 소스 코드를 보기 위해 올라가지 않습니다. 그러나 그는 실제로 괴물입니다. 당신은 그들을 사용합니다. 라이브러리에서도 마찬가지입니다. 동일한 일반 성경을 사용하기 위해서는 완전한 이해가 필요하지 않습니다.
MT4 Expert Advisors 및 해당 MT5 포트에 대해서는 KB를 참조하십시오. MT5 포트는 이해하기 힘든 작업입니다. 간결함의 냄새가 나지 않을 뿐만 아니라(코드가 원본보다 몇 배 더 큼) mqh 파일에서 고려되지 않은 MT5 함정의 덜거덕거림도 있습니다.
코드를 해석하지는 않겠지만 어떻게든 템플릿의 일부를 게시했는데 비슷한 접근 방식이 있습니다. 두 개의 모니터 스크롤에서 if로 발보를 늘리는 것을 좋아하지 않습니다.
이 경우 함수를 사용하는 것이 좋습니다.
그리고 당신이 코드를 해석하지 않았다는 사실은 당신도 그것이 어떻게 작동하는지 바로 이해할 수 없다는 것을 의미합니다. 여기에서 괄호에 대한 주의 깊은 분석, 바로 이러한 "질문"과 논리적 "또는"이 필요합니다. 그러나 프로그램의 "병목 현상"에 사용되는 보다 효율적인 코드를 제공하는 경우 이러한 "쌓임"은 매우 제한된 경우에 허용됩니다. 이 경우 실행 유형을 얻는 것은 어떤 식으로든 "병목 현상"이 될 수 없으며 이러한 코드는 여기에서 바람직하지 않습니다. fxsaber의 권한과 여러 자체 검사를 기반으로 단독으로 사용합니다. 그러나 이것은 예외입니다. 원칙적으로 본인이 자세히 파악하지 못한 코드는 사용하지 않습니다.
기능은 정말 잘 작동합니다. 여러 번 확인했는데 오류가 없었습니다. 그러나이 끔찍한 반환에서 결과가 어떻게 형성되는지 - 내 의견으로는 꽤 좋은 경험에도 불구하고 이해하지 못했습니다. 또한 fxsaber 자신은 자신이 이것을 기억하지 못한다는 질문에 대답했습니다.
반환에 관한 것이 아닙니다. if-else 형식으로 동일한 논리를 작성하면 더 이상 이해하지 못할 것입니다. 이것은 "지지되지 않는 충전" 문제를 매우 깊이 연구한 경우입니다. 이렇게 하려면 수반되는 많은 스트레스 코드를 작성하고 다른 토러스 서버에서 많은 계정을 열고 모든 기호를 살펴봐야 합니다. 다양한 플래그 조합 중에서 패턴을 찾습니다. 마지막으로 모든 테이블을 하나의 공통 분모로 가져옵니다. "기억나지 않는다" 입니다.
문제가 더 이상 발생하지 않고 안전하게 잊어버렸습니다. 한 번 작성한 코드로 돌아갈 필요가 없을 때 좋습니다. 작동 - 중요한 것.
내 스타일의 예?
예를 들어 다음과 같습니다.
100개의 함수가 있고 각각이 그러한 레코드를 반환한다고 상상해보십시오. 이 항목 중 오류를 찾고 있습니다. 언제까지 검색할 것인가?
예를 들어 다음과 같습니다.
100개의 함수가 있고 각각이 그러한 레코드를 반환한다고 상상해보십시오. 이 항목 중 오류를 찾고 있습니다. 언제까지 검색할 것인가?
특히 이 스타일로 작성하면 한 화면에 수십 가지 이상의 기능을 표시할 수 있으므로 코드 작업이 더 쉬워지기 때문에 몇 분 이상 검색하지 않을 것입니다.
예를 들어 다음과 같습니다.
100개의 함수가 있고 각각이 그러한 레코드를 반환한다고 상상해보십시오. 이 항목 중 오류를 찾고 있습니다. 언제까지 검색할 것인가?
저를 믿으세요. 이렇게 쓰는 것은 스타일이나 간결함의 원칙을 위해서가 아니라 정말 저에게 더 쉽기 때문입니다.
가장 간단한 반품을 가져왔습니다. 솔직히 말해서, 나는 그에게 무슨 문제가 있는지 조금도 이해하지 못합니다.
C++ 코드를 전혀 모르기 때문에 읽을 수 없음을 고백합니다. 그러나 사람들은 그것에 씁니다. 그래서 그것은 단지 무지의 문제입니다.
저를 믿으세요. 이렇게 쓰는 것은 스타일이나 간결함의 원칙을 위해서가 아니라 정말 저에게 더 쉽기 때문입니다.
가장 간단한 반품을 가져왔습니다. 솔직히 말해서, 나는 그에게 무슨 문제가 있는지 조금도 이해하지 못합니다.
C++ 코드를 전혀 모르기 때문에 읽을 수 없음을 고백합니다. 그러나 사람들은 그것에 씁니다. 그래서 그것은 단지 무지의 문제입니다.
아마도 우리는 코드의 단순성에 대해 다른 생각을 가지고 있을 것입니다.
나는 당신이 프로그래밍 분야에서 훌륭한 전문가라는 것을 이해합니다. 그러나 모든 일에서 최대의 생산성을 추구하면서 노동 생산성 을 잊어서는 안됩니다. 코드 가독성에서 시작됩니다. 가독성 때문에 코드를 압축하려는 욕구를 정당화하는 것이 무엇인지 나에게는 명확하지 않지만 이것이 대규모(독립) 프로젝트에서 완전히 받아들일 수 없다는 사실은 나에게 완전히 명백합니다.
솔직히 말해서 C++이 너무 읽기 어렵다는 것은 참을 수 없습니다. 존재를 쉽게 피할 수 있는 엔터티의 힙입니다. 그리고 그것은 더 좋아질 것입니다. 더 넓습니다.
추신. 개발 시 코드는 가독성 때문이 아니라 최상의 솔루션으로 인해 압축되어야 하며 가능한 한 가독성을 유지해야 한다고 생각합니다. 코드를 이해하는 속도는 자신의 작업 생산성에 매우 중요합니다.
ZYY. 스레드는 훌륭합니다. 고맙습니다.
정수 외부에서 무엇을 얻을 수 있는지 생각해 보십시오.
따라서 LONG_MAX 를 확인하십시오 - double을 long으로 변환하기 전에도 있어야 합니다. 반올림 함수는 정수에 맞지 않는 값을 위해 설계되지 않은 것이 분명합니다. 그리고 그것은 문제를 바꾸지 않습니다.
함수가 double을 반환하고 이를 long으로 변환하면 동일한 오버플로 위험이 발생합니다.
개인적으로, 반올림 직전에는 항상 경계 값에 대한 assert-check가 있으며, 프로그램 논리에 따라 항상 정수의 최대값보다 큰 값이 변환에 올 수 없도록 항상 확인합니다.
특히 이 스타일로 작성하면 한 화면에 수십 가지 이상의 기능을 표시할 수 있으므로 코드 작업이 더 쉬워지기 때문에 몇 분 이상 검색하지 않을 것입니다.
왠지 의심스럽습니다.
다음은 실행 유형을 반환 하는 함수의 실제 코드입니다.
기능은 정말 잘 작동합니다. 여러 번 확인했는데 오류가 없었습니다. 그러나이 끔찍한 반환에서 결과가 어떻게 형성되는지 - 내 의견으로는 꽤 좋은 경험에도 불구하고 이해하지 못했습니다. 또한 fxsaber 자신은 자신이 이것을 기억하지 못한다는 질문에 대답했습니다.
Vitaly, 이 코드가 어떻게 작동하는지 알려주십시오. 어렵지 않다면 비슷한 스타일로 "몇 분 안에 이해"하세요!
나는 return 문 에서 "대괄호를 열고" 모든 "질문"을 if로 바꾸고 논리적 "or"를 통해 찾은 값을 반환합니다. 개인적으로 "질문" 연산자는 저를 짜증나게 합니다. 유사한 if와 똑같은 코드를 제공하지만 가독성이 훨씬 떨어집니다.
왠지 의심스럽습니다.
다음은 실행 유형을 반환 하는 함수의 실제 코드입니다.
기능은 정말 잘 작동합니다. 여러 번 확인했는데 오류가 없었습니다. 그러나이 끔찍한 반환에서 결과가 어떻게 형성되는지 - 내 의견으로는 꽤 좋은 경험에도 불구하고 이해하지 못했습니다. 또한 fxsaber 자신은 자신이 이것을 기억하지 못한다는 질문에 대답했습니다.
Vitaly, 이 코드가 어떻게 작동하는지 알려주십시오. 어렵지 않다면 비슷한 스타일로 "몇 분 안에 이해"하세요!
나는 return 문 에서 "대괄호를 열고" 모든 "질문"을 if로 바꾸고 논리적 "or"를 통해 찾은 값을 반환합니다. 개인적으로 "질문" 연산자는 저를 짜증나게 합니다. 유사한 if와 똑같은 코드를 제공하지만 가독성이 훨씬 떨어집니다.
코드를 해석하지는 않겠지만 어떻게든 템플릿의 일부를 게시했는데 비슷한 접근 방식이 있습니다. 두 개의 모니터 스크롤에서 if로 발보를 늘리는 것을 좋아하지 않습니다.
노동 생산성 을 잊지 마십시오. 코드 가독성에서 시작됩니다.
지금은 전혀 이해할 수 없는 내 코드의 예입니다. 그리고 이해를 위해서는 많은 요인들을 잘 살펴보아야 합니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
Init() 및 DeInit() 실행 순서
fxsaber , 2017.04.14 23:35
보시다시피 코드/스타일은 매우 간단합니다. 그러나 동일한 코드를 다시 작성할 수 있는 경우에만 오류 또는 부재를 감지할 수 있습니다. 이것은 정말 오랜 시간이 걸릴 것입니다. 왜냐하면. 문제를 완전히 이해해야 합니다.
따라서 생성 단계에서 복잡한 것은 핥아(스트레스 테스트 작성) mqh를 연결하는 간단한 형태로 사용하는 것이 원칙입니다. 보시다시피 이해의 복잡성은 스타일이나 간결성에 의해 항상 결정되는 것은 아닙니다.
순수한 언어 구성의 또 다른 예인 TypeToBytes가 있습니다. 이해하는 데에는 전혀 다른 수준의 어려움이 있습니다. 그리고 거기에서 매크로가 없으면 나는 시들 것입니다. 즉, 매크로를 사용하기 때문에 소스 코드에 매우 빠르게 들어가는 것으로 나타났습니다. 매크로는 대부분 간결함을 위한 것이 아니라 이해를 위한 것이기 때문입니다.
그리고 간단하지만 잊어버릴 수 있는 많은 함정을 고려해야 하는 또 다른 경우가 있습니다. 이것은 MT4Orders에서 일어나는 일입니다. 따라서 일부 행에는 자신에게만 적용되는 주석이 수반됩니다. 코드를 이해하는 데 도움이 됩니다.
그러나 이것들은 모두 mqh이므로 참여할 필요가 없습니다. 그리고 차량 코드는 mqh를 사용하여 매우 간단하게 작성됩니다. 일반 iHigh 기능의 소스 코드를 보기 위해 올라가지 않습니다. 그러나 그는 실제로 괴물입니다. 당신은 그들을 사용합니다. 라이브러리에서도 마찬가지입니다. 동일한 일반 성경을 사용하기 위해서는 완전한 이해가 필요하지 않습니다.
MT4 Expert Advisors 및 해당 MT5 포트에 대해서는 KB를 참조하십시오. MT5 포트는 이해하기 힘든 작업입니다. 간결함의 냄새가 나지 않을 뿐만 아니라(코드가 원본보다 몇 배 더 큼) mqh 파일에서 고려되지 않은 MT5 함정의 덜거덕거림도 있습니다.
코드를 해석하지는 않겠지만 어떻게든 템플릿의 일부를 게시했는데 비슷한 접근 방식이 있습니다. 두 개의 모니터 스크롤에서 if로 발보를 늘리는 것을 좋아하지 않습니다.
이 경우 함수를 사용하는 것이 좋습니다.
그리고 당신이 코드를 해석하지 않았다는 사실은 당신도 그것이 어떻게 작동하는지 바로 이해할 수 없다는 것을 의미합니다. 여기에서 괄호에 대한 주의 깊은 분석, 바로 이러한 "질문"과 논리적 "또는"이 필요합니다. 그러나 프로그램의 "병목 현상"에 사용되는 보다 효율적인 코드를 제공하는 경우 이러한 "쌓임"은 매우 제한된 경우에 허용됩니다. 이 경우 실행 유형을 얻는 것은 어떤 식으로든 "병목 현상"이 될 수 없으며 이러한 코드는 여기에서 바람직하지 않습니다. fxsaber의 권한과 여러 자체 검사를 기반으로 단독으로 사용합니다. 그러나 이것은 예외입니다. 원칙적으로 본인이 자세히 파악하지 못한 코드는 사용하지 않습니다.
기능은 정말 잘 작동합니다. 여러 번 확인했는데 오류가 없었습니다. 그러나이 끔찍한 반환에서 결과가 어떻게 형성되는지 - 내 의견으로는 꽤 좋은 경험에도 불구하고 이해하지 못했습니다. 또한 fxsaber 자신은 자신이 이것을 기억하지 못한다는 질문에 대답했습니다.
반환에 관한 것이 아닙니다. if-else 형식으로 동일한 논리를 작성하면 더 이상 이해하지 못할 것입니다. 이것은 "지지되지 않는 충전" 문제를 매우 깊이 연구한 경우입니다. 이렇게 하려면 수반되는 많은 스트레스 코드를 작성하고 다른 토러스 서버에서 많은 계정을 열고 모든 기호를 살펴봐야 합니다. 다양한 플래그 조합 중에서 패턴을 찾습니다. 마지막으로 모든 테이블을 하나의 공통 분모로 가져옵니다. "기억나지 않는다" 입니다.
문제가 더 이상 발생하지 않고 안전하게 잊어버렸습니다. 한 번 작성한 코드로 돌아갈 필요가 없을 때 좋습니다. 작동 - 중요한 것.