조직의 코딩 스타일은 선택 사항입니까?

이 프로그래밍 스타일 문서 에는 일반적인 규칙이 있습니다.

규칙에 대한 강한 개인 이의가있는 경우 규칙을 위반할 수 있습니다.

이것은 내가 생각하는 방식과 충돌하며 코딩 스타일이 실제로 중요하다는 많은 기사가 있습니다. 예를 들어 다음과 같이 말합니다.

코딩 표준 문서는 개발자에게 코드 작성 방법을 알려줍니다. 각 개발자가 선호하는 스타일로 코딩하는 대신 모든 코드를 문서에 요약 된 표준에 작성합니다. 이를 통해 큰 프로젝트는 일관된 스타일로 코딩됩니다. 부품은 프로그래머마다 다르게 작성되지 않습니다. 이 솔루션을 사용하면 코드를보다 쉽게 ​​이해할 수있을뿐만 아니라 코드를 보는 모든 개발자가 전체 응용 프로그램에서 기대할 사항을 알 수 있습니다.

그래서이 문서 의 내용 과이 질문의 맨 위에있는 인용문을 오해하고 있습니까? 사람들은 코딩 스타일을 실제로 무시할 수 있습니까?

어쩌면 나는 충분히 명확하지 않았 으므로이 편집을 통해 조금 명확하게 설명 할 것입니다.

팀의 코딩 스타일 문서를 작성 중이며 일부 정적 분석기를 사용하여 스타일을 확인하고 싶습니다. 실패하면 Jenkins가 이메일을 보냅니다. 스타일이 일치하지 않으면 코드 검토에 실패하고 싶습니다. 이것은 첫 번째 인용문과 분명히 충돌합니다.

그러나 인용문이 옳다면 누군가가 원하는 것을 할 수 있다면 코딩 스타일 문서의 사용법은 무엇입니까?

내가 알 수있는 한, 당신을 혼란스럽게 한 진술은 가이드 라인을 가능한 한 많은 사람들에게 제공하기 위해 만들어진 실질적인 타협입니다. 특정 상황에 따라 (아래에 자세히 설명되어 있음) 상황을 조정하고 지침을보다 효율적으로 사용할 수있는 옵션이있을 수 있습니다.

알다시피, 지침은 위반을 정당화하기위한 수단으로 "강력한 개인 이의 제기"를 참조합니다. 이러한 이의 제기는 특히 숙련 된 개발자가 제공하는 경우 가볍게 무시할 것이 아닙니다.

이러한 반대 의견 은 틀릴 수도 있습니다. 그러나 여러분은 생각하지만 (매우 큰 것입니다) 일반적으로 또는 특정 프로젝트의 맥락에서 특정 규칙이 잘못되었음을 나타낼 수도 있습니다 (규칙 불일치의 한 예는 성능이 중요한 코드에 대한 자세한 로깅).

현명한 스타일 가이드는 위의 내용을 고려해야하고 스스로 조정할 필요를 수용해야한다고 생각합니다. 이제 여러분을 혼란스럽게했던 가이드가 효율적이고 매끄러운 프로세스와 환경을 갖춘 성숙한 팀 만을 대상으로한다면 다음과 같이 명확 하게 설명 할 수 있습니다.

챌린지가 제기 될 때까지 규칙을 엄격히 준수해야합니다.이 경우 챌린지 된 규칙은 챌린지를 거부하거나 수락하고 규칙에 맞게 조정하여 해결 될 때까지 무시해야합니다.

당신은 위의 내용을 더 좋아할 수도 있고, 모든 사람에게 그런 식으로되기를 원할 수도 있지만, "도전이 제기 / 지속적으로 무시 / 조정"되는 부분을 자세히 살펴보고 구현 방법을 스스로에게 물어보십시오. 프로젝트와 팀에 따라 시간이 얼마나 걸릴 수 있는지 자문 해보십시오 . 한 시간이 걸리면 괜찮습니까? 하루, 일주일 또는 한 달이 걸리면 어떻게 되나요?

도전과 무시까지 해결 된 접근법은 프로젝트의 지침으로 제시 될 경우 남용의 폭이 넓어 질 수 있습니다. "그렇습니다. 우리는 여러분의 의견을 듣고, 가이드가 말한대로하겠습니다. 먼저,이 챌린지 양식을 작성하고 CEO / CFO / CTO 승인을 받으십시오. 1 ~ 2 주 정도 걸릴 것으로 예상됩니다. 그 후 코드 검사가 업데이트 될 때까지 기다리십시오. "일주일 또는 2 주가 소요될 수 있습니다. 한편, 성능 결정 코드는 모든 레지스터 이동에 대해 올바른 형식의 로깅 명령문을 구토해야합니다."

