많은 소프트웨어 회사에서는 그러한 코드에 대해 모든 손가락을 때릴 것입니다. 항상 어디서나 필요한 첫 번째 것은 "추가 읽기"가 없다는 것입니다. 예를 들어, 함수를 입력할 때 조건이 사용되는 경우:
다음과 같이 작성하는 것이 좋습니다.
이 접근 방식은 중첩 조건에 많은 도움이 됩니다.
다시 한 번 - 손가락을 치십시오. 결국 아무도 OrderType() 함수가 반환한 내용을 확인하지 않았습니다. 아니면 그녀가 -1 또는 6을 반환했습니까? 이것은 컴파일러 속성에 대한 바인딩의 예이며 항상 멀리해야 합니다. 당신은 크로스 플랫폼 코드의 많은 예를 제공합니다. 그렇다면 왜 이 사건에 그를 놔두는 겁니까? MQ의 새 컴파일러가 릴리스되고 이 코드는 더 이상 올바르게 작동하지 않습니다.
소프트웨어 회사는 논의 중인 내용과 어떤 관련이 있습니까? 코드는 작동을 멈추지 않을 것입니다. 여기서 부정행위를 할 필요는 없습니다.
같은 상황을 계속합니다. 유형 코드:
다음보다 읽기가 더 어렵습니다.
그러나 두 경우 모두 실행 효율성은 동일합니다.
이 경우 한 줄의 코드가 여섯 줄의 코드보다 읽기 쉽습니다. 게다가 논리적이기 때문에 사이클 내부의 필요성에 어떤 식으로든 묶여 있지 않습니다. 저것들. 첫 번째 옵션은 침착하게 복사하여 붙여 넣을 수 있으며 두 번째 옵션은 아니요.
RTFM (изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству») — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства.
이해할 수 있는 코드입니다. 그리고 방금 문서를 보고 코드를 본 사람들은 즉시 궁금해하기 시작할 것입니다. 배열의 크기가 8이고 문서에 6개의 주문 유형 만 있는 이유는 무엇입니까?
그리고 개인적으로는 조건을 따로따로 읽는게 더 편합니다. 이와 같이:
나는 또한 이것보다 더 기분이 좋다.
하지만 그것은 취향과 습관의 문제라고 생각합니다 . 누구도 강요하거나 증명할 필요가 없습니다.
한편 다음과 같이 동의합니다.
그리고 이것은 논리적이라고 생각하고 다른 때는 기억이 나지 않습니다.
다음은 키워드입니다.
개인적으로 나는 일반적으로 계속 쓰기에 짜증이 난다.
그들의 의미는 무엇입니까???? 당신이 읽는 경우
if ( OrderSelect (i, SELECT_BY_POS ) && OrderSymbol () == Symbol () && OrderMagicNumber () == m_nMagicNumber)
모든 것이 러시아어로 읽힙니다.
주문이 선택되고 주문의 기호가 "우리"이고 마법도 우리의 것이라면... 우리는 중괄호로 묶인 모든 것을 실행합니다.
그러나 러시아어로 어떻게 들리지 않습니까?
오더 선택 안되면 지옥가자...
주문 기호가 우리가 아니면 지옥에 가자
등.
몇 번이나 그곳으로 자신을 보내야 하는지.......
분명히 mql3에서는 이것이 의미가 있었습니다. 이를 통해 상태 확인 시간을 단축할 수 있습니다. 그런 다음 모든 조건을 처음부터 끝까지 확인했습니다. 그러나 결국 오랜 시간 동안 상황이 수정되었으며, 확인이 조건을 충족하지 못하면 추가 확인이 중지됩니다. 그리고 이 모든 트릭은 전혀 말이 되지 않습니다.
주문이 선택되고 주문의 기호가 "우리"이고 마법도 우리의 것이라면... 우리는 중괄호로 묶인 모든 것을 실행합니다.
그러나 러시아어로 어떻게 들리지 않습니까?
오더 선택 안되면 지옥가자...
주문 기호가 우리가 아니면 지옥에 가자
등.
몇 번이나 그곳으로 자신을 보내야 하는 건지.......
분명히 mql3에서는 이것이 의미가 있었습니다. 이를 통해 상태를 확인하는 시간이 단축되었습니다. 그런 다음 모든 조건을 처음부터 끝까지 확인했습니다. 그러나 결국 오랜 시간 동안 상황이 수정되었으며, 확인이 조건을 충족하지 못하면 추가 확인이 중지됩니다. 그리고 이 모든 트릭은 전혀 말이 되지 않습니다.
당신은 이것이 습관의 문제라는 데 동의했습니다. 예를 들어, 불필요한 중첩에 짜증이 나서 항상 반환을 통해 제거합니다. 계속합니다. 그리고 "지옥에 가자" 대신 "조건 1과 2가 충족됨"을 읽는 데 익숙해지기 쉽습니다.
많은 소프트웨어 회사에서는 그러한 코드에 대해 모든 손가락을 때릴 것입니다. 항상 어디서나 필요한 첫 번째 것은 "추가 읽기"가 없다는 것입니다. 예를 들어, 함수를 입력할 때 조건이 사용되는 경우:
다음과 같이 작성하는 것이 좋습니다.
이 접근 방식은 중첩 조건에 많은 도움이 됩니다.
다시 한 번 - 손가락을 치십시오. 결국 아무도 OrderType() 함수가 반환한 내용을 확인하지 않았습니다. 아니면 그녀가 -1 또는 6을 반환했습니까? 이것은 컴파일러 속성에 대한 바인딩의 예이며 항상 멀리해야 합니다. 당신은 크로스 플랫폼 코드의 많은 예를 제공합니다. 그렇다면 왜 이 사건에 그를 놔두는 겁니까? MQ의 새 컴파일러가 릴리스되고 이 코드는 더 이상 올바르게 작동하지 않습니다.
소프트웨어 회사는 논의 중인 내용과 어떤 관련이 있습니까? 코드는 작동을 멈추지 않을 것입니다. 여기서 부정행위를 할 필요는 없습니다.
같은 상황을 계속합니다. 유형 코드:
다음보다 읽기가 더 어렵습니다.
그러나 두 경우 모두 실행 효율성은 동일합니다.이 경우 한 줄의 코드가 여섯 줄의 코드보다 읽기 쉽습니다. 게다가 논리적이기 때문에 사이클 내부의 필요성에 어떤 식으로든 묶여 있지 않습니다. 저것들. 첫 번째 옵션은 침착하게 복사하여 붙여 넣을 수 있으며 두 번째 옵션은 아니요.
음, 위의 Lottes[] 예제는 코드가 매우 간결하고 절대적으로 이해할 수 있는 방법을 보여주는 진정한 보물입니다.
이해할 수 있는 코드입니다. 그리고 방금 문서를 보고 코드를 본 사람들은 즉시 궁금해하기 시작할 것입니다. 배열의 크기가 8이고 문서에 6개의 주문 유형 만 있는 이유는 무엇입니까?
그리고 개인적으로는 조건을 따로따로 읽는게 더 편합니다. 이와 같이:
나는 또한 이것보다 더 기분이 좋다.
하지만 그것은 취향과 습관의 문제라고 생각합니다. 누구도 강요하거나 증명할 필요가 없습니다.
한편 다음과 같이 동의합니다.
그리고 이것이 논리적이라고 생각하고 다른 때는 기억이 나지 않습니다.
이해할 수 있는 코드입니다. 그리고 방금 문서를 보고 코드를 본 사람들은 즉시 궁금해하기 시작할 것입니다. 배열의 크기가 8이고 문서에 6개의 주문 유형 만 있는 이유는 무엇입니까?
간단한 코드가 어떻게 마음에 올바른 질문을 제기하는지 알 수 있습니다! 그리고 그 이후에 문서에 기록된 모든 것을 신뢰할 가치가 있습니까?
그리고 그 이후에 문서에 기록된 모든 것을 신뢰할 가치가 있습니까?
가치가 있습니다. 이것이 RTFM 프로그래밍의 기본 원칙입니다.
가치가 있습니다. 이것이 RTFM 프로그래밍의 기본 원칙입니다.
현실은 이 원칙과 모순됩니다.
소프트웨어 회사는 논의 중인 내용과 어떤 관련이 있습니까?
글쎄, 누가 권위자로 데려올 것인가?
코드는 작동을 멈추지 않을 것입니다. 여기서 부정행위를 할 필요는 없습니다.
예, MT4가 이미 거의 묻혀 있기 때문에 99% 확률로 MT4에서는 이것이 사실입니다. 그러나 그러한 허술한 크로스 플랫폼을 시도하고 치명적인 오류로 이어지는 사라지는 결함을 즉시 발견합니다.
이 경우 한 줄의 코드가 여섯 줄의 코드보다 읽기 쉽습니다. 게다가 논리적이기 때문에 사이클 내부의 필요성에 어떤 식으로든 묶여 있지 않습니다. 저것들. 첫 번째 옵션은 침착하게 복사하여 붙여 넣을 수 있으며 두 번째 옵션은 아니요.
특정 사례에 대해 구체적으로 이야기한다면 주어진 코드가 모든 전문가에게 거의 표준이기 때문에 그럴 수도 있습니다. 그러나 더 복잡한 것을 취하면 한 줄로 쓸 때 즉시 읽기가 어려워집니다.
왜 당신의 코드로 작업하는 누군가로부터 우주의 저주를 듣습니까? ))
글쎄, 누가 권위자로 데려올 것인가?
여기에 권위의 개념이 관련되어 있다는 것이 이상합니다.
예, MT4가 이미 거의 묻혀 있기 때문에 99% 확률로 MT4에서는 이것이 사실입니다. 그러나 그러한 허술한 크로스 플랫폼을 시도하고 치명적인 오류로 이어지는 사라지는 결함을 즉시 발견합니다.
MT5에서도 똑같이 씁니다...
특정 사례에 대해 구체적으로 이야기한다면 주어진 코드가 모든 전문가에게 거의 표준이기 때문에 그럴 수도 있습니다. 그러나 더 복잡한 것을 취하면 한 줄로 쓸 때 즉시 읽기가 어려워집니다.
그러나 if -> else if -> else if -> else 구조도 있습니다. 조건 연산자의 bool-expression이 가장 원시적인 형식으로 제공되어야 하는 이유를 이해할 수 없습니다.
이해할 수 있는 코드입니다. 그리고 방금 문서를 보고 코드를 본 사람들은 즉시 궁금해하기 시작할 것입니다. 배열의 크기가 8이고 문서에 6개의 주문 유형 만 있는 이유는 무엇입니까?
그리고 개인적으로는 조건을 따로따로 읽는게 더 편합니다. 이와 같이:
나는 또한 이것보다 더 기분이 좋다.
하지만 그것은 취향과 습관의 문제라고 생각합니다 . 누구도 강요하거나 증명할 필요가 없습니다.
한편 다음과 같이 동의합니다.
그리고 이것은 논리적이라고 생각하고 다른 때는 기억이 나지 않습니다.
다음은 키워드입니다.
개인적으로 나는 일반적으로 계속 쓰기에 짜증이 난다.
그들의 의미는 무엇입니까???? 당신이 읽는 경우
모든 것이 러시아어로 읽힙니다.
주문이 선택되고 주문의 기호가 "우리"이고 마법도 우리의 것이라면... 우리는 중괄호로 묶인 모든 것을 실행합니다.
그러나 러시아어로 어떻게 들리지 않습니까?
오더 선택 안되면 지옥가자...
주문 기호가 우리가 아니면 지옥에 가자
등.
몇 번이나 그곳으로 자신을 보내야 하는지.......
분명히 mql3에서는 이것이 의미가 있었습니다. 이를 통해 상태 확인 시간을 단축할 수 있습니다. 그런 다음 모든 조건을 처음부터 끝까지 확인했습니다. 그러나 결국 오랜 시간 동안 상황이 수정되었으며, 확인이 조건을 충족하지 못하면 추가 확인이 중지됩니다. 그리고 이 모든 트릭은 전혀 말이 되지 않습니다.
다음은 키워드입니다.
개인적으로 나는 일반적으로 계속 쓰기에 짜증이 난다.
그들의 의미는 무엇입니까???? 당신이 읽는 경우
모든 것이 러시아어로 읽힙니다.
주문이 선택되고 주문의 기호가 "우리"이고 마법도 우리의 것이라면... 우리는 중괄호로 묶인 모든 것을 실행합니다.
그러나 러시아어로 어떻게 들리지 않습니까?
오더 선택 안되면 지옥가자...
주문 기호가 우리가 아니면 지옥에 가자
등.
몇 번이나 그곳으로 자신을 보내야 하는 건지.......
분명히 mql3에서는 이것이 의미가 있었습니다. 이를 통해 상태를 확인하는 시간이 단축되었습니다. 그런 다음 모든 조건을 처음부터 끝까지 확인했습니다. 그러나 결국 오랜 시간 동안 상황이 수정되었으며, 확인이 조건을 충족하지 못하면 추가 확인이 중지됩니다. 그리고 이 모든 트릭은 전혀 말이 되지 않습니다.
당신은 이것이 습관의 문제라는 데 동의했습니다. 예를 들어, 불필요한 중첩에 짜증이 나서 항상 반환을 통해 제거합니다. 계속합니다. 그리고 "지옥에 가자" 대신 "조건 1과 2가 충족됨"을 읽는 데 익숙해지기 쉽습니다.
if (!condition1 || !condition2) continue;예를 들어, 나는 추가 중첩에 짜증이 나서 항상 return으로 제거하고 계속합니다.
예를 들어, " 논리적 부정 NOT (!)"에 짜증이 납니다. 프로세서 주기가 없어질 뿐만 아니라 논리적 표현을 읽는 것이 "뒤죽박죽"으로 바뀝니다)))
나는 항상 가장 기대되는 응답으로 bool 함수에서 "true"를 반환합니다. 예를 들면 다음과 같습니다. 다음과 같은 서버 가용성 확인이 있습니다.
나는 꽤 읽기 쉽고 논리적이라고 부릅니다.
서버가 바쁜 경우 - 종료, 일반적으로 거래 기능에서 사용합니다. 서버가 바쁘기 때문에 요청으로 서버를 망치는 것이 없습니다.
이미 말했듯이-맛의 문제이지만 아시다시피 모든 펠트 펜의 맛은 다릅니다)))