하지만 MQL5 스타일이 정상적이지 않다는 점에는 크게 동의하지 않습니다. 그건 그렇고, 나는 "How to program in C and C plus plus"코딩을 배운 책에서 같은 스타일 또는 거의 같은 (정확히 기억하기 어렵습니다. 몇 년 전이라 정확히 기억하기 어렵습니다), 그런데 저자는 일부 대학의 미국인입니다. 바로 이 C 언어의 첫 번째 테스터 중 한 명입니다.
여기에 양날의 검이 있습니다. 프로그래머에게 자유를 부여하면 스타일이 마침내 분산되어 바벨탑을 얻을 수 있습니다.
바로 이 요소가 컴파일러의 저주라면 두 가지 중 하나가 될 것입니다. 그렇지 않으면 "인간"에서 "올바른" 스타일로 일종의 변환기를 작성해야 합니다(이는 비록 - 기존 IDE가 실제로 이 작업을 수행하지만) MT5에서 프로그래밍하지 마십시오. MT5의 스타일을 사용할 생각조차 하지 않는데...
나는 어떤 것과도 모순되지 않습니다. 토론 과정에서 일반적으로 미래와 미래를 위한 패턴을 형성하는 것은 패턴의 자유로운 형성, 보다 효과적인 형성과 함께 주어진 것으로 그것들에 의존한다는 아이디어가 떠올랐습니다. 가능한 모든 스타일이 분류되고 있기 때문에 가능하지만 가장 편리한 스타일이 이긴다(가장 많이 인쇄된 스타일이 이긴다). Integer 단독으로 또는 Scriptor와 함께 미래에 스타일을 설정하고 gpwr과 같은 개인이 이긴다는 보장은 없습니다. 글을 거의 쓰지 않지만 요점까지 쓰는 사람은 스타일에서 벗어나지 않을 것입니다.
문제는 MQL4-5는 허용되는 코딩 스타일이 채택된 일부 회사에서 한때 일했거나 일한 프로그래머가 대부분 코딩하고 매우 익숙하고 코드를 읽기가 더 쉽다는 것입니다. 새로운 스타일로의 전환에는 시간이 걸리며 논리적으로 보이더라도 모든 사람이 이를 받아들일 수 있는 것은 아닙니다.
Java IDE(예: intelliJ) 또는 MSVS에서와 같이 스타일러를 사용자 정의할 수 있도록 하기만 하면 됩니다. 예를 들어 다른 사람의 소스에서 가져와서 코드에 삽입한 경우와 같이 코드 블록의 형식을 지정하는 기능도 있습니다.
동일한 소스 파일 내에서 함수, 연산자 등의 코드 블록을 축소하거나 확장할 수 있는 MQL5에서 접는 것도 매우 기쁩니다.
그런 다음 하나의 파일에 큰 프로그램을 작성하고(헤더가 있는 경우에도) 많은 파일을 생성하지 않고 사용하지 않는 코드를 간단히 접을 수 있습니다. 그러면 코드를 통한 탐색 및 검색이 훨씬 더 편리합니다. 저는 개인적으로 모든 최신 버전의 IDE에서 구현되는 접기 또는 개요를 좋아합니다.
사용자 정의 스타일을 수행해야한다는 데 동의합니다 ...
하지만 MQL5 스타일이 정상적이지 않다는 점에는 크게 동의하지 않습니다. 그건 그렇고, 나는 "How to program in C and C plus plus"코딩을 배운 책에서 같은 스타일 또는 거의 같은 (정확히 기억하기 어렵습니다. 몇 년 전이라 정확히 기억하기 어렵습니다), 그런데 저자는 일부 대학의 미국인입니다. 바로 이 C 언어의 첫 번째 테스터 중 한 명입니다.
여기에 양날의 검이 있습니다. 프로그래머에게 자유를 부여하면 스타일이 마침내 분산되어 바벨탑을 얻을 수 있습니다.
마찬가지로 어떤 종류의 억제력과 안내 요소(익숙해지기 위해)가 있어야 합니다.
ps. 펜으로 글을 쓸 줄 아는 사람은 누구나 이 낙서를 읽을 수 없습니다.
그러나 블록 문자는 글을 쓰는 사람이라면 누구나 읽을 수 있습니다.
Urain писал(а) >>
마찬가지로 어떤 종류의 억제력과 안내 요소(익숙해지기 위해)가 있어야 합니다.
모두가 위협적으로 손가락을 흔드는 모습, 그리고 잠시 동안 포럼에서 이 모든 내용을 블록체로 읽는 것이 아니라 원본(손으로 쓴)의 손글씨로 읽는다고 상상해보세요. 무엇이든 이해하거나 심지어 서체에 유사한 처방을 입력해야 한다는 공통된 의견에 도달할 것입니다.
ps. 스타일은 단지 습관일 뿐이며 생각의 패턴일 뿐이라고 잠시 생각합니다.
모두가 위협적으로 손가락을 흔드는 모습, 그리고 잠시 동안 포럼에서 이 모든 내용을 블록체로 읽는 것이 아니라 원본(손으로 쓴)의 손글씨로 읽는다고 상상해보세요. 무엇이든 이해하거나 심지어 서체에 유사한 처방을 입력해야 한다는 공통된 의견에 도달할 것입니다.
ps. 스타일은 단지 습관일 뿐이며 생각의 패턴일 뿐이라고 잠시 생각합니다.
생각 패턴이 부과되고 선택할 권리가 주어지지 않을 때 불쾌합니다.
여기서 당신은 틀렸고 심지어 자신과 모순됩니다.
나는 어떤 것과도 모순되지 않습니다. 토론 과정에서 일반적으로 미래와 미래를 위한 패턴을 형성하는 것은 패턴의 자유로운 형성, 보다 효과적인 형성과 함께 주어진 것으로 그것들에 의존한다는 아이디어가 떠올랐습니다. 가능한 모든 스타일이 분류되고 있기 때문에 가능하지만 가장 편리한 스타일이 이긴다(가장 많이 인쇄된 스타일이 이긴다). Integer 단독으로 또는 Scriptor와 함께 미래에 스타일을 설정하고 gpwr과 같은 개인이 이긴다는 보장은 없습니다. 글을 거의 쓰지 않지만 요점까지 쓰는 사람은 스타일에서 벗어나지 않을 것입니다.
문제는 MQL4-5는 허용되는 코딩 스타일이 채택된 일부 회사에서 한때 일했거나 일한 프로그래머가 대부분 코딩하고 매우 익숙하고 코드를 읽기가 더 쉽다는 것입니다. 새로운 스타일로의 전환에는 시간이 걸리며 논리적으로 보이더라도 모든 사람이 이를 받아들일 수 있는 것은 아닙니다.
Java IDE(예: intelliJ) 또는 MSVS에서와 같이 스타일러를 사용자 정의할 수 있도록 하기만 하면 됩니다. 예를 들어 다른 사람의 소스에서 가져와서 코드에 삽입한 경우와 같이 코드 블록의 형식을 지정하는 기능도 있습니다.
동일한 소스 파일 내에서 함수, 연산자 등의 코드 블록을 축소하거나 확장할 수 있는 MQL5에서 접는 것도 매우 기쁩니다.
그런 다음 하나의 파일에 큰 프로그램을 작성하고(헤더가 있는 경우에도) 많은 파일을 생성하지 않고 사용하지 않는 코드를 간단히 접을 수 있습니다. 그러면 코드를 통한 탐색 및 검색이 훨씬 더 편리합니다. 저는 개인적으로 모든 최신 버전의 IDE에서 구현되는 접기 또는 개요를 좋아합니다.
나는 나 자신과 모순되지 않는다
봤으니 계속할게 솔직히 하기 싫었다.
별말씀을요. 스타일은 코드의 이해도에 영향을 주어서는 안 되지만 매우 강력한 영향을 미치므로 한 스타일이 다른 스타일보다 더 이해하기 쉽다고 말함으로써 이를 확인합니다.
따라서 사고 패턴은 정보 인식에 영향을 미치지 않습니다.
따라서 사고 패턴은 정보 인식에 영향을 미치지 않습니다.
여기서 당신은 착각하고 있습니다. 사고 패턴은 정보의 인식에 강한 영향을 미칩니다.
너무 강해서 많은 사람들이 거기에 있어서는 안 될 것들을 보지 못합니다(사고 방식에 따라).
이런 스타일이 익숙하다
사람마다 스타일이 다르다스타일러 개발자가 3가지 스타일을 2개 만들어주면 좋아요
if ( ... { for ( { } }제 생각에는 이것이 고전적인 스타일입니다. 정확히 기억나지는 않지만 Van Tassel의 스타일에 대한 책은 아주 명확하게 쓰여졌 습니다.