가이드 작성자의 마음을 읽을 수는 없지만 위에서 설명한 것처럼 혼란을 정당화하기 위해 가이드를 사용하지 않으려한다고 가정하는 것이 합리적입니다. 이러한 관점에서 본 가이드가 어떠한 시행도하지 않는다고 명확하게 진술하는 것이 더 안전합니다. 그러나이 방법은 서툴지 만, 여전히 광범위한 팀과 프로젝트에 사용할 수 있습니다. 이러한 넓은 허용 범위는 더 성숙하고 효율적인 팀이 개발자의 생산성을 손상시키지 않고 합리적으로 범위를 좁힐 수있는 기회를 제공 할 것으로 예상됩니다.

특정 사례에 적용하여 팀의 코딩 스타일 문서를 작성하고 스타일이 일치하지 않으면 코드 검토에 실패합니다. 개발자가 특정 규칙에 이의를 제기하고 무시하는 데 걸리는 시간을 계산해야한다고 생각합니다. 해결하고 해상도에 따라 변경하거나 복구하십시오.

개발 워크 플로우에 많은 장애를 유발하지 않고이 프로세스를 작동시킬 수있는 방법을 알아 내면, 혼란스럽고 "충분히 울면 위반"대신 공식화되고 추적하기 쉬운 도전 / 해결 방법을 고려해 볼 가치가 있습니다.

부수적으로, 나는 당신이 다른 의견 에서 "코딩 스타일이 이상적이라고 가정하고 그렇지 않은 경우"라고 쓴 것을 언급하고 싶다 .

이것은 실제로 위험한 가정입니다. 나는 광대 한 경험을 가지고 그것에 대해 모든 것을 알고 있다고 생각하는 곳에서 두 번의 프로젝트로 내 코를 부러 뜨 렸습니다. 나는 그것을 떨어 뜨릴 것을 강력히 권장합니다. 스타일 가이드에 실수가있을 수 있다고 가정하고 그러한 실수가 발견 될 경우 어떻게해야할지 생각하는 것이 더 안전합니다.

개인적인 취향 때문에 사람들이 코딩 스타일을 무시하도록 하는 것은 나쁜 생각입니다.

귀하의 질문에 인용 된 것은 모든 개발자가 단순히 "이 스타일을 좋아하지 않기 때문에 사용하지 않을 것"이라고 말할 수있는 것 같습니다.

이것은 모든 요점을 거스 르므로 팀의 모든 사람이 일관성과 가독성을 위해 동일한 방식으로 작업을 수행하게합니다.

나는 그러한 진술을 한 스타일 문서가 무의미하다는 데 동의합니다.

그럼에도 불구하고 스타일 가이드 라인을 준수 할 때 약간의 유연성이 권장됩니다.

• 가이드 라인을 따르지 않으면 특정 코드를 작성하는 가장 좋은 방법을 막을 수 있습니다 . 개발자는 지침을 무시하고 자신이 한 일이이 경우에 무언가를 달성하기위한 가장 읽기 쉬운 방법이라고 주장 할 수 있어야합니다.
• 레거시 코드를 사용하려면 유연성이 필요할 수 있습니다. 기존의 큰 코드 기반을 다시 스타일링하는 데 시간을 잘 사용하지 않는 것이 좋습니다. 특정 섹션을 크게 다시 쓰면 선호하는 스타일로 다시 포맷 할 수 있습니다. 그러나 약간만 변경하면 코드의 기존 스타일을 사용하는 것이 좋습니다.
• 스타일 가이드를 조금만 위반해도 시간을 잘 사용할 수는 없습니다. 코드 검토는 팀의 스타일과 크게 다른 코드를 강조하기에 좋은시기입니다. 그러나 작은 스타일의 "실수"를 포착하고 고치는 것은 잘못된 일에 초점을 맞춘 바쁜 일이 될 것입니다. 스타일이 명백히 무시되면 코드 검토에 실패합니다. 그러나 나는 분석기를 실행하고 잘못 배치 된 모든 괄호 또는 들여 쓰기를 지적한다는 아이디어가 마음에 들지 않습니다.

결론 : 팀의 요구를 가장 잘 충족시키기 위해 스타일 가이드 라인을 유연하게 준수 할 수 있지만 개인 취향과 같은 임의의 이유는 아닙니다.

