나머지 사용자에게는 매우 확실합니다. 그리고 그들이 다른 사람의 스타일로 포맷된 코드를 읽는 것은 매우, 매우 불쾌합니다.
이 문제를 해결하기 위해 스타일러의 일반 기능을 확장할 것을 제안합니다. 다른 사람들(당신이 아니라 다른 사람들)이 당신의 스타일러를 사용하기를 원한다면 가장 편리하고 사용자 정의 가능한 옵션으로 가져오는 것이 좋습니다. 그리고 여기서 핵심 단어는 "당신"이 아니라 "사람"입니다.
프로그래머는 스스로 코드를 작성하지 않지만 스스로 코드를 작성한다고 잘못 생각합니다. 익숙한가요?
추신: CodeBase에 대한 변명은 일반적으로 말도 안 됩니다. 편집기에 내장된 스타일러가 그것과 무슨 관련이 있습니까?...
동의하지 않는다은 무슨 뜻인가요? 동의할 수 없는 사실상의 표준이 있으며, 따라야 합니다. 하위 파괴를 사용하여 자체 HTML로 보고서를 생성하는 것은 그들에게 발생하지 않았습니다. 그들은 표준 문서에서 수행했습니다. 스타일도 마찬가지다. 프로그래밍은 세계적인 산업이고 스타일이 정의되어 있으며 MetaQuots는 이러한 종류의 "혁신"으로 대중을 대적할 수 없습니다.
스타일은 제어 문과 연결된 중괄호를 다음 줄에 놓고 제어 문과 같은 수준으로 들여씁니다. 중괄호 안의 문은 다음 수준으로 들여쓰기됩니다.
동안( x == y ) { 뭔가 (); 뭔가 다른 (); } 마무리 ();
자신의 관점을 보호하는 문제는 절대적으로 무리인 것 같습니다. 다음과 같은 형식의 텍스트를 보고 싶으십니까? 그러나 다른 형식으로 보기를 원하는 다른 사람들이 있습니다. 이 사람들(본문에 대한 액세스 권한이 없음)은 자신의 요구 사항을 고려하고 포맷터에 대한 설정을 지정하여 귀하와 그들의 요구 사항에 따라 포맷할 수 있도록 요청합니다. 개발자인 당신만이 할 수 있습니다. 우리는 당신에게 요청하고 있습니다. 당신은 우리를 만나러 가거나 모든 사람을 당신의 표준으로 보냅니다. 옵션을 선택하고 음성으로 알려주세요.
Indentation is not a requirement of most programming languages, where it is used as secondary notation. Rather, programmers indent to better convey the structure of their programs to human readers. In particular, indentation is used to show the relationship between control flow constructs such as conditions or loops and code contained within...
이 문제를 왜 중요하게 생각하는지, 왜 Allman 스타일(Emacs에서는 bsd) 이 가장 정확하다고 생각하는지 몇 단락만 추가하겠습니다. 누가 무엇에 익숙했는지 잠시 잊고 맨손으로 논리를 펴자.
왜 텍스트 서식이 필요합니까? 바로 이 형식을 사용하여 별도의 논리 블록을 선택하고 분리합니다 .
규칙적으로 잠시 봅시다. 루프 "헤더"와 루프 본문이라는 두 개의 논리적으로 분리된 블록이 있습니다. 그것들을 섞지 않으려면 다른 라인에 배치해야합니다. 이런 이유로 같은 줄의 여는 괄호가 (개인적으로 저에게는) 의아합니다(사람이 반으로 들어간 것과 같습니다. 몸 전체가 방 안에 있고 머리는 여전히 문 밖에 "남아" 있습니다. ).
이제 두 번째 질문은 브래킷을 안쪽으로 밀어넣는 것입니다. 원칙적으로 괄호는 헤더와 직접 관련이 없으며 루프 본문의 일부입니다. 그러나 실행 가능한 명령만 푸시하면 됩니다. 자체 논리가 있는 것. 그러나 본문이 없는 루프의 정상적인 예가 하나 이상 있습니다.
while ( TradingServerNotAvailable() ) { }
거래 서버를 사용할 수 있을 때까지 우리는 할 일이 없습니다. 그래서 우리는 아무 것도 하지 않고 루프 본문이 비어 있습니다. 이 경우 안쪽으로 밀어 넣은 괄호가 (내 관점에서 볼 때) 이상하게 보입니다. 보이드가 오른쪽으로 이동하고 보이드가 강조 표시됩니다.
루프에 본문이 있는 경우 오른쪽으로 이동하고 닫는 괄호 쌍을 검색하기 위해 왼쪽 공간이 확보됩니다.
while ( TradingServerNotAvailable() ) { Sleep ( 1000 ); }
이것이 여는 괄호가 루프 헤더와 같은 줄에 던져지면 안 되는 또 다른 이유입니다. 눈으로 닫는 / 여는 괄호를 찾을 때 찾기가 더 어렵습니다. 내 버전에서 브래킷은 이 위치에서 명확하게 표시되고 해당 쌍은 다른 라인에 있지만 동일한 위치에 있습니다. 또한 단일 괄호가 있는 줄(설명이 없어도!)은 내부 블록을 외부 블록과 강조 표시하고 구분하는 추가 시각적 요소 역할을 합니다.
보시다시피 개인적인 것은 없습니다. 텍스트의 시각적 인식 논리일 뿐입니다!
그리고 이 논리(개인 취향과 습관이 아님)의 관점에서 스타일러의 현재 형식에 있는 텍스트는 이해할 수 없거나 불쾌합니다.
// чего вдавлен внутрь кусок кода - в котором кода нет и выделять там нечего while ( TradingServerNotAvailable() ) { }
// каждый отступ вправо ассоциируется с новым уровнем вложенности, а здесь визуально ТРИ уровня ! while ( TradingServerNotAvailable() ) // первый уровень { // второй уровень Sleep(1000); // третий уровень }
그리고 GNU-sleep에서 쓰기가 일종의 엉망이라면
if ( TradingServerNotAvailable() ) { .... }else{ // вот тут в одной строке ТРИ элемента разных блоков: закрытие предыдущего , разделитель , начало следующего :((( .... }
여는 괄호를 잃어버렸고 닫는 괄호를 추가로 넣지 않았는지 확인하는 방법은 무엇입니까? 톨리 이렇습니다.
Indentation is not a requirement of most programming languages, where it is used as secondary notation. Rather, programmers indent to better convey the structure of their programs to human readers. In particular, indentation is used to show the relationship between control flow constructs such as conditions or loops and code contained within...
여러분, 누구를 위한 코드입니까?
프로그래머의 나머지 부분에 대해 매우 강력하게 확신합니다. 그리고 그들이 다른 사람의 형식이 지정되지 않은 코드를 읽는 것은 매우 매우 불쾌합니다.
이 문제를 해결하기 위해 스타일러의 일반 기능을 만들었습니다. 다른 사람들(당신이 아니라 다른 사람들)이 당신의 코드를 보기를 원한다면 가장 간단하고 명확한 버전으로 가져오는 것이 좋습니다. 그리고 여기서 핵심 단어는 "당신"이 아니라 "사람"입니다.
Renat, 스타일러 는 누구를 위해 작성되었습니까?
나머지 사용자에게는 매우 확실합니다. 그리고 그들이 다른 사람의 스타일로 포맷된 코드를 읽는 것은 매우, 매우 불쾌합니다.
이 문제를 해결하기 위해 스타일러의 일반 기능을 확장할 것을 제안합니다. 다른 사람들(당신이 아니라 다른 사람들)이 당신의 스타일러를 사용하기를 원한다면 가장 편리하고 사용자 정의 가능한 옵션으로 가져오는 것이 좋습니다. 그리고 여기서 핵심 단어는 "당신"이 아니라 "사람"입니다.
프로그래머는 스스로 코드를 작성하지 않지만 스스로 코드를 작성한다고 잘못 생각합니다. 익숙한가요?
추신: CodeBase에 대한 변명은 일반적으로 말도 안 됩니다. 편집기에 내장된 스타일러가 그것과 무슨 관련이 있습니까?...
추신: CodeBase에 대한 변명은 일반적으로 말도 안 됩니다. 편집기에 내장된 스타일러가 그것과 무슨 관련이 있습니까?...
코드 베이스를 직접 수집, 유지 관리 및 지불하면 질문이 즉시 사라집니다. 아니면 주변의 모든 것이 무료라고 생각하십니까?
이제 모든 이야기는 "구성할 수 없기 때문에 나쁘다"는 원칙적인 입장에 대해서만 이야기됩니다.
특정 지점으로 이동해 보겠습니다. 스타일러 에서 잘못 수행한 지점과 이유를 나타냅니다.
이제 모든 이야기는 "구성할 수 없기 때문에 나쁘다"는 원칙적인 입장에 대해서만 이야기됩니다.
동의하지 않는다.
예를 들어, 나는 다음과 같은 입장을 가지고 있습니다. "일반적으로 허용되는 코딩 표준을 충족하지 않기 때문에 만족하지 못하는 것. 만족할 때까지 사용하지 않고 만족할 때 사용할 것입니다. 달성 수단 결과" 양복 "큰 역할을 하지 않는다".
당신은 이 문제뿐만 아니라 원칙적인 입장을 가지고 있습니다.
그리고 당신은 주장이 상당히 합리적이고 합리적이더라도 다른 사람들의 주장을 절대적으로 듣고 싶지 않습니다.
특정 지점으로 이동하겠습니다. 스타일러에서 잘못 수행한 지점과 이유를 나타냅니다.
동의하지 않는다.
예를 들어, 나는 다음과 같은 입장을 가지고 있습니다. "일반적으로 허용되는 코딩 표준을 충족하지 않기 때문에 만족하지 못하는 것. 만족할 때까지 사용하지 않고 만족할 때 사용할 것입니다. 달성 수단 결과" 양복 "큰 역할을 하지 않는다".
당신은 이 문제뿐만 아니라 원칙적인 입장을 가지고 있습니다.
그리고 당신은 주장이 상당히 합리적이고 합리적이더라도 다른 사람들의 주장을 절대적으로 듣고 싶지 않습니다.
스타일러는 모든 것을 올바르게 수행합니다. 그러나 원하는(허용되는) 결과가 일치하지 않습니다.+1. 모든 면에서.
표준 스타일로 돌아가려면 솔루션만 있으면 됩니다. 그들은 단순히 과거 언젠가 비뚤어진 스타일을 채택한 실수를 인정하고 싶지 않습니다.
+1. 모든 면에서.
표준 스타일로 돌아가려면 솔루션만 있으면 됩니다. 그들은 단순히 과거 언젠가 비뚤어진 스타일을 채택한 실수를 인정하고 싶지 않습니다.
"곡률"에 동의하지 않습니다.
그들은 너무 "맛있고" "밝습니다"... 그것에 대해 논쟁하지 마십시오.
그리고 설정에 대해 그들은 말합니다 - 우리는 나중에 주제로 돌아갈 것입니다
;)
"곡률"에 동의하지 않습니다.
그들은 너무 "맛있고" "밝습니다"... 그것에 대해 논쟁하지 마십시오.
그리고 설정에 대해 그들은 말합니다 - 우리는 나중에 주제로 돌아갈 것입니다
;)
동의하지 않는다은 무슨 뜻인가요? 동의할 수 없는 사실상의 표준이 있으며, 따라야 합니다. 하위 파괴를 사용하여 자체 HTML로 보고서를 생성하는 것은 그들에게 발생하지 않았습니다. 그들은 표준 문서에서 수행했습니다. 스타일도 마찬가지다. 프로그래밍은 세계적인 산업이고 스타일이 정의되어 있으며 MetaQuots는 이러한 종류의 "혁신"으로 대중을 대적할 수 없습니다.
스타일러 가 잘못 수행한 점과 이유를 알려주세요.
형식이 지정된 코드 조각을 보여주는 것이 좋습니다.
스타일러가 잘못한 점과 이유를 알려주세요.
형식이 지정된 코드 조각을 보여주는 것이 좋습니다.
https://www.mql5.com/en/forum/122145 , 탭은 작은 2 자이지만 3-4는 정상이지만 그다지 중요하지 않습니다.
첫 번째 게시물의 데모. 쉼표는 없으며 이 문장과 같이 필요합니다.
당신이 진지하다면, 나는 우리의 기업 스타일 계약에서 인용할 수 있습니다.
스타일러가 잘못한 점과 이유를 알려주세요.
형식이 지정된 코드 조각을 보여주는 것이 좋습니다.
Renat, 이것은 이미 스포츠 정신이 아닙니다.)
MQL은 귀하의 언어이며 이에 대한 표준이 없으므로 귀하는 귀하의 표준을 설정할 권리가 있습니다. 그리고 우리는 당신에게 아무것도 증명하지 않을 것입니다.
그러나 MQL은 C와 같은 언어입니다. 그리고 C에는 일반적으로 인정되는 몇 가지 표준이 있습니다. 여기 있습니다: https://en.wikipedia.org/wiki/Indent_style
나는 개인적으로 Allman 스타일(Emacs의 경우 bsd)을 선호합니다.
스타일은 제어 문과 연결된 중괄호를 다음 줄에 놓고 제어 문과 같은 수준으로 들여씁니다. 중괄호 안의 문은 다음 수준으로 들여쓰기됩니다.
자신의 관점을 보호하는 문제는 절대적으로 무리인 것 같습니다. 다음과 같은 형식의 텍스트를 보고 싶으십니까? 그러나 다른 형식으로 보기를 원하는 다른 사람들이 있습니다. 이 사람들(본문에 대한 액세스 권한이 없음)은 자신의 요구 사항을 고려하고 포맷터에 대한 설정을 지정하여 귀하와 그들의 요구 사항에 따라 포맷할 수 있도록 요청합니다. 개발자인 당신만이 할 수 있습니다. 우리는 당신에게 요청하고 있습니다. 당신은 우리를 만나러 가거나 모든 사람을 당신의 표준으로 보냅니다. 옵션을 선택하고 음성으로 알려주세요.
이 문제를 왜 중요하게 생각하는지, 왜 Allman 스타일(Emacs에서는 bsd) 이 가장 정확하다고 생각하는지 몇 단락만 추가하겠습니다. 누가 무엇에 익숙했는지 잠시 잊고 맨손으로 논리를 펴자.
왜 텍스트 서식이 필요합니까? 바로 이 형식을 사용하여 별도의 논리 블록을 선택하고 분리합니다 .
규칙적으로 잠시 봅시다. 루프 "헤더"와 루프 본문이라는 두 개의 논리적으로 분리된 블록이 있습니다. 그것들을 섞지 않으려면 다른 라인에 배치해야합니다. 이런 이유로 같은 줄의 여는 괄호가 (개인적으로 저에게는) 의아합니다(사람이 반으로 들어간 것과 같습니다. 몸 전체가 방 안에 있고 머리는 여전히 문 밖에 "남아" 있습니다. ).
이제 두 번째 질문은 브래킷을 안쪽으로 밀어넣는 것입니다. 원칙적으로 괄호는 헤더와 직접 관련이 없으며 루프 본문의 일부입니다. 그러나 실행 가능한 명령만 푸시하면 됩니다. 자체 논리가 있는 것. 그러나 본문이 없는 루프의 정상적인 예가 하나 이상 있습니다.
거래 서버를 사용할 수 있을 때까지 우리는 할 일이 없습니다. 그래서 우리는 아무 것도 하지 않고 루프 본문이 비어 있습니다. 이 경우 안쪽으로 밀어 넣은 괄호가 (내 관점에서 볼 때) 이상하게 보입니다. 보이드가 오른쪽으로 이동하고 보이드가 강조 표시됩니다.
루프에 본문이 있는 경우 오른쪽으로 이동하고 닫는 괄호 쌍을 검색하기 위해 왼쪽 공간이 확보됩니다.
이것이 여는 괄호가 루프 헤더와 같은 줄에 던져지면 안 되는 또 다른 이유입니다. 눈으로 닫는 / 여는 괄호를 찾을 때 찾기가 더 어렵습니다. 내 버전에서 브래킷은 이 위치에서 명확하게 표시되고 해당 쌍은 다른 라인에 있지만 동일한 위치에 있습니다. 또한 단일 괄호가 있는 줄(설명이 없어도!)은 내부 블록을 외부 블록과 강조 표시하고 구분하는 추가 시각적 요소 역할을 합니다.
보시다시피 개인적인 것은 없습니다. 텍스트의 시각적 인식 논리일 뿐입니다!
그리고 이 논리(개인 취향과 습관이 아님)의 관점에서 스타일러의 현재 형식에 있는 텍스트는 이해할 수 없거나 불쾌합니다.
그리고 GNU-sleep에서 쓰기가 일종의 엉망이라면
if ( TradingServerNotAvailable() ) {
....
} else { // вот тут в одной строке ТРИ элемента разных блоков: закрытие предыдущего , разделитель , начало следующего :(((
....
}
여는 괄호를 잃어버렸고 닫는 괄호를 추가로 넣지 않았는지 확인하는 방법은 무엇입니까? 톨리 이렇습니다.
다시 한 번 반복합니다. 이것은 제 개인적인 습관이나 다른 것에 관한 것이 아닙니다. 단지 텍스트에 대한 시각적 인식의 논리일 뿐입니다!