많은 소프트웨어 회사에서 그러한 코드에 대해 모든 손가락을 때렸습니다. 항상 어디서나 필요한 첫 번째 것은 "추가 읽기"가 없다는 것입니다. 예를 들어, 함수를 입력할 때 조건이 사용되는 경우:
다음과 같이 작성하는 것이 좋습니다.
이 접근 방식은 중첩 조건에 많은 도움이 됩니다.
다시 한 번 - 손가락을 치십시오. 결국 아무도 OrderType() 함수가 반환한 내용을 확인하지 않았습니다. 아니면 그녀가 -1 또는 6을 반환했습니까? 이것은 컴파일러 속성에 대한 바인딩의 예이며 항상 멀리해야 합니다. 당신은 크로스 플랫폼 코드의 많은 예를 제공합니다. 그렇다면 왜 이 사건에 그를 놔두는 겁니까? MQ의 새 컴파일러가 릴리스되고 이 코드는 더 이상 올바르게 작동하지 않습니다.
같은 상황을 계속합니다. 유형 코드:
다음보다 읽기가 더 어렵습니다.
그러나 두 경우 모두 실행 효율성은 동일합니다.
이것은 완전한 주석입니다.
if (! OrderSelect (i, SELECT_BY_POS ))
continue ;
if ( OrderSymbol () != Symbol ())
continue ;
if ( OrderMagicNumber () != m_nMagicNumber)
continue ;
주석이란 무엇입니까? 한 줄의 superexpression - 주석이 있는 곳입니다. 사람은 조건이 더 이상 처리될 필요가 없다는 것을 즉시 이해하는 컴퓨터가 아닙니다. 사람은 컴퓨터와 달리 전체 표현식을 끝까지 계산해야 하며 첫 번째 구성 요소가 이미 잘못된 결과를 초래한다는 것을 이해해야 합니다.
모든 것이 간단한 조건에 따라 배치되는 기록에서는 그러한 계산이 필요하지 않습니다. 첫 번째 조건이 충족되지 않고 떠났습니다.
줄이 아니라 시간을 절약해야 합니다. 여기에서 그들은 또한 코드의 간결함을 옹호합니다. 이는 실제로 작업과 조건을 서로 압축하는 것입니다. 글쎄요, 이 패키지는 성능을 눈에 띄게 향상시킬 것입니다. 저도 이해합니다. 그러나 결국 - 아닙니다. 최대 성장은 측정 오차 이내입니다. 사람들은 줄을 절약하는 데 관심이 있지만 코드를 이해하고 디버깅하는 데 드는 시간을 절약할 생각은 하지 않습니다.
주석이란 무엇입니까? 한 줄의 superexpression - 주석이 있는 곳입니다. 사람은 조건이 더 이상 처리될 필요가 없다는 것을 즉시 이해하는 컴퓨터가 아닙니다. 사람은 컴퓨터와 달리 전체 표현식을 끝까지 계산해야 하며 첫 번째 구성 요소가 이미 잘못된 결과를 초래한다는 것을 이해해야 합니다.
모든 것이 간단한 조건에 따라 배치되는 기록에서는 그러한 계산이 필요하지 않습니다. 첫 번째 조건이 충족되지 않고 떠났습니다.
줄이 아니라 시간을 절약해야 합니다. 여기에서 그들은 또한 코드의 간결함을 옹호합니다. 이는 실제로 작업과 조건을 서로 압축하는 것입니다. 글쎄요, 이 패키지는 성능을 눈에 띄게 향상시킬 것입니다. 저도 이해합니다. 그러나 결국 - 아닙니다. 최대 성장은 측정 오차 이내입니다. 사람들은 줄을 절약하는 데 관심이 있지만 코드를 이해하고 디버깅하는 데 드는 시간을 절약할 생각은 하지 않습니다.
나는 그것을 읽기 어려운 표현이라고 부르지 않을 것이다.
if (! OrderSelect (i, SELECT_BY_POS ) || OrderSymbol () != Symbol () || OrderMagicNumber () != m_nMagicNumber)
continue ;
예, "짧은 계산 주기"는 정신적 노력 없이 조건을 읽을 때 "자동으로" 고려되는 기본 사항입니다.
그리고 여기서 말할 필요도 없습니다. 지금까지 나의 반대자들(당신을 포함하여)은 이 표현이 줄 바꿈보다 읽기 쉽다는 사실에 찬성하여 단 한 번의 주장도 하지 않았습니다.
세 가지 주장이 나에게 주어졌습니다.
긴 문자열 이 보기에 맞지 않습니다. 최소한의 헤드 회전이 필요합니다(처리 시간 증가). 짧은 라인과 그 뒤에 오는 라인은 그러한 비용이 필요하지 않습니다.
긴 줄에서 실수를 저지르고 눈치 채지 못하는 것이 더 쉽습니다. 줄 바꿈을 사용하면 이러한 종류의 오류가 발생할 가능성이 줄어듭니다.
긴 문자열은 디버깅할 수 없습니다. 줄바꿈해주세요.
주관적인 선호도가 없습니다. 모든 것은 실용적인 의미로 확인되며 그 이상은 아닙니다. 예, 누군가가 오른쪽 발꿈치로 왼쪽 귀를 긁는 것이 더 편리하지만 이것이이 접근법이 실용적이라는 것을 의미하지는 않습니다. 그리고 자연에서는 모든 것이 실용성에 종속되고 더 실용적인 사람이 살아남습니다.
그리고 여기서 말할 필요도 없습니다. 지금까지 나의 반대자들(당신을 포함하여)은 이 표현이 줄 바꿈보다 읽기 쉽다는 사실에 찬성하여 단 한 번의 주장도 하지 않았습니다.
세 가지 주장이 나에게 주어졌습니다.
긴 문자열 이 보기에 맞지 않습니다. 최소한의 헤드 회전이 필요합니다(처리 시간 증가). 짧은 라인과 그 뒤에 오는 라인은 그러한 비용이 필요하지 않습니다.
긴 줄에서 실수를 저지르고 눈치 채지 못하는 것이 더 쉽습니다. 줄 바꿈을 사용하면 이러한 종류의 오류가 발생할 가능성이 줄어듭니다.
긴 문자열은 디버깅할 수 없습니다. 줄바꿈해주세요.
주관적인 선호도가 없습니다. 모든 것은 실용적인 의미로 확인되며 그 이상은 아닙니다. 예, 누군가가 오른쪽 발꿈치로 왼쪽 귀를 긁는 것이 더 편리하지만 이것이이 접근법이 실용적이라는 것을 의미하지는 않습니다. 그리고 자연에서는 모든 것이 실용성에 종속되고 더 실용적인 사람이 살아남습니다.
많은 소프트웨어 회사에서 그러한 코드에 대해 모든 손가락을 때렸습니다. 항상 어디서나 필요한 첫 번째 것은 "추가 읽기"가 없다는 것입니다. 예를 들어, 함수를 입력할 때 조건이 사용되는 경우:
다음과 같이 작성하는 것이 좋습니다.
이 접근 방식은 중첩 조건에 많은 도움이 됩니다.
다시 한 번 - 손가락을 치십시오. 결국 아무도 OrderType() 함수가 반환한 내용을 확인하지 않았습니다. 아니면 그녀가 -1 또는 6을 반환했습니까? 이것은 컴파일러 속성에 대한 바인딩의 예이며 항상 멀리해야 합니다. 당신은 크로스 플랫폼 코드의 많은 예를 제공합니다. 그렇다면 왜 이 사건에 그를 놔두는 겁니까? MQ의 새 컴파일러가 릴리스되고 이 코드는 더 이상 올바르게 작동하지 않습니다.
같은 상황을 계속합니다. 유형 코드:
다음보다 읽기가 더 어렵습니다.
그러나 두 경우 모두 실행 효율성은 동일합니다.이것은 완전한 주석입니다.
이것은 완전한 주석입니다.
주석이란 무엇입니까? 한 줄의 superexpression - 주석이 있는 곳입니다. 사람은 조건이 더 이상 처리될 필요가 없다는 것을 즉시 이해하는 컴퓨터가 아닙니다. 사람은 컴퓨터와 달리 전체 표현식을 끝까지 계산해야 하며 첫 번째 구성 요소가 이미 잘못된 결과를 초래한다는 것을 이해해야 합니다.
모든 것이 간단한 조건에 따라 배치되는 기록에서는 그러한 계산이 필요하지 않습니다. 첫 번째 조건이 충족되지 않고 떠났습니다.
줄이 아니라 시간을 절약해야 합니다. 여기에서 그들은 또한 코드의 간결함을 옹호합니다. 이는 실제로 작업과 조건을 서로 압축하는 것입니다. 글쎄요, 이 패키지는 성능을 눈에 띄게 향상시킬 것입니다. 저도 이해합니다. 그러나 결국 - 아닙니다. 최대 성장은 측정 오차 이내입니다. 사람들은 줄을 절약하는 데 관심이 있지만 코드를 이해하고 디버깅하는 데 드는 시간을 절약할 생각은 하지 않습니다.
주석이란 무엇입니까? 한 줄의 superexpression - 주석이 있는 곳입니다. 사람은 조건이 더 이상 처리될 필요가 없다는 것을 즉시 이해하는 컴퓨터가 아닙니다. 사람은 컴퓨터와 달리 전체 표현식을 끝까지 계산해야 하며 첫 번째 구성 요소가 이미 잘못된 결과를 초래한다는 것을 이해해야 합니다.
모든 것이 간단한 조건에 따라 배치되는 기록에서는 그러한 계산이 필요하지 않습니다. 첫 번째 조건이 충족되지 않고 떠났습니다.
줄이 아니라 시간을 절약해야 합니다. 여기에서 그들은 또한 코드의 간결함을 옹호합니다. 이는 실제로 작업과 조건을 서로 압축하는 것입니다. 글쎄요, 이 패키지는 성능을 눈에 띄게 향상시킬 것입니다. 저도 이해합니다. 그러나 결국 - 아닙니다. 최대 성장은 측정 오차 이내입니다. 사람들은 줄을 절약하는 데 관심이 있지만 코드를 이해하고 디버깅하는 데 드는 시간을 절약할 생각은 하지 않습니다.
나는 그것을 읽기 어려운 표현이라고 부르지 않을 것이다.
예, "짧은 계산 주기"는 정신적 노력 없이 조건을 읽을 때 "자동으로" 고려되는 기본 사항입니다.
다시 말하지만 순전히 주관적인 의견입니다.
당신은 이것이 습관의 문제라는 데 동의했습니다.
그리고 다시 한 번 반복하겠습니다. 나는 누군가에게 습관을 바꾸고 펠트 펜의 취향의 차이를 찾으라고 촉구하지 않습니다.
이미 말했듯이-맛의 문제이지만 아시다시피 모든 펠트 펜의 맛은 다릅니다)))
나는 그것을 읽기 어려운 표현이라고 부르지 않을 것이다.
그리고 여기서 말할 필요도 없습니다. 지금까지 나의 반대자들(당신을 포함하여)은 이 표현이 줄 바꿈보다 읽기 쉽다는 사실에 찬성하여 단 한 번의 주장도 하지 않았습니다.
세 가지 주장이 나에게 주어졌습니다.
그리고 여기서 말할 필요도 없습니다. 지금까지 나의 반대자들(당신을 포함하여)은 이 표현이 줄 바꿈보다 읽기 쉽다는 사실에 찬성하여 단 한 번의 주장도 하지 않았습니다.
세 가지 주장이 나에게 주어졌습니다.
Igor, 눈이 소켓에서 움직이지 않고 머리를 돌려야한다면 다음과 같이 쓸 수 있습니다.
그리고 얼마나 많은 오류가 있는 짧은 줄을 만났는지........... 분명히 오류의 수와 확률은 줄의 길이에 의존하지 않습니다.
디버깅에만 동의할 수 있습니다. 그러나 습관은 mql4에서 디버거가 등장하기 전에 개발되었으며 모든 사람이 습관을 변경할 수 있는 것은 아닙니다.
Igor, 눈이 소켓에서 움직이지 않고 머리를 돌려야한다면 다음과 같이 쓸 수 있습니다.
그리고 얼마나 많은 오류가 있는 짧은 줄을 만났는지........... 분명히 오류의 수와 확률은 줄의 길이에 의존하지 않습니다.
디버깅에만 동의할 수 있습니다. 그러나 습관은 mql4에서 디버거가 등장하기 전에 개발되었으며 모든 사람이 습관을 변경할 수 있는 것은 아닙니다.
하지만 이 스타일을 사용하면 프로그램의 한 블록을 보려면 화면을 두 번 스크롤해야 하며 이는 한 화면에서 모든 코드를 보는 것보다 나쁩니다. (당신을 걱정하지 마십시오, 그것은 단지 예일뿐입니다)
불행히도, 이 신화는 포럼의 역사에서 어떤 확인도 찾지 못합니다. 또한 개발자들은 이러한 변경이 근본적으로 불가능하다는 입장을 지속적으로 분명히 밝히고 있습니다.
그랬다. 정렬이 영향을 받았습니다.
토론은 아마도 이전 metatrader4.com 포럼에서 수행되었을 것입니다(최근에 열렸고 지금은 mql5.com으로 리디렉션됨).
그랬다. 정렬이 영향을 받았습니다.
토론은 아마도 이전 metatrader4.com 포럼에서 수행되었을 것입니다(최근에 열렸고 지금은 mql5.com으로 리디렉션됨).
그랬다, 그랬다. 과거 주문 수와 마찬가지로 "오늘"을 설정하면 OrdersHistoryTotal()은 오늘 마감한 마감 주문 수를 반환합니다. 일부 이전 주문이 "내역" 탭에 표시되지 않으면 티켓으로도 사용할 수 없습니다.
그랬다, 그랬다. 과거 주문 수와 마찬가지로 "오늘"을 설정하면 OrdersHistoryTotal()은 오늘 마감한 마감 주문 수를 반환합니다. 일부 이전 주문이 "내역" 탭에 표시되지 않으면 티켓으로도 사용할 수 없습니다.
정렬에 관한 것입니다. 그런 다음 시간순으로 정렬되지 않은 경우 인덱스별로 마지막 항목을 찾을 수 없었습니다. 정렬된 항목 중 마지막 항목을 찾았습니다.
이제 선택한 탭에 따라 스토리의 깊이가 달라지지 않습니까? 나는 그것이 달려 있다고 생각합니다.