코딩 스타일 및 스타일 가이드는 코드를 더 읽기 쉽게 만드는 데 도움이됩니다. 그리고 가독성은 복잡성을 돕기 위해 존재합니다.

따라서 궁극적으로 조직의 요구에 맞는 코딩 스타일을 위반할 것인지 (적용이라고 부를 것인지) 여부는 사물을 이해하기 쉽게 만드는 데 도움이됩니다.

OO 프로그래밍에서 기능적 패러다임, 다양한 동시성 모델에 이르기까지 모든 것, 그리고 모든 스트레스는 사람들이 복잡성을 다루는 데 도움이되는 유일한 이유 때문에 존재한다는 것을 기억하십시오.

어떤 바보라도 컴퓨터가 이해할 수있는 코드를 작성할 수 있습니다. 훌륭한 프로그래머는 인간이 이해할 수있는 코드를 작성합니다. -마틴 파울러, 2008

조직의 코딩 스타일은 선택 사항입니까?

조직은 코딩 스타일을 선택합니다. 우선 코딩 스타일이 필요하지 않습니다.

그래서 당신이 읽고있는 인용문은 코딩 "스타일"과 실제 슈퍼 스타 "해커"와 관련하여 가장 큰 문제를 다루고 있습니다. 당신은 새로운 사람을 데리고 와서 좀비를 떨어 뜨리고 오래된 서버를 빠르게 비명을 지도록하는 코드를 작성합니다. .. 그러나 그의 코딩 스타일은 "허용되는 조직 스타일"과 다릅니다. 그는 변화를 거부하고 모든 사람이 자신의 특정 스타일 을 따르도록하는 과정은 시간이 많이 걸리고 비싸다. 이제 뭐?

내가 알고있는 슈퍼 해커의 대부분은 자신의 능력으로 대형으로 자아와 함께, 그들은 조직에 적응하려는 그들 , 다른 방법은 주위에. 따라서 코딩 스타일 표준 은 코딩 스타일 지침 과 비슷해야 하므로이 킬러 해커가 스타일 이탈을 사용하여 타오르는 빠르고 놀라운 코드를 계속 작성할 수는 있지만 다른 사람들이 자신의 서사적 해커에 도달 할 때까지 다른 사람들이 이해해야합니다. 상태에 따라 규칙을 준수해야합니다 (또는 그를 정리하는 데 도움이 됨).

물론 이것은 관리의 악몽이지만 일반적으로 기술 인력을 관리하는 것은 어쨌든 고양이를 방목하는 것과 같습니다. 따라서 대부분의 회사에는 "스타일 표준"이 아닌 "스타일 지침"이 있습니다. 또한 모든 회사의 스타일 위반으로 인해 빌드가 실패하지 않고 코드 검토가 자동으로 실패하지 않습니다. 수퍼 스타 해커를 허용하고 "지침"을 갖거나 수퍼 스타를 잃어 버리고보다 일관된 코드 스타일을가집니다.

그래서이 문서의 내용 과이 질문의 맨 위에있는 인용문을 오해하고 있습니까? 사람들은 코딩 스타일을 무시할 수 있습니까?

따라 다릅니다.

내가 현재있는 곳에는 스타일 가이드가 없으며 별거 아니에요. 프로그래머간에 약간의 차이가 있지만 의미있는 방식으로 가독성, 검색 가능성 또는 일관성에 영향을 미치지는 않습니다. 그리고 우리는 팀의 새로운 구성원이 모두 줄을 서도록 강제 할 수있는 충분히 큰 그룹과 강한 문화를 가지고 있습니다.

이전 회사에서는 빠르게 성장하고 있었고 언어와 관용구에 익숙하지 않은 사람들이있었습니다. 그 회사에서 사람들의 유입은 글을 잘 쓰는 문화가 없다는 것을 의미했습니다. 그리고 언어에 익숙하지 않은 사람들은 조정할 것이 많았습니다. 이 자동화 된 스타일 체커는 조정을 가장 효율적인 방법이었고, 실제 작성 가이드는 우리의 기대에 새로운 사람들을 훈련하는 가장 좋은 방법이었다.

개인적으로 스타일 가이드는별로 신경 쓰지 않고 자동화 된 스타일 적용은 그다지 중요하지 않습니다. 사람이 기본 관용구를 집어들 수 없다면 왜 프로그래머로 고용합니까? 그리고 그들이 나쁜 팀 플레이어라면 다른 사람들이 다루기 어려운 코드를 지속적으로 작성한다면 왜 그 사람들을 고용하고 있습니까?

이것은 코딩 스타일을 관리하는 가장 좋은 방법에 대한 문자 적 ​​해석 대신 심리적 공헌입니다. 팀 / 회사 / 관리자 / 리더가 권위를 떨어 뜨립니다. 나는 개인적이 아닌 상황 적 예외에 더 집중할 것이다. 코딩 문서에 관계없이, 목표는 사물을 쉽게 읽을 수 있도록하는 것입니다. 필요한 경우 혼란스러운 코드를 해결하고 변경해야합니다. 작은 지루한 것들을 처리하는 많은 도구가 있으므로 사용하십시오.

모든 규칙에는 예외가 있습니다. 사람들에게 "일부"흔들기 방을 제공하십시오. 코딩 스타일 규칙 (환영하는 새로운 사람)을 받아들이는 사람이 적을수록 더 많은 사람들이 반격하기를 원합니다. 많은 것들이 흑백이지만, 일부는 해석에 개방적입니다.

모든 세부 사항과 해석에 대항하는 대신 모든 사람이 코딩 지침의 정신에 참여하도록하는 것이 목표입니다.

그렇습니다. 코딩 스타일 문서가 사용하기에 합리적이지 않을 때가 있으며 전문 개발자와 성인 개발자가 그 차이를 알아야합니다.

수정 한 내용을 바탕으로 올바른 목표를 목표로합니다.

스타일 가이드를 사용하면 많은 이점이 있지만 제 생각에 가장 중요한 두 가지는 팀 구성원 간 코드의 가독성과 "어리석은"커밋 (공백 만 또는 추가 줄 등)이 없다는 것입니다.

목표를 달성하려면 선택한 스타일 가이드가 간단하고 준수하기 쉬워야합니다. 실제로 필요한 것에 집중하십시오. 린터를 행복하게하기 위해 거대 코드 견본을 다시 작성하는 것을 좋아하는 사람은 없습니다. 그러나 여전히 이점이있을 수 있습니다.

팀원이 스타일 가이드를 승인하도록하십시오. 당신이 그들을 붙잡을 것입니다, 그들이 동의하는지 또는 그것이 영원한 투쟁이 될 것입니다.

스타일 위반이 "실패"가 아닌 "경고"인지 확인하고 위반이 실패에 해당하는지 사람이 결정하도록합니다. 그 이유는 간단합니다. 나는 간단한 작업 흐름을 믿습니다. "테스트"단계에서 "실패"가 발생하면 프로덕션으로 푸시 할 수 없습니다. 나는 안전으로 사용합니다. 핫픽스도 테스트 단계를 거쳐야합니다 (더 짧아도). 누군가가 '대신'를 사용했기 때문에 중요한 버그 수정을 프로덕션에 적용하지 않을 것이라고 말할 수 있습니까? 각각 대신에 for 루프를 사용하는 것은 어떻습니까? 기계 (리터)가 내릴 수없는 결정이므로, 사람이 있는지 확인하고 경고를 판단하고 기계가 고장 나지 않도록하십시오.

스타일 가이드를 무시하려면 사례별로 판단해야합니다. "편차"에 실제 이유가 있는지 확인하십시오. 그들은 올 것이다. 검토 자의 임무는 사소한 것이 아니라 편차에 대한 정당한 이유가 있는지 확인하는 것입니다.

나는 기분 음악이 여기에서 받아 들여진 지혜가 코딩 표준이 부정확하거나 불완전하다는 것이라면, 개발자가 일반적인 동의를 얻는 것이 어려운 과정을 거치지 않고 눌렀을 때 두 가지 악이 적다는 것입니다. 문서가 변경되고 재검토되었습니다.

또한 지난 해의 코드 표준 시행 정책은 일반적으로 현재 수행되고있는 방식이 아니라는 점에 유의해야합니다.

예전에는 개발자 데스크 끝에서 고서를 들고 챕터를 인용하고 왜 코드가 34.5.5767을 위반 하는지를 인용했습니다.

우리는 이제 정적 코드 분석과 자동 문서화 도구를 사용하여 많은 코드 표준을 버리고 있습니다.

이 모든 것에 실패하면 개발자에게 다시 던지거나 코드 검토에서 제기하거나 기울어지면 직접 변경할 수 있습니다.

