답변:
모든 요구 사항에 대한 이유. 이런 식으로 표준을 따르는 것은 일종의화물 컬트가되지 않으며 사람들은 그 이유가 더 이상 적용되지 않으면 표준을 변경하거나 그 이유가 명확하게 적용되지 않는 특정 경우에 표준을 위반하는 것이 좋다는 것을 알고 있습니다 .
탭 대 공백! 동료 중 하나가 실수로 저장소로 이동하는 공간에 많은 탭을 커밋하면 미친 업데이트가 발생합니다.
명명 규칙
편집 : 이것은 명명 규칙이 아니라 명명 지침을 의미합니다.
예를 들어, Guideline은입니다 All boolean values should begin with Is/Can/Has/etc when possible. 규칙은All boolean values must start with Is
IsCanUpdate와 IsHasChildren. 물론, 틀렸지 만 표준으로 결정되었습니다. 그리고 이것이 내 요점입니다. 일단 이런 것들을 지정하기 시작하면 모든 기초를 다뤄야합니다. 또는 그들은 표준을 무시하기 시작합니다. 어느 쪽이든, 팀은 패배합니다.
그룹의 코딩 표준에는 반드시 해결해야하는 경고 및 오류에 대한 컴파일러 옵션 이 포함 되어야합니다.
프로그래머는 자신의 코드에 대해 경고를 자유롭게 늘릴 수 있지만 다른 사람의 코드를 읽고 작업해도 컴파일러에서 얻은 출력이 어지럽히 지 않도록 기준이 있어야합니다.
그러한 표준은 또한 다른 규정을 따르지 않는 예외적 인 코드가있는 경우 프로그래머가 사례별로 이러한 경고를 비활성화 할 수있는 방법을 다루어야합니다.
내가 좋아하는 일부 표준 (많은 표준이 있다는 것을 알고 있지만 그것이 내가 선호하는 표준입니다) :
표준을 사용하면 코드를 처음 작성하는 약간의 도움을 코딩, 그들은 도움이 많은 당신, 또는 교체, 2 년 후 코드를 업데이트해야합니다.
이상적인 표준은 코드의 임의의 페이지로 이동할 수있는 코드로 연결되며 첫 번째 판독에서 수행중인 작업을 정확하게 이해합니다.
반면에 임의의 표준이 너무 많으면 코드 작성 흐름이 중단 될 수 있습니다. 따라서 제안 된 코딩 규칙의 모든 항목은 다음 두 가지 기준에 따라 평가되어야한다고 생각합니다.
둘 다 참이 아닌 경우 항목은 임의적이며 아마도 불필요합니다
내가 쓰는 표준에 다음 사항을 포함시킬 것입니다.
선명도 :
파일 구성 : 파일에서 항목의 고정 순서를 지정하면 팀이 다른 파일을 쉽게 탐색 할 수 있습니다. #defines 또는 구조 정의를 찾기 위해 사냥 할 필요는 없습니다.
명명 규칙 : 일관된 명명은 가독성을 향상시킵니다. 그러나 너무 많은 규칙을 과도하게 지정하면 쓰기 가능성이 떨어집니다.
코드 구조. 중괄호 배치, 들여 쓰기 수준, 공백과 탭 등. 예, 이것은 개인적인 취향을 강력하게 할 수 있지만 목표는 명확한 코드입니다. 팀에 가장 적합한 옵션을 찾아서 고수하십시오.
정확성을 위해 :
문제 유형별 모범 사례 : 메모리 할당, 동시성 또는 이식성에 대한 규칙.
"정확한 정확성", static및의 적절한 사용 volatile등
전 처리기 매크로 및 기타 쉽게 악용 될 수있는 언어 기능에 대한 규칙.
코딩 표준에 무엇이 있어야합니까? 가능한 적게. 오히려 더. 그리고 정당화하십시오.
내가 프로세스를 원하지 않는 카우보이 코더이기 때문이 아니라 논리가없는 무거운 코딩 사양을 보았 기 때문에 "아마도 '95의 어딘가에있는 네트에서 이것을 발견했습니다." 함께 일하는 관료적 악몽.
어떤 사람들은 정직하게 표준을 세움으로써 상응하는 코드 "품질"을 보게 될 것이며 아마도 그 측정에 의해 그렇게 될 것이라고 믿는 것 같습니다. 그 동안에는 파일의 행 수보다 더 중요한 아키텍처, 성능, 상식 및 기타 여러 가지를 무시합니다.
좋은 오래된 상식은 사라지지 않을 것입니다. 관련이없는 요점을 다루는 코딩 표준 문서가 너무 많습니다 (글꼴 유형 및 크기와 같은 항목은 내가 본 것 중 가장 극단적 인 것 중 하나입니다).
개발자 그룹에 속한 경우 가장 좋은 방법은 서로 대화하고 코드를보고 수용 가능한 사항에 대한 합의를 작성하고 요점을 지침으로 작성해야하지만 다음과 같이 유지하는 것입니다. 그 지침 만. 지침과의 차이를 정당화 할 수 없다면 실제로 왜 그렇게하는지 고려해야합니다.
하루가 끝나면 레이아웃이나 타이포그래피에 대한 엄격한 규칙보다 명확하고 이해하기 쉬운 코드가 중요합니다.
다른 사람들이 언급했듯이 코드 테스트 범위가 중요합니다. 나는 또한보고 싶다 :
프로젝트 구조. 테스트는 코드의 일부입니까, 아니면 별도의 프로젝트 / 패키지 / 디렉토리에 있습니까? UI 코드는 백엔드와 함께 있습니까? 그렇지 않은 경우 어떻게 분할됩니까?
개발 과정. 코드 전에 테스트를 작성 하시겠습니까? 깨진 빌드를 수정하는 것이 개발보다 우선합니까? 코드 검토는 언제 이루어지며 무엇을 다루어야합니까?
소스 코드 관리 언제 체크인 되나요? 설계 문서 및 테스트 계획은 개정 관리됩니까? 언제 분기하고 언제 태그합니까? 이전 빌드를 유지하고 있다면 얼마나 오래 / 길게 유지합니까?
배포 표준. 빌드는 어떻게 패키지됩니까? 릴리스 정보에 들어가야 할 것은 무엇입니까? 업그레이드 스크립트는 어떻게 생성 / 제어 / 실행됩니까?
이름 지정 규칙, 형식 및 함수 / 방법 / 모듈에 몇 줄을 넣을 수 있는지에 대한 모든 것을 잊어 버리십시오. 하나의 규칙 : 기존 스타일이 편집중인 스타일에 관계없이 사용하십시오. 누군가의 스타일이 마음에 들지 않으면 코드 검토에서 다른 스타일을 선택하십시오. 유일한 편집자 / IDE가 맹목적으로 서로 변환하고 모든 라인이 변경 되었기 때문에 변경 히스토리를 파괴하는 경우에만 tabs-vs-spaces 일 수 있습니다.
나는 실제로 해결해야 할 두 가지가 있다고 생각하지만 실제로는 두 가지가 중요하지만 동일한 방식으로 접근 할 수 없기 때문에 실제로는 별도로 고려할 것입니다.
내가의 자격 기술적 측면 표준 코딩은 ,로 할 허브 셔터 와 안드레이 Alexandrescu의를 자신과 C ++ 코딩 표준 . 명명 스타일 , 들여 쓰기 등을 포함하는 코딩 스타일 자격이있는 프레젠테이션 ...
코딩 표준
순수한 기술이기 때문에 코딩 표준은 대부분 객관적 일 수 있습니다. 따라서 모든 규칙은 이유에 의해 지원되어야합니다. 책에서 나는 각 항목에 대해 언급했다 :
이유와시기를 요약 한 근거와 예외는 매우 중요합니다.
제목은 검토하는 동안 작업 할 제목 (치트 시트) 목록 만 있으면됩니다. 그리고 항목을 쉽게 찾을 수 있도록 범주별로 항목을 그룹화하십시오.
Sutter와 Alexandrescu는 C ++이 털이 많은 것으로 여겨지더라도 백 항목 만 나열했습니다.
코딩 스타일
이 부분은 일반적으로 덜 객관적입니다 (그리고 매우 주관적 일 수 있습니다). 여기에서 유지 보수 담당자와 신규 이민자에게 도움이되므로 일관성을 보장해야합니다.
여기에 어떤 들여 쓰기 또는 중괄호 스타일이 더 좋은지에 대한 전쟁에 참여하고 싶지는 않습니다.이 포럼이 있습니다.이 카테고리에서는 합의> 과반수 투표> 리더의 임의 결정으로 작업을 수행합니다.
형식화 예제는 Artistic Style 옵션 목록을 참조하십시오 . 이상적으로, 규칙은 프로그램이 코드를 다시 작성할 수있을 정도로 명확하고 완전해야합니다 (하지만 코드를 작성하지는 않지만;))
명명 규칙의 경우 클래스 / 유형을 변수 / 속성과 쉽게 구별하도록 만들려고합니다.
이 범주에서 "측정"을 다음과 같이 분류합니다.
기타?
마지막으로, 코딩 표준에서 논의되는 경우는 거의 없지만 한 가지 항목이 있습니다. 코드 구성은 각 응용 프로그램에 따라 다르기 때문일 것입니다. 아키텍처 문제는 아마도 가장 뛰어난 문제 일 것입니다. 초기 디자인을 망쳐 놓으면 몇 년 후부터 그 문제에 시달릴 것입니다. 공개 / 개인 헤더, 종속성 관리, 우려 분리, 다른 시스템 또는 라이브러리와의 인터페이스와 같은 기본 파일 처리를위한 섹션을 추가해야합니다.
그러나 이들이 실제로 적용되고 시행 되지 않는다면 아무 것도 아닙니다 .
코드 검토 중에 위반 사항이 제기되어야하며 위반 사항이 해결 된 경우 코드 검토를 수행 할 수 없습니다.
분명히, 규칙을 바꾸는 것은 지도자들로부터 "진보"를 얻는 것을 의미합니다.
나는 프레임 워크 디자인 가이드 라인 의 형식을 좋아하는데 여기에는 가이드 라인에 대한 일반 섹션과 합리성이 포함되어 있습니다. 가장 유용한 비트는 Do, Do Not, 회피 및 고려로 시작하는 세부 사항입니다.
다음은 인터페이스 멤버 구현 섹션의 예입니다. 명시 적으로 다음과 같은 항목이 있습니다 (주목을 설명하기 위해 근거를 삭제했습니다)
강력한 이유없이 인터페이스 멤버를 명시 적으로 구현 하지 마십시오.
인터페이스를 통해서만 멤버를 호출하려는 경우 인터페이스 멤버를 명시 적으로 구현 하십시오 .
명시 적 멤버를 보안 경계로 사용 하지 마십시오 .
마십시오 제공하는 기능이 의미하는 경우> 명시 적으로 구현 구성원으로 동일한 기능을 파생 클래스 전문되는 것을 보호 된 가상 멤버를 제공합니다.
이것은 좋은 일반 톤을 만듭니다. 회피 및 고려를 사용하면 개발자가 자신의 판단을 사용할 수 있습니다. 또한 규칙이 아니라 가이드 라인이기 때문에 개발자는 더 맛있고 결과적으로 따라갈 가능성이 높습니다.
예. 모든 규칙을 사용하는 깔끔하고 비현실적이며 실제에 가까운 예제. 예제의 어느 부분이 어떤 규칙을 따르는 지 주석 (코드의 일부일 필요는 없음).
템플릿. C ++ 종류는 아니지만 복사하여 붙여 넣고 라이브로 채울 무언가. 복사 할 참조가있을 때 24 줄 상용구 주석을 얻는 것이 훨씬 쉽습니다.
코딩 표준은 실제로 몇 가지 항목입니다.
코딩 규칙
모범 사례
예를 들어. 시도 후 빈 캐치를 두지 마십시오
try { Foo(); } catch { //do nothing }
1) Foo ()에 의해 예외가 발생하면 foo가 성공했다고 가정하는 다음 함수에 다른 문제가 발생할 수 있습니다.
2) 전역 오류 처리기는 prod에서 발생할 때 예외를 지원 팀에 알리지 않습니다.
코딩 환경
종이에 쓰여질 때 코딩 표준은 매우 효과적입니다. Go가 코딩 표준을 게시하는 방식이 마음에 듭니다. gofmt프로그램 텍스트를 형식으로 형식화 하는 도구 가 있습니다. 코딩 형식에 대한 토론은의 소스에 대한 패치로 간단히 나타납니다 gofmt.
형식에 대한 내용은
if, 함수 본문, 기타 목적을위한 명령문 블록을 배치하는 방법,다른 사람 (C 언어 대부분) 코드를 읽을 때 변수 / 함수 이름이 프로젝트의 맥락에서 직관적이지 않거나 들여 쓰기 수준이 5 단계를 초과하거나 함수가 6 ~ 7 개 이상의 인수를 취하거나 함수가 이상 실행되는 경우 화면에 2 ~ 3 페이지가 있으면 코드를 읽고 이해하기가 매우 어려워집니다. 개선 / 유지 보수 작업을 수행하라는 요청을 받으면 어려움이 추가됩니다. 그것은 나를 원하는 만드는 gofmt프로그램이이 프로젝트에 최선을 다하고되기 전에이 프로그램을 통해 실행되는 모든 프로젝트 (또는 언어) 모든 소스 코드 파일을 작성할 수있다.
Google JavaScript 스타일 가이드를 좋아합니다 .
지침의 간결하지만 필요한 경우 세부 정보가 있습니다.