이 템플릿은 수년에 걸쳐 개발되었으며 더디기는 하지만 여전히 계속 개선되고 있습니다. :)
따라서 나쁜 습관은 아닙니다. 그녀에게는 너무 힘들었다. 그것은 연산자 사이에 공백을 두는 것이 아닙니다. 그렇습니다. 놀랍게도 많은 사람들에게 나쁜 습관입니다.
사실 팀 작업에 있어서 가장 중요한 것은 전체 팀이 동일한 코드 스타일로 작업하는 것입니다. 이것은 매우 중요합니다. 굴의 맛에 대해 논쟁하는 것은 의미가 없습니다. 우리는 그들을 먹었다! ;-) 이 해산물을 먹으면 어떤 유익한 부작용이 있는지 말할 수 있습니다! :-)
문제의 해결책은 ELEMENTARY입니다. 스툴러는 이미 작동 중이며 브래킷을 들여써야 하는 위치에 따라 일정한 위치가 어딘가에 있습니다. ME 매개변수에 바로 이 들여쓰기를 입력하기 위해 하나의 텍스트 필드를 추가하는 것은 모든 개발자에게 사소한 문제입니다. 누구든지 .... MK를 제외하고 - 그들은 무슨 일이 있어도 준수하기로 결정한 자체 "정책"을 가지고 있습니다.
코드베이스에 일반적인 순서가 있어야 한다는 사실에 대한 주장은 변명조차 되지 않습니다. :)) 당신이 작성한 스크립트를 수락하기 위한 규칙을 작성하십시오: 코드는 이런저런 형식으로 수락됩니다. 사용자가 다른 것을 보내면 "포맷해야 합니다"라는 표준 응답을 받게 되며 코드베이스 관리자는 이러한 잘못된 텍스트로 장난치지 않을 것입니다.
하지만 그게 요점이 아닙니다! 하루에 전 세계적으로 몇 줄의 MQL 코드가 작성됩니까? 이 숫자로는 긴 것만으로는 부족하다고 생각합니다. 그리고 그 중 몇 개가 코드베이스에 포함됩니까?! 숏컷이면 충분하다고 생각합니다. 그러니 교활한 개발자가 되지 마십시오. ;) 코드 기반에는 포스터보다 실제 사용자가 훨씬 더 많습니다. 그리고 당신의 제품이 그들에게 더 편리할수록 더 인기가 있을 것입니다. 솔직하게 쓰자 - 우리는 할게, 하지만 나중에는 "아주 나중에"가 될 수도 있어..... 그렇지 않으면 5개 중 첫 번째 베타의 공개와 같이 깨지고... 그건 당신에게 편리하지 않습니다 :)
Urain писал(а) >>
ps. 스타일은 단지 습관일 뿐이며 생각의 패턴일 뿐이라고 잠시 생각합니다.
이 템플릿은 수년에 걸쳐 개발되었으며 더디기는 하지만 여전히 계속 개선되고 있습니다. :)
따라서 나쁜 습관은 아닙니다. 그녀에게는 너무 힘들었다. 그것은 연산자 사이에 공백을 두는 것이 아닙니다. 그렇습니다. 놀랍게도 많은 사람들에게 나쁜 습관입니다.
아니요, 스타일러는 설정 없이 유지됩니다.
이것은 개발자의 답변입니다. 마감된 주제 :(
이 템플릿은 수년에 걸쳐 개발되었으며 더디기는 하지만 여전히 계속 개선되고 있습니다. :)
따라서 나쁜 습관은 아닙니다. 그녀에게는 너무 힘들었다. 그것은 연산자 사이에 공백을 두는 것이 아닙니다. 그렇습니다. 놀랍게도 많은 사람들에게 나쁜 습관입니다.
사실 팀 작업에 있어서 가장 중요한 것은 전체 팀이 동일한 코드 스타일로 작업하는 것입니다. 이것은 매우 중요합니다. 굴의 맛에 대해 논쟁하는 것은 의미가 없습니다. 우리는 그들을 먹었다! ;-) 이 해산물을 먹으면 어떤 유익한 부작용이 있는지 말할 수 있습니다! :-)
일반적으로 거의 동등한 2개의 적절한 읽기 가능한 스타일이 있습니다.
if () { }그리고
if () { }다른 모든 것은 사악한 IMHO의 것입니다.
추신. 흔들리는 발 azzx
기업 내 C 스타일 표준의 예 - EMBEDDED 시스템(하드웨어):
문제는 양측 모두에게 매우 간단한 해결책이 될 수 있습니다.
두 가지 버전만 유지하면 됩니다.
개발자는 형식이 지정된 버전을 자신이 처리하기에 편리한 방식으로 유지하고 사용자는 익숙한 방식으로 유지합니다.
이 경우 누구도 누구에게나 아무 것도 부과하지 않으며 새로운 재포맷을 위한 추가 디스크 공간 및 시간 비용은 미미합니다.
게다가 이념적으로 올바른 스타일을 배우고 싶은 분들은 언제나 '이상형'을 바라볼 수 있는 기회가 있습니다:)
사실 팀 작업에 있어서 가장 중요한 것은 전체 팀이 동일한 코드 스타일로 작업하는 것입니다.
사람이 제정신이라면 누구든지 이것에 대해 논쟁하지 않을 것입니다. :)
슈 작성 >>
일반적으로 거의 동등한 2개의 적절한 읽기 가능한 스타일이 있습니다.
그리고
다른 모든 것은 사악한 IMHO의 것입니다.
문제는 양측 모두에게 매우 간단한 해결책이 될 수 있습니다.
문제의 해결책은 ELEMENTARY입니다. 스툴러는 이미 작동 중이며 브래킷을 들여써야 하는 위치에 따라 일정한 위치가 어딘가에 있습니다. ME 매개변수에 바로 이 들여쓰기를 입력하기 위해 하나의 텍스트 필드를 추가하는 것은 모든 개발자에게 사소한 문제입니다. 누구든지 .... MK를 제외하고 - 그들은 무슨 일이 있어도 준수하기로 결정한 자체 "정책"을 가지고 있습니다.
코드베이스에 일반적인 순서가 있어야 한다는 사실에 대한 주장은 변명조차 되지 않습니다. :)) 당신이 작성한 스크립트를 수락하기 위한 규칙을 작성하십시오: 코드는 이런저런 형식으로 수락됩니다. 사용자가 다른 것을 보내면 "포맷해야 합니다"라는 표준 응답을 받게 되며 코드베이스 관리자는 이러한 잘못된 텍스트로 장난치지 않을 것입니다.
하지만 그게 요점이 아닙니다! 하루에 전 세계적으로 몇 줄의 MQL 코드가 작성됩니까? 이 숫자로는 긴 것만으로는 부족하다고 생각합니다. 그리고 그 중 몇 개가 코드베이스에 포함됩니까?! 숏컷이면 충분하다고 생각합니다. 그러니 교활한 개발자가 되지 마십시오. ;) 코드 기반에는 포스터보다 실제 사용자가 훨씬 더 많습니다. 그리고 당신의 제품이 그들에게 더 편리할수록 더 인기가 있을 것입니다. 솔직하게 쓰자 - 우리는 할게, 하지만 나중에는 "아주 나중에"가 될 수도 있어..... 그렇지 않으면 5개 중 첫 번째 베타의 공개와 같이 깨지고... 그건 당신에게 편리하지 않습니다 :)
Нет, стайлер останется без настроек.
ForexTools 작성 >>
이것은 개발자의 답변입니다. 마감된 주제 :(
슬프게도
--
유적:
1-다른 스타일러 찾기
2회용 레귤러
---
코드에 대한 인식, 모든 사람은 자신의
좋은 코드는 편집됩니다 - 드물게
코드가 항상 제품과 함께 전송되는 것은 아닙니다.
코드를 통과하더라도 - 내 스타일이 익숙한 사람들에게 제대로 인식되지 않을 수 있습니다.
if ( ) { ... } или if ( условие ) { ... } void functionA() { ... }이런 스타일로 씁니다
void Function1() { } if ( ) // условие входа { }카탈로그만 봐주세요!
C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\src\mfc\
고전적인 스타일이 있습니다 ... 그것이 내가 고수하는 것입니다.
다음은 한 줄의 asty.bat 배치 파일입니다.
astyle.exe --indent=tab --indent=force-tab=3 --style=allman --delete-empty-lines --pad-oper --unpad-paren --pad-paren-out %1 %2 %3 %4 %5 %6 %7 %8 %9
그리고 당신은 행복할 것입니다.
http://astyle.sourceforge.net/astyle.html
스타일은 사용자 정의할 수 있어야 하며 코드가 어떻게 보이는지는 작성자에게 달려 있습니다.
작가로서의 개발자는 우리를 작가로 인정하지 않습니다.
메모장 ++과 같은 대안을 사용해야 할 때
이중 괄호로 적절하게 작업할 수 있도록 스타일에 대해 이야기할 필요가 없습니다.