귀하의 질문은 두 따옴표를 조정하는 데 중점을 둡니다. 나는 treecoder가 쓴 것이 일반적으로 귀하의 질문에 대답한다고 생각합니다. 스타일 가이드 라인 작성에있어 가이드 원칙을 나타냅니다.

더 구체적으로, 당신은 코딩 스타일 가이드 라인 (문서 작성자이기 때문에 나의 가정 임)을 설정해야 할 책임이 있기 때문에, 선택 사항인지 아닌지, 그리고 개인 스타일의 유연성을 어느 정도 허용 할 것인지 결정할 수 있습니다. 팀. 필요한 경우 피드백을받습니다. 그러나 일단 지침이 제정되면이를 준수하십시오.

따라서 다음과 같이 두 가지 상충되는 내용을 조정할 수 있습니다.

가이드 라인 문서가 완성되기 전에 첫 번째 인용문을 스타일 결정권자로 생각하십시오. 특정 스타일 표준이 팀에 적합하지 않은 경우 이는 "강력한 개인 이의 제기"로 간주되며 가이드 라인에 반영됩니다.

문서가 완성 된 후 팀에 전달 된 두 번째 인용문을 생각하십시오. 팀에 대한 지침을 설정하고 문서를 작성한 후에는 팀의 모든 개발자가 스타일 지침을 준수하는 것이 중요합니다.

코딩 스타일이있는 한 사람들이 갖는 코딩 스타일은 그다지 중요하지 않습니다. 회사가 코딩 스타일을 고집하는 경우 개발자의 약 49 %가 발가락을 크게 밟습니다.

문제는 많은 개발자들이 코딩 스타일을 회사의 일반적인 표준에 크게 적응시키는 것을 신경 쓰지 않지만 회사 정치에 능숙한 (또는 더 많은 관심을 가진) 사람들에게 많은 것을 듣고 있다는 점입니다.

즉, 코딩 스타일 표준을 만드는 것은 엄청난 시간 낭비, 끝없는 논쟁의 원천, 무한한 분개의 원인 및 전체적으로 엄청난 시간과 에너지 소모가 될 수 있습니다.

이 포럼에서 다른 많은 사람들이했던 것처럼 몇 년 동안 코드 스타일 가이드 라인을 다루었습니다. 여기에는 내가 싫어하는 싸움 스타일 가이드와 다른 사람들이 스타일 가이드를 사용하여 자신의 스타일로 다시 장려하도록 독려하는 것이 포함됩니다.

회사는 공통 코딩 표준의 혜택을받습니다. 회사를 위해 소프트웨어를 개발할 때 고려해야 할 중요한 사항이 있습니다. 예를 들어, 새로운 개발자가 이전 세대의 코드를 선택하도록 훈련시키는 방법과 같습니다. 코드를 작성할 때 항상 이것에 대해 생각하지는 않습니다. 실제로, 많은 코더들은 다른 사람들이 코드가 사라진 후 5 년 또는 10 년 후에 어떻게 접근하고 싶어하는지조차 고려하지 않기로 선택합니다. 코딩 스타일 가이드는 기업이 이러한 5 년 및 10 년 목표에 중점을 두는 방법으로 개발자가 더 큰 계획에서 작업하기가 더 쉽습니다.

반면에, 코딩 스타일 가이드는 완벽한 코딩 스타일을 개발하고 기록 할 수 없기 때문에 불완전하게 불완전합니다. 수학적 증거를 완벽하게 만들려고 시도하면 수학 증거가 실패하기 시작하는 재미있는 모퉁이 사례가 실제로 시작됩니다. 코딩 스타일 가이드가 불완전하다는 것을 알고 있습니다. 5 년에서 10 년이 걸리는 것에 초점을 맞추지 못할 수도 있습니다.

코딩 스타일을 "강화"하면 나중에 가치를 위해 가치를 희생하게됩니다. 우리가 우리의 노력에 대한 수익을 얻을 것이라고 확신 할 수 있다면 이것을 "투자"라고 부를 수 있지만, 코딩 스타일 가이드를 제대로 작성하지 않은 개발자는 개발자의주의를 산만하게함으로써 "가독성"이 크게 향상되었음을 증명할 수 있습니다 그들의 코드에서 멀어 지십시오. 내 경험상, 30 년 또는 40 년 동안 소프트웨어를 사용할 수있는 독창적 인 빙하 고객을위한 소프트웨어에서 강제 코딩 스타일에 장점이있는 경우는 매우 적습니다!

