Gorillych : 모든 것이 이해될 수 있고, 문서가 있고, 예가 있으며, Rosh는 모든 것을 썼습니다. 설명서에 있는 예제만으로는 만족하지 않습니다. 여기 사이트에서 이러한 예제 중 많은 부분이 이미 작성되었지만 문서는 여전히 동일합니다.
나는 사이트의 온라인 문서에 자신의 의견을 추가할 수 있는 기능을 추가할 것을 제안합니다(세 번째로 그런 것 같습니다). 이것은 다른 IT 기술에 성공적으로 적용되었습니다. 다음은 이러한 기능 설명의 예입니다. 기본 및 타사 개발자 아래의 기성품 코드 - 가져 와서 복사하십시오.
Yurixx, 문서에서 정확히 무엇이 잘못되었습니까? 오류에 대한 명확한 표시를 제공해 주시면 수정하겠습니다.
예를 들어, 식별자가 지정되지 않은 오류가 있었고 이미 수정했습니다.
조니는 다음과 같이 썼다. 그런데 문서에 대해 툴킷의 OBJPROP_FIBOLEVELS 속성에서 F1 키를 눌렀을 때 뭔가 이상하거나 거의 아무 일도 일어나지 않는 것을 발견했습니다.
모든 경우에 대해 가장 자세한 문서를 갖고 싶다면 불행히도 이것이 작동하지 않습니다. MSDN의 아날로그를 터미널에 삽입하는 것은 어려울 것입니다. 우리가 무엇을 쓰든 여전히 질문이 있을 것입니다. 그리고 기사, 코드 라이브러리, 포럼 및 검색 엔진이 도처에 있다고 해도 항상 도움이 되는 것은 아닙니다.
이 스레드의 주제는 나로 하여금 오랫동안 기한이 지난 생각을 분명히 하게 만들었습니다. 이론적 접근 방식은 " 좋은 문서/책을 제공하면 세상을 바꿀 것입니다 "로는 충분하지 않습니다. 갈퀴 위를 의무적이고 독립적으로 밟는 연습이 필요합니다.
우리의 사례:
오랫동안 소프트웨어 개발 방법론을 개선해 왔으며 ISO9000 인증도 준비하고 있습니다. 지난 몇 년 동안 주제에 대한 수십 권의 책을 구입했으며 많은 책을 읽었으며 모두가 구현의 필요성에 동의합니다. 그러나 이론으로는 충분하지 않습니다. 올라타서 하셔야 합니다. 우리는 단계적으로 무엇을하고 있습니다.
어렵습니다. 책을 읽고 나면 머리가 완전히 엉망이 됩니다. 어디론가 나가서 "문서가 나쁘다"고 외쳐야 할 때입니다. "컨설턴트를 부르자"는 생각이 즉시 떠올랐고 그들이 여기에서 우리를 위해 모든 것을 하도록 내버려 두었습니다. 그러나 이성은 우리 자신이 컨설턴트의 물의 보고서를 읽는 것이 아니라 모든 것을 이해하고 변경해야한다고 말합니다.
비즈니스에서도 마찬가지입니다. 책만 읽으면 모든 것이 단순해 보일 것입니다. "나는 나 자신을 믿었고, 몸을 흔들고, 사업을 시작했고, 모든 것이 끝났다." 삶의 모든 것이 다릅니다.
문서화에 대한 우리의 입장:
특별 웹사이트 MQL4.community를 통해 전 세계적으로 글로벌 수준의 거래자 교육에 참여
나는 사이트의 온라인 문서에 자신의 의견을 추가할 수 있는 기능을 추가할 것을 제안합니다(세 번째로 그런 것 같습니다). 이것은 다른 IT 기술에 성공적으로 적용되었습니다. 다음은 이러한 기능 설명의 예입니다. 기본 및 타사 개발자 아래의 기성품 코드 - 가져 와서 복사하십시오.
예, 이것은 좋은 생각이며 아마도 우리가 구현할 것입니다.
우리는 MQL4 사이트에서 계속 작업하고 있으며 많은 아이디어를 가지고 있습니다. 내일 우리는 사이트용 새 편집기의 베타 버전을 출시할 예정입니다. 그러면 고급 " 관련 주제 " 기능의 새 버전이 제공됩니다.
이 스레드에서 내가 말하고 싶은 또 다른 것이 있습니다. 이 스레드에서 새 사용자는 Rosh 의 기사로 자주 보내지지만 나는 가끔 거기를 보는 것을 부끄러워하지 않습니다. alpari에서 변경되었으며 모든 링크는 여기에서 'Rosh 기사 개요' a: MetaTrader 4의 전문가 가 404 오류를 유발하므로 링크를 수정해야 합니다.
위협 그럼 당연히 댓글은 봤는데 제가 필요로 하는 글이 거의 맨 위에 6개여서 바로 눈치채지 못했어요.
Jhonny : 이 스레드에서 내가 말하고 싶은 또 다른 것이 있습니다. 이 스레드에서 새 사용자는 Rosh 의 기사로 자주 보내지지만 나는 가끔 거기를 보는 것을 부끄러워하지 않습니다. alpari에서 변경되었으며 모든 링크는 여기에서 'Rosh 기사 개요' a: MetaTrader 4의 전문가 가 404 오류를 유발하므로 링크를 수정해야 합니다.
Renat : Yurixx, 문서에서 정확히 무엇이 잘못되었습니까? 오류에 대한 명확한 표시를 제공해 주시면 수정하겠습니다.
모든 경우에 대해 가장 자세한 문서를 갖고 싶다면 불행히도 이것이 작동하지 않습니다. MSDN의 아날로그를 터미널에 삽입하는 것은 어려울 것입니다. 우리가 무엇을 쓰든 여전히 질문이 있을 것입니다. 그리고 기사, 코드 라이브러리, 포럼 및 검색 엔진이 도처에 있다고 해도 항상 도움이 되는 것은 아닙니다.
이 스레드의 주제는 나로 하여금 오랫동안 기한이 지난 생각을 분명히 하게 만들었습니다. " 나에게 좋은 문서/책을 제공하면 세상을 바꿀 것입니다 "라는 이론적인 접근 방식으로는 충분하지 않습니다. 갈퀴 위를 의무적이고 독립적으로 밟는 연습이 필요합니다.
문서화에 대한 우리의 입장:
특별 웹사이트 MQL4.community를 통해 전 세계의 글로벌 수준에서 거래자에 대한 양방향 교육에 참여
거래자들이 서로 돕고 지식을 공유할 수 있는 기회 제공
거래자가 개발자와 직접 통신할 수 있도록 합니다.
거래자가 기사를 작성하고 다른 언어로 번역하도록 권장
누구나 액세스할 수 있도록 단일 지점에서 정보 수집
나는 모든 경우 등에 대해 가장 자세한 문서를 갖고 싶지 않습니다. 그것은 단지 일반적인 문서에 관한 것입니다. 이 스레드에서 표현된 몇 가지 소원을 3페이지의 내 게시물에 결합했습니다. 문서 부분에는 다음이 있었습니다.
MQL 프로그램의 메커니즘을 설명하는 챕터가 있어야 합니다( lex_ant 가 쓴 대로). 이것은 프로그래밍을 처음 접하는 모든 거래자가 언어를 배우기도 전에 이해할 수 있는 것입니다. 그리고 이 설명은 거래 프로세스와 연결되어야 합니다. 여기에서 지표, 스크립트 및 Expert Advisors가 서로 어떻게 다른지, 틱 흐름, 거래 서버, 서로 등과 관련하여 어떻게 작동하는지 설명할 수 있습니다.
MQL 프로그램의 구조, 주요 구성 요소인 init(), start() 및 deinit() 함수에 더 많은 주의를 기울여야 합니다. 이러한 기능은 MQL과 다른 언어 사이의 중요한 차이점이며 문서에서 거의 몇 줄에 불과한 공간이 거의 제공되지 않습니다.
사전의 모든 항목을 살펴보고 오류와 오타를 제거할 뿐만 아니라 용어를 공통 분모로 가져오는 것은 매우 멋질 것입니다. 매우 자주, 기능 및 절차의 동일한 유형 또는 동일한 매개변수에 대한 설명은 완전히 다른 용어를 사용하여 수행되며 이러한 용어의 의미는 설명되지 않습니다. 결과적으로 설명은 가능하지만 일부 매개변수의 의미와 사용은 실험을 통해 연구해야 합니다.
예제를 올바르게 이해하는 것은 매우 중요합니다 ( 4x4ever 에 전적으로 동의)! 사전 항목에 있는 대다수의 예는 아무에게도 설명하지 않으며 아무 것도 가르치지 않습니다. 일반적으로 한 줄의 예제는 예제가 아닙니다! 일반 참고서에서는 예제를 통해 매개변수의 의미, 프로시저/함수를 사용하는 절차, 얻은 결과를 이해할 수 있습니다. 그리고 이를 위해 자신의 프로그램을 작성할 필요가 없습니다. IMHO: MQL 사전 예제의 약점은 문서의 주요 단점 중 하나입니다.
동의합니다. 그렇게 많지 않습니다.
Renat, 문서에 대한 귀사의 입장은 모든 존경을 받을 만합니다. 그러나 귀하가 나열한 항목에는 문서와 직접적으로 관련된 항목이 하나도 없다는 점에 유의하십시오. 그것들은 모두 좋지만 이것은 추가 기능이며 기초는 모든 사람이 MQL 및 프로그램을 배우는 데 도움이 되는 자료입니다. 오늘날 그것은 사전(즉, 실제 문서)이며, 두 번째로 사이트의 출판물입니다. 추가 기능이 작동하려면 견고한 기반을 만드십시오. 즉, MQL 참조를 필요한 품질로 가져옵니다 .
레나트는 다음과 같이 썼습니다. Yurixx, 문서에서 정확히 무엇이 잘못되었습니까? 오류에 대한 명확한 표시를 제공해 주시면 수정하겠습니다.
Yurixx : Renat, 문서에 대한 귀사의 입장은 모든 존경을 받을 만합니다. 그러나 귀하가 나열한 항목에는 문서와 직접적으로 관련된 항목이 하나도 없다는 점에 유의하십시오. 그것들은 모두 좋지만 이것은 추가 기능이며 기초는 모든 사람이 MQL 및 프로그램을 배우는 데 도움이 되는 자료입니다. 오늘날 그것은 사전(즉, 실제 문서)이며, 두 번째로 사이트의 출판물입니다. 애드온이 작동하려면 견고한 기반을 만드십시오. 즉, MQL 참조를 필요한 품질로 가져옵니다 .
일반적으로 그러한 경우 자신을 긴장시키지 않기 위해 사랑하는 사람 :) 특정 오류를 검색하여 GOST, SNiP 및 ISO에 대한 여러 페이지 링크가 제공되며 지정된 내용에 따라 제품을 가져올 것을 제안합니다. 목록. 번호가 기억나지 않고 보고 싶지도 않습니다. 그렇지 않으면 목록을 던질 것입니다.) 이건 농담이야.
레나트는 다음과 같이 썼습니다. Yurixx, 문서에서 정확히 무엇이 잘못되었습니까? 오류에 대한 명확한 표시를 제공해 주시면 수정하겠습니다.
내가 이해하는 한 명백한 오류에 대한 명확한 표시는 없습니다. 불쌍해.
Renat, 당신은 결론에 너무 성급합니다. 보시다시피, 추가 노력 없이 성가신 "비평가"를 제거하고 싶을 것입니다. 회사의 입장이 이렇게 아름답게 선언된 후, 사실 이러한 선언의 이면에는 사용자의 의사를 듣지 않으려는 마음이 있음을 알 수 있습니다. 실제로 MQ 자체는 무엇을 어떻게 해야 하는지, 사용자가 무엇을 해야 하는지 알고 있습니다.
감히 장담합니다. 상황을 잘못 이해하고 계십니다. 개선해야 할 점을 명확하게 알려드릴 수 있습니다. 그러나 먼저 우리는 무언가를 명확히 해야 합니다. 이 문구에서 빨간색으로 설득력 있게 강조 표시되면 다음이 명확하게 표시됩니다. 오류를 지적하면 수정하지만 설명서를 직접 살펴보지는 않습니다. 그리고 "명백한 오류"라는 문구도 암시적입니다. 2년간의 디버깅과 이 포럼 참가자들의 도움 덕분에 "명백한 오류"의 수가 최소로 줄어들었고 계속해서 감소하고 있습니다. 그러나 "명백하지 않은" 다른 오류를 지적하는 데 관심이 없다는 문구를 분명히 합니다. 그리고 동시에 나쁜 예, 이해하기 어려운 설명 등에는 관심이 없습니다.
또한 모든 문서 오류에 대한 지침은 무엇입니까? 아니, 레나트, 미안해. 귀사가 MQL에 대한 교과서 작성에 관여하지 않을 수 있습니다. 이는 정상적인 현상입니다. 그러나 언어에 대한 문서를 마무리 해야 합니다. 고마운! 언어 작성자 외에 누가 문서화해야 합니까? 이 문서를 기반으로 하지 않고 프로그래머가 이 언어를 사용하는 방법을 배울 수 있습니까?
그러므로 근거 없는 말을 하지 않기 위해 대표적인 예를 든다. 문서의 품질에 관심이 없다면 내가 쓴 것이 말도 안되는 이유를 확실히 알게 될 것입니다. 그럼에도 불구하고 이 대화에 건설적인 부분이 조금이라도 있다면 틀림없이 내 말을 이해하게 될 것입니다. 그러나 당신은 이것을 아주 잘 이해하고 있습니다.
지정된 배열 차원의 요소 수를 반환합니다. 인덱스가 0에서 시작하기 때문에 차원의 크기는 가장 큰 인덱스보다 1 더 큽니다.
옵션:
정렬[]
-
검사된 배열
range_index
-
차원 색인.
예시:
int dim_size;
이중 num_array[10,10,10];
dim_size=ArrayRange(num_array, 1);
.
인덱스는 일반적으로 배열의 요소에 번호를 매기는 변수입니다. 이 경우 인덱스에 대해 이야기하는 것이 아니라 인덱스 번호에 대해 이야기하는 것입니다. 하지만 "인덱스는 0부터 시작하기 때문에 차원의 크기는 가장 큰 인덱스보다 1 더 크다"라는 구절에서 이 또한 그 무엇도 이해할 수 없다. 특히 초보자를 위해.
"왜냐하면..."은(는) 무슨 뜻인가요? 이것은 전에 어디에서 언급되었습니까? 아무데도! 특정 함수이고 차원을 나타내는 range_index 변수가 다른 곳에는 나타나지 않기 때문입니다. 따라서 차원 번호 매기기가 0에서 시작한다고 말해야 합니다. 그리고 차원 번호 (크기가 아님!)는 변수 range_index ("인덱스"가 아님)의 가장 큰 값보다 1이 더 큽니다. 그리고 한 문장으로 압축하지 말고 2~3개의 문구로 일관되고 명확하게 설명하는 것이 좋습니다.
설명에 제공된 예는 참조 고전입니다. 그는 무엇을 명확히 할 수 있습니까? 아무것도 ! 레나트가 어떻게 되어야 할지 모르겠다면 이 페이지의 첫 번째 게시물에 있는 그림을 보세요. 최소한 예제에 표시된 작업 결과의 인쇄물이 있어야 합니다. 그리고 결과적으로 dim_size 변수가 취한 값은 무엇입니까? 나는 당신이 알고 있지만 새로운 언어 학습자가 이것을 알고 있습니까?
그리고 dim_size=10 이라고 쓰여져도 누구이며 무엇을 명확히 할 것인가? 이 예의 작성자는 아마도 유머러스한 이유로 배열의 3차원 모두에 숫자 10을 넣습니다 .
다음은 문서 작성에 대한 태도의 예입니다. "관계"라는 단어에 대한 소명을 생각해보십시오. 여기서 얼마나 많은 "명백한" 오류를 계산했는지 궁금합니다. 나는 한 명도 없다고 생각한다. 그러나 핸드북에는 명백한 오류가 없지만 그 안에 포함된 문서의 품질을 현저히 저하시키는 그러한 기사가 여전히 많이 있습니다.
모든 것이 이해될 수 있고, 문서가 있고, 예가 있으며, Rosh는 모든 것을 썼습니다.
설명서에 있는 예제만으로는 만족하지 않습니다. 여기 사이트에서 이러한 예제 중 많은 부분이 이미 작성되었지만 문서는 여전히 동일합니다.
나는 사이트의 온라인 문서에 자신의 의견을 추가할 수 있는 기능을 추가할 것을 제안합니다(세 번째로 그런 것 같습니다). 이것은 다른 IT 기술에 성공적으로 적용되었습니다.
다음은 이러한 기능 설명의 예입니다. 기본 및 타사 개발자 아래의 기성품 코드 - 가져 와서 복사하십시오.
예를 들어, 식별자가 지정되지 않은 오류가 있었고 이미 수정했습니다.
조니는 다음과 같이 썼다.
그런데 문서에 대해 툴킷의 OBJPROP_FIBOLEVELS 속성에서 F1 키를 눌렀을 때 뭔가 이상하거나 거의 아무 일도 일어나지 않는 것을 발견했습니다.
모든 경우에 대해 가장 자세한 문서를 갖고 싶다면 불행히도 이것이 작동하지 않습니다. MSDN의 아날로그를 터미널에 삽입하는 것은 어려울 것입니다. 우리가 무엇을 쓰든 여전히 질문이 있을 것입니다. 그리고 기사, 코드 라이브러리, 포럼 및 검색 엔진이 도처에 있다고 해도 항상 도움이 되는 것은 아닙니다.
이 스레드의 주제는 나로 하여금 오랫동안 기한이 지난 생각을 분명히 하게 만들었습니다. 이론적 접근 방식은 " 좋은 문서/책을 제공하면 세상을 바꿀 것입니다 "로는 충분하지 않습니다. 갈퀴 위를 의무적이고 독립적으로 밟는 연습이 필요합니다.
우리의 사례:
오랫동안 소프트웨어 개발 방법론을 개선해 왔으며 ISO9000 인증도 준비하고 있습니다. 지난 몇 년 동안 주제에 대한 수십 권의 책을 구입했으며 많은 책을 읽었으며 모두가 구현의 필요성에 동의합니다. 그러나 이론으로는 충분하지 않습니다. 올라타서 하셔야 합니다. 우리는 단계적으로 무엇을하고 있습니다.
비즈니스에서도 마찬가지입니다. 책만 읽으면 모든 것이 단순해 보일 것입니다. "나는 나 자신을 믿었고, 몸을 흔들고, 사업을 시작했고, 모든 것이 끝났다." 삶의 모든 것이 다릅니다.어렵습니다. 책을 읽고 나면 머리가 완전히 엉망이 됩니다. 어디론가 나가서 "문서가 나쁘다"고 외쳐야 할 때입니다. "컨설턴트를 부르자"는 생각이 즉시 떠올랐고 그들이 여기에서 우리를 위해 모든 것을 하도록 내버려 두었습니다. 그러나 이성은 우리 자신이 컨설턴트의 물의 보고서를 읽는 것이 아니라 모든 것을 이해하고 변경해야한다고 말합니다.
문서화에 대한 우리의 입장:
즉, 우리의 학습 작업은 가장 단순한 내장 문서보다 훨씬 광범위합니다. 예를 들어, 어제 저는 중국에서 MetaTrader를 홍보하는 사무실을 열었던 상하이에서 비행기를 타고 왔습니다. 앞으로 몇 달 안에 사이트의 중국어 부분에 큰 변화가 있을 것입니다.
어떻게 하는지 살펴보세요.
나는 사이트의 온라인 문서에 자신의 의견을 추가할 수 있는 기능을 추가할 것을 제안합니다(세 번째로 그런 것 같습니다). 이것은 다른 IT 기술에 성공적으로 적용되었습니다.
다음은 이러한 기능 설명의 예입니다. 기본 및 타사 개발자 아래의 기성품 코드 - 가져 와서 복사하십시오.
우리는 MQL4 사이트에서 계속 작업하고 있으며 많은 아이디어를 가지고 있습니다. 내일 우리는 사이트용 새 편집기의 베타 버전을 출시할 예정입니다. 그러면 고급 " 관련 주제 " 기능의 새 버전이 제공됩니다.
위협 그럼 당연히 댓글은 봤는데 제가 필요로 하는 글이 거의 맨 위에 6개여서 바로 눈치채지 못했어요.
이 스레드에서 내가 말하고 싶은 또 다른 것이 있습니다. 이 스레드에서 새 사용자는 Rosh 의 기사로 자주 보내지지만 나는 가끔 거기를 보는 것을 부끄러워하지 않습니다. alpari에서 변경되었으며 모든 링크는 여기에서 'Rosh 기사 개요' a: MetaTrader 4의 전문가 가 404 오류를 유발하므로 링크를 수정해야 합니다.
Yurixx, 문서에서 정확히 무엇이 잘못되었습니까? 오류에 대한 명확한 표시를 제공해 주시면 수정하겠습니다.
모든 경우에 대해 가장 자세한 문서를 갖고 싶다면 불행히도 이것이 작동하지 않습니다. MSDN의 아날로그를 터미널에 삽입하는 것은 어려울 것입니다. 우리가 무엇을 쓰든 여전히 질문이 있을 것입니다. 그리고 기사, 코드 라이브러리, 포럼 및 검색 엔진이 도처에 있다고 해도 항상 도움이 되는 것은 아닙니다.
이 스레드의 주제는 나로 하여금 오랫동안 기한이 지난 생각을 분명히 하게 만들었습니다. " 나에게 좋은 문서/책을 제공하면 세상을 바꿀 것입니다 "라는 이론적인 접근 방식으로는 충분하지 않습니다. 갈퀴 위를 의무적이고 독립적으로 밟는 연습이 필요합니다.
문서화에 대한 우리의 입장:
MQL 프로그램의 메커니즘을 설명하는 챕터가 있어야 합니다( lex_ant 가 쓴 대로). 이것은 프로그래밍을 처음 접하는 모든 거래자가 언어를 배우기도 전에 이해할 수 있는 것입니다. 그리고 이 설명은 거래 프로세스와 연결되어야 합니다. 여기에서 지표, 스크립트 및 Expert Advisors가 서로 어떻게 다른지, 틱 흐름, 거래 서버, 서로 등과 관련하여 어떻게 작동하는지 설명할 수 있습니다.
MQL 프로그램의 구조, 주요 구성 요소인 init(), start() 및 deinit() 함수에 더 많은 주의를 기울여야 합니다. 이러한 기능은 MQL과 다른 언어 사이의 중요한 차이점이며 문서에서 거의 몇 줄에 불과한 공간이 거의 제공되지 않습니다.
사전의 모든 항목을 살펴보고 오류와 오타를 제거할 뿐만 아니라 용어를 공통 분모로 가져오는 것은 매우 멋질 것입니다. 매우 자주, 기능 및 절차의 동일한 유형 또는 동일한 매개변수에 대한 설명은 완전히 다른 용어를 사용하여 수행되며 이러한 용어의 의미는 설명되지 않습니다. 결과적으로 설명은 가능하지만 일부 매개변수의 의미와 사용은 실험을 통해 연구해야 합니다.
예제를 올바르게 이해하는 것은 매우 중요합니다 ( 4x4ever 에 전적으로 동의)! 사전 항목에 있는 대다수의 예는 아무에게도 설명하지 않으며 아무 것도 가르치지 않습니다. 일반적으로 한 줄의 예제는 예제가 아닙니다! 일반 참고서에서는 예제를 통해 매개변수의 의미, 프로시저/함수를 사용하는 절차, 얻은 결과를 이해할 수 있습니다. 그리고 이를 위해 자신의 프로그램을 작성할 필요가 없습니다. IMHO: MQL 사전 예제의 약점은 문서의 주요 단점 중 하나입니다.
동의합니다. 그렇게 많지 않습니다.Renat, 문서에 대한 귀사의 입장은 모든 존경을 받을 만합니다. 그러나 귀하가 나열한 항목에는 문서와 직접적으로 관련된 항목이 하나도 없다는 점에 유의하십시오. 그것들은 모두 좋지만 이것은 추가 기능이며 기초는 모든 사람이 MQL 및 프로그램을 배우는 데 도움이 되는 자료입니다. 오늘날 그것은 사전(즉, 실제 문서)이며, 두 번째로 사이트의 출판물입니다. 추가 기능이 작동하려면 견고한 기반을 만드십시오. 즉, MQL 참조를 필요한 품질로 가져옵니다 .
레나트는 다음과 같이 썼습니다.
Yurixx, 문서에서 정확히 무엇이 잘못되었습니까? 오류에 대한 명확한 표시를 제공해 주시면 수정하겠습니다.
Renat, 문서에 대한 귀사의 입장은 모든 존경을 받을 만합니다. 그러나 귀하가 나열한 항목에는 문서와 직접적으로 관련된 항목이 하나도 없다는 점에 유의하십시오. 그것들은 모두 좋지만 이것은 추가 기능이며 기초는 모든 사람이 MQL 및 프로그램을 배우는 데 도움이 되는 자료입니다. 오늘날 그것은 사전(즉, 실제 문서)이며, 두 번째로 사이트의 출판물입니다. 애드온이 작동하려면 견고한 기반을 만드십시오. 즉, MQL 참조를 필요한 품질로 가져옵니다 .
내가 이해하는 한 명백한 오류에 대한 명확한 표시는 없습니다. 불쌍해.
내가 알기로는 명백한 오류에 대한 명확한 표시가 없습니다. 불쌍해.
일반적으로 그러한 경우 자신을 긴장시키지 않기 위해 사랑하는 사람 :) 특정 오류를 검색하여 GOST, SNiP 및 ISO에 대한 여러 페이지 링크가 제공되며 지정된 내용에 따라 제품을 가져올 것을 제안합니다. 목록. 번호가 기억나지 않고 보고 싶지도 않습니다. 그렇지 않으면 목록을 던질 것입니다.)
이건 농담이야.
Renat, 사이트를 시작할 때 어떤 종류의 새 편집기를 여기에서 언급했습니까?
Renat, 사이트를 시작할 때 어떤 종류의 새 편집기를 여기에서 언급했습니까?
새로운 기능(아직 포함되지 않음) 중 하나는 동영상 삽입입니다. YouTube의 동영상과 동영상입니다. 아마도 월요일에 공개 테스트를 위해 베타를 시작할 것입니다.
레나트는 다음과 같이 썼습니다.
내가 이해하는 한 명백한 오류에 대한 명확한 표시는 없습니다. 불쌍해.Yurixx, 문서에서 정확히 무엇이 잘못되었습니까? 오류에 대한 명확한 표시를 제공해 주시면 수정하겠습니다.
Renat, 당신은 결론에 너무 성급합니다. 보시다시피, 추가 노력 없이 성가신 "비평가"를 제거하고 싶을 것입니다. 회사의 입장이 이렇게 아름답게 선언된 후, 사실 이러한 선언의 이면에는 사용자의 의사를 듣지 않으려는 마음이 있음을 알 수 있습니다. 실제로 MQ 자체는 무엇을 어떻게 해야 하는지, 사용자가 무엇을 해야 하는지 알고 있습니다.
감히 장담합니다. 상황을 잘못 이해하고 계십니다. 개선해야 할 점을 명확하게 알려드릴 수 있습니다. 그러나 먼저 우리는 무언가를 명확히 해야 합니다. 이 문구에서 빨간색으로 설득력 있게 강조 표시되면 다음이 명확하게 표시됩니다. 오류를 지적하면 수정하지만 설명서를 직접 살펴보지는 않습니다. 그리고 "명백한 오류"라는 문구도 암시적입니다. 2년간의 디버깅과 이 포럼 참가자들의 도움 덕분에 "명백한 오류"의 수가 최소로 줄어들었고 계속해서 감소하고 있습니다. 그러나 "명백하지 않은" 다른 오류를 지적하는 데 관심이 없다는 문구를 분명히 합니다. 그리고 동시에 나쁜 예, 이해하기 어려운 설명 등에는 관심이 없습니다.
또한 모든 문서 오류에 대한 지침은 무엇입니까? 아니, 레나트, 미안해. 귀사가 MQL에 대한 교과서 작성에 관여하지 않을 수 있습니다. 이는 정상적인 현상입니다. 그러나 언어에 대한 문서를 마무리 해야 합니다. 고마운! 언어 작성자 외에 누가 문서화해야 합니까? 이 문서를 기반으로 하지 않고 프로그래머가 이 언어를 사용하는 방법을 배울 수 있습니까?
그러므로 근거 없는 말을 하지 않기 위해 대표적인 예를 든다. 문서의 품질에 관심이 없다면 내가 쓴 것이 말도 안되는 이유를 확실히 알게 될 것입니다. 그럼에도 불구하고 이 대화에 건설적인 부분이 조금이라도 있다면 틀림없이 내 말을 이해하게 될 것입니다. 그러나 당신은 이것을 아주 잘 이해하고 있습니다.
그러나 예.
인덱스는 일반적으로 배열의 요소에 번호를 매기는 변수입니다. 이 경우 인덱스에 대해 이야기하는 것이 아니라 인덱스 번호에 대해 이야기하는 것입니다. 하지만 "인덱스는 0부터 시작하기 때문에 차원의 크기는 가장 큰 인덱스보다 1 더 크다"라는 구절에서 이 또한 그 무엇도 이해할 수 없다. 특히 초보자를 위해.
"왜냐하면..."은(는) 무슨 뜻인가요? 이것은 전에 어디에서 언급되었습니까? 아무데도! 특정 함수이고 차원을 나타내는 range_index 변수가 다른 곳에는 나타나지 않기 때문입니다. 따라서 차원 번호 매기기가 0에서 시작한다고 말해야 합니다. 그리고 차원 번호 (크기가 아님!)는 변수 range_index ("인덱스"가 아님)의 가장 큰 값보다 1이 더 큽니다. 그리고 한 문장으로 압축하지 말고 2~3개의 문구로 일관되고 명확하게 설명하는 것이 좋습니다.
설명에 제공된 예는 참조 고전입니다. 그는 무엇을 명확히 할 수 있습니까? 아무것도 ! 레나트가 어떻게 되어야 할지 모르겠다면 이 페이지의 첫 번째 게시물에 있는 그림을 보세요. 최소한 예제에 표시된 작업 결과의 인쇄물이 있어야 합니다. 그리고 결과적으로 dim_size 변수가 취한 값은 무엇입니까? 나는 당신이 알고 있지만 새로운 언어 학습자가 이것을 알고 있습니까?
그리고 dim_size=10 이라고 쓰여져도 누구이며 무엇을 명확히 할 것인가? 이 예의 작성자는 아마도 유머러스한 이유로 배열의 3차원 모두에 숫자 10을 넣습니다 .
다음은 문서 작성에 대한 태도의 예입니다. "관계"라는 단어에 대한 소명을 생각해보십시오.
여기서 얼마나 많은 "명백한" 오류를 계산했는지 궁금합니다. 나는 한 명도 없다고 생각한다.
그러나 핸드북에는 명백한 오류가 없지만 그 안에 포함된 문서의 품질을 현저히 저하시키는 그러한 기사가 여전히 많이 있습니다.