대신 코딩 스타일 가이드를 선언문으로 취급하는 것이 가장 효과적이라고 생각합니다. "이것은 그룹에 가장 적합한 코딩 스타일이라고 생각합니다." 말로 기록 된 유동적 인 생각의 무리입니다. "믿다"라는 단어가 중요합니다. 신념이 바뀌면 코딩 스타일 가이드도 이에 따라 바뀌어야합니다.

이것은 "강력한 개인 이의 제기"인용문이 나오는 곳입니다. 내가 "완벽한"세상이라고 부르는 것에서, 당신은 당신이 가장 느끼는 코드를 작성하고 그 결과로 살아갑니다. 우리는 프로그래밍 할 때 종종 "부드러운"결과를 간과하기를 원하지만이 경우에는 중요합니다. 나는 당신에게 나름대로 중요하고 오래 지속되는 어떤 것도주지 않아도 괜찮다면 자신의 스타일로 쓰는 데 아무런 문제가 없습니다.

전체 시스템을 골프 코스처럼 생각하십시오. 코딩 스타일은 페어웨이를 향한 쉬운 길을 열어줍니다. 코딩 표준을 준수한다면 인생을 최대한 쉽게 할 수 있습니다. 고유 한 코딩 표준을 사용하여 거칠어 질수록 팀의 가치를 더 많이 입증해야합니다.

월요일 아침에 와서 1 주일 동안 문제를 풀면서 주말 내내 보낸 문제를 발견하고 자신의 "특별한"코딩 표준으로 문제를 해결했다면 고치세요. 샤워하러 가라고하겠습니다. "특별한"코딩 표준이 예외적으로 "특별한"경우, 엔트리 레벨 개발자에게 코드의 작동 방식에 대한 지식을 널리 알리기 위해 코드를 "검토"할 것을 제안 할 수 있습니다. 정리해 그 주말에 회사에 충분한 가치를 제공하여 귀하가 저지른 엄중 한 코딩 표준 위반에 대해서는 언급 할 가치가 없습니다.

물론이 골프 비유에는 한계가 있습니다. 순위와 파일 작업을 수행하고 양식에 새 필드를 추가하도록 요청하고 매크로 정의와 같은 그늘진 문자를 사용하여 특정 양식에 맞게 전체 양식 작성 코드를 리팩터링하는 기회를 사용하기로 결정한 경우 스택 교환에서 방금 배운 신기한 템플릿 메타 프로그래밍 기술로 돌아가서 수정해야합니다. 당신은 행동하기로 선택했는데, 그 결과입니다.

( 면책 조항 : 나는이 사악한 과제를 해결하기 위해이 구현을 작성 is_base_of했으며, 선임 개발자로부터 얻은 모든 지옥을 얻었습니다. 나는 그만한 가치가 있다고 말합니다. 는 C의 7 개 관련이없는 부분을 함께 ++ 사양과 같은 그 패턴 웨지 놀라운 일을 수행하는 방법에 봐. 그게 당신이 금지 무엇을 얻을!, 당신의 수석 개발자를 가져가 boost이 특정 프로젝트에! )

거의 모든 하급 IDE의 내장 기능인 거의 모든 프로그래밍 언어에 대해 존재해야하는 자동화 된 코드 포맷터를 사용하는 것이 가장 좋습니다. 이를 통해 코드 검토 중에 불필요한 작업과 마찰이 많이 제거됩니다.

모든 개발자가 포맷터를 새로 작성된 코드 섹션에 적용하는 습관을 개발하도록 요구하는 것이 합리적입니다.

최악의 방법은 기존 코드 포맷터가 지원하지 않는 사용자 지정 코딩 스타일을 요구하는 것입니다.

상대적으로 드문 경우이지만 포맷터가이 작업을 정말로 끔찍하게 수행하는 경우 일부 섹션의 형식이 다르게 지정 될 수 있지만 일반적으로 모든 사람이 더 잘 포맷하도록 포맷터를 조정하는 것이 좋습니다.

포맷터가 지원할 수없는 유용한 규칙 (예 : 변수 이름 지정 방법) 일 수 있지만 이러한 규칙 만 남아 있으면 비교적 쉽게 따라갈 수 있습니다.

실제 해결책 (철학뿐만 아니라)

코드 주석이 보푸라기를 재정의하고 원하는 경우 주석 목록을 컴파일합니다 (할일 주석으로 자주 수행됨)

개발자가 컨벤션 외부에서 명시적이고 이유없이 작업 할 수있는 능력을 부여하십시오. 사람이 코드를 검토하는 동안 필요에 따라이를 면밀히 조사 할 수 있습니다.