모든 개발자에게 동일한 코드 형식을 적용하는 것이 좋은 생각입니까?

프로젝트에 단일 표준 코드 형식 (Eclipse에서 저장 조치가있는 자동 형식)을 적용하려고합니다. 그 이유는 현재 여러 개발자 (> 10)가 사용하는 코드 형식에 큰 차이가 있기 때문에 한 개발자가 다른 개발자의 코드를 다루기가 더 어렵 기 때문입니다. 동일한 Java 파일은 때때로 3 가지 다른 형식을 사용합니다.

따라서 이점이 분명하다고 생각하지만 (가독성 => 생산성) 이것을 적용하는 것이 좋습니다? 그렇지 않다면 왜?

업데이트
우리는 모두 Eclipse를 사용하며 모든 사람들이 계획을 알고 있습니다. 이미 대부분의 코드 형식이 사용되었지만 일부는 자체 코드 형식을 선호하기 때문에 적용되지 않습니다. 위의 이유 때문에 일부는이를 시행하는 것을 선호 할 것입니다.

나는 현재 표준 코드 형식이 적용되는 곳에서 일하고 있으며 파일을 저장할 때 코드가 자동으로 형식이 지정됩니다. 회사의 새로운 회원으로서 나는 일반적인 서식 규칙이 "이 사람들이하는 일을 알고있다"는 따뜻하고 애매한 느낌을 주었기 때문에 더 행복해질 수 없다는 것을 알게되었습니다. ;) 관련 측면에서, 일반적인 형식 규칙을 사용하여 Eclipse에서 특정의 엄격한 컴파일러 경고 설정을 시행합니다. 이들 대부분은 오류로 설정되고 대부분 경고로 설정되고 거의 무시로 설정되지 않습니다.

프로젝트에서 단일 코드 형식을 시행해야하는 두 가지 주요 이유가 있다고 말하고 싶습니다. 먼저 버전 제어와 관련이 있습니다. 모든 사람이 코드를 동일하게 형식화하면 파일의 모든 변경 사항이 의미가 있습니다. 더 이상 여기나 저기에 공간을 추가하거나 제거 할 필요없이 전체 파일을 실제로 한 줄 또는 두 줄만 바꾸는 "부작용"으로 다시 포맷하는 것은 아닙니다.

두 번째 이유는 프로그래머의 자아가 방정식에서 빠져 나가기 때문입니다. 모든 사람이 같은 방식으로 코드를 포맷하면 더 이상 누가 무엇을 썼는지 쉽게 알 수 없습니다. 이 코드는보다 익명의 공용 속성이되므로 아무도 "다른 사람의"코드를 변경하는 것에 대해 불안 할 필요가 없습니다.

주된 이유는 다른 것들도 있습니다. Eclipse가 저장하면 자동으로 처리하므로 코드 형식에 대해 생각할 필요가 없습니다. LaTeX로 문서를 작성하는 것과 같이 걱정할 필요가 없습니다. 나중에 형식이 지정되므로 글을 쓸 때 걱정할 필요가 없습니다. 또한 모든 사람들이 자신 만의 스타일을 가지고있는 프로젝트에서 일했습니다. 그런 다음 자신의 스타일로 다른 사람의 코드를 수정해도 괜찮은지 또는 대신 스타일을 모방해야하는 등 어리 석고 의미없는 문제에 대해 생각해야합니다.

내가 생각할 수있는 일반적인 코드 형식 설정에 대한 유일한 주장은 이미 진행중인 프로젝트이므로 모든 파일에 불필요한 변경이 많이 발생하여 실제 파일 기록을 망칠 것입니다. 가장 좋은 시나리오는 프로젝트 시작부터 바로 설정을 시작할 수있는 경우입니다.

모든 전문 소프트웨어 개발자는 스타일에 대한 복음 전쟁보다는 (좋은) 표준을 채택하는 것을 선호 할 것입니다. 바로 그 이유 때문입니다.

많은 소프트웨어 개발자들이 복음 전쟁을 벌입니다 .......

팀 내에서의 위치와 팀 역학에 따라 전쟁에서이기는 것이 불가능하다고 결정할 수 있습니다. 이 경우 시작하지 않는 것이 가장 좋습니다 ...

예, 모든 개발자에게 하나의 코드 형식 스타일을 갖는 것이 좋습니다.

코드 스타일 형식을 디자인하고 모든 개발자 일식으로 가져옵니다.

이것은 우리가 merging'버전 제어'시스템으로 코드를 만들 때 도움이 될 것 입니다.

무엇을 얻으려고 노력하고 있는지, 항문 유지력을 강화하기 위해 (그리고 규칙의 세부 수준에서), 다른 언어로 작성된 코드에서 시행하려고합니까? 기존 코드에서 소급 적용하려고합니까?

1. 일반적인 모양과 느낌의 코드는 실제로 코드를 더 읽기 쉽게 만들 수 있지만 모양과 느낌이 잘못된 경우 상황을 악화시킬 수 있습니다. _hUngarian_lpfstr 표기법이 대표적인 예입니다. :)
2. 주석 블록 내에서 공백의 수, 메소드 이름의 알파벳 순서 및 기타 넌센스를 적용하는 "코드 표준"을 보았습니다. 하지마
3. 언어마다 사용 경험이 많은 사람들이 사용하는 표준이 다릅니다. 어떤 사람들은 이러한 표준을 요구합니다 (Python, Cobol, Visual Studio는 자동으로 C ++ 스타일 브레이스 규칙을 부과하는 반면 Java는 C 스타일을 규칙 등으로 사용한다고 생각합니다).
4. 코드를 변경하기 위해 기존 코드를 변경하지 마십시오. 새로운 문제가 발생하는 것입니다. 그리고 이는 전체 소스 파일뿐만 아니라 코드 섹션을 의미합니다. 누군가 1000 줄 파일에서 한 줄을 변경할 때 기존 코드를 다시 포맷하지 마십시오.
5. 숙련 된 프로그래머는 자신이 작성하는 내용이 자동 승인 시스템 또는 검토 자에게 "올바른 것처럼 보일"것인지 절반 만 생각할 필요가 없다면 훨씬 더 생산적 일 수 있습니다. 또한 자연스런 스타일 사이에 작은 차이가 있더라도 깔끔한 코드를 작성하는 습관을 들이게됩니다.

따라서 특정 스타일과 표준을 적용해야 할 이유가 있지만 엄격하게 그렇게하지 않는 이유도 있습니다.

그렇습니다 . 다른 사람들 이 언급 한 이유로 일관성은 좋은 생각 입니다.

다른 곳에서는 사용하지 않은 몇 가지 사항을 추가하고 싶었습니다.

• 오라클은 사실상의 표준 인 Java에 대한 일련의 규칙 을 발표 했습니다 .
  • 이것들을 사용하면 어떤 스타일을 따라야하는지에 대한 논쟁을 피할 수 있습니다.
  • 많은 공용 라이브러리와 오픈 소스 프로젝트는 이러한 규칙을 사용하는 경향이 있으므로 이러한 규칙을 살펴 보려면 형식을 잘 알고 있어야합니다.
  • Eclipse 포맷터에는 이러한 규칙에 맞는 내장 규칙이 있으며,이 규칙도 도움이됩니다.
• 코드가 메인 브랜치에 들어가기 전에 자동 형식화되도록 소스 제어 설정에 연결하는 것을 고려할 수 있습니다.
  • 표준을 따르기를 거부하는 특히 완고한 프로그래머와의 전투를 피할 수 있습니다. 작업하는 동안 자체 형식을 사용하여 나중에 표준화 할 수도 있습니다!
  • 사용자 지정 서식 설정을 사용하는 경우 (예 : 많은 사람들이 "한 줄에 최대 80 자"규칙을 무시하는 경우) 한 곳에서만 변경하면됩니다.

Checkstyle 플러그인 을 사용하는 팀에있었습니다 . 기본 제공 기능을 사용하는 대신 관심있는 개발자로 구성된 소규모위원회를 구성했습니다. 우리는 잃어버린 것처럼 보이는 것, 과도한 것처럼 보이는 것, 물건을 망치는 것에 대해 토론했습니다. 우리 모두는 그 과정에서 무언가를 배웠고 개발자 근육을 강화했습니다.

(우리의 결정의 예 : 너비가 72 자 (자)는 너무 작지만 120자가 더 낫습니다. 정적 결승에는 _ALLCAPS를 사용하는 것이 좋습니다; 함수에서 단일 종료를 시행하는 것이 좋습니다.)

코드 리뷰를 받았을 때 첫 번째 질문 중 하나는 "Checkstyle을 통해 코드를 실행 했습니까?"였습니다. 코딩 표준을 준수하는 것이 대부분 자동화되었으며 검토자가 까다로워 관심을 끌지 못했습니다. Checkstyle이 메소드 서명을 강조 표시하고 마우스 오른쪽 단추를 클릭 한 후 변수를 final로 변경하는 것은 매우 쉽습니다. 또한 들여 쓰기와 중괄호를 수정하여 모든 사람의 코드가 비슷한 모양과 느낌을 갖도록 할 수 있습니다. 공용 함수에 대한 Javadoc이 없습니까? Checkstyle은 기능을 플래그합니다.

(일관된 서식보다 코드 냄새를 제거하는 것이 더 중요합니다. 이는 자동화 된 도구의 이점입니다.)

Checkstyle과 같은 자동화 도구 는 같은 형식 을 강요 하는 것 보다 덜 하고 비슷한 모양과 느낌 을 장려 합니다. 고양이를 잡을 때 자동화 된 도구를 사용하면 깨지기 쉬운 자아를 손상시키지 않으면 서 기술을 연마하고 코드 냄새를 줄일 수 있습니다.

동일한 IDE를 사용하고 일부 서식 도구를 통합하려는 경우 너무 많은 노력이 필요하지 않으므로 좋은 생각입니다. 항문 보유가 아닌 가독성에 중점을 두어 규칙을 단순하게 유지하십시오 . 그것은 측정 스틱이어야합니다.

일관된 형식의 진흙 공은 단지 진흙 공보다 낫지 만, 괄호가가는 곳이 너무 까다 롭지 않고 시간을 보내는 것이 좋습니다. 코드 검토 중에 들여 쓰기 공간을 세고 새 표지가 TPS 보고서에 있는지 확인하여 업무를 수행하고 있다고 느끼는 핀 헤드 관리자에게로 향하지 마십시오 .

개인적인 취향은 그저이며 생산을 거의 개선하지 않습니다 : https : //.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

그렇다면, 그것을 극복하고 무언가를하십시오.

인간은 코드 형식을 적용하고 사소한 위반 사항도 간과하거나 간과 할 것을 강력히 권장합니다. 이에 대한 이유는 간단히 말해서

1. 최악의 시간에, 그리고 일반적으로 새로운 언어 기능을 사용하는 경우 기기에 문제가 발생합니다. Java 등에서 클로저를 어떻게 처리합니까? Jalopy는 멤버 함수가있는 열거 형에 문제가 있습니다.
2. 회사 코드처럼 보이는 회사의 코드를 작성하도록 프로그래머에게 맡기는 것은 매우 합리적인 부담이라고 생각합니다. 이것이 코드의 형식이 "여기"이며 모든 코드의 형식이 어디에서나 형식화되는 방법이 아니라는 점을 언급하면 ​​도움이됩니다. 이전 회사는 다른 경로를 선택했을 수도 있습니다. 모국어와 달리 코드 문화에 특화된 관용구가 있습니다.
3. 코드 구문 적용은 코드 검토를 통해 가장 잘 수행됩니다.
   1. 형식이 중요한 경우 조직에서 코드 검토를 수행하는 것보다 중요합니다. 이것은 큰 이점입니다.
   2. 서식 규칙을 위반하면 의도를보다 명확하게 전달할 수 있으면 사람이이를보고 기계보다 더 잘 판단 할 수 있습니다. 이것은 매우 드물지만 가끔 발생합니다.

"가독성 => 생산성"과 관련하여 코드 구조 (예 : 단일 책임 클래스 및 함수)는 코드 형식보다 훨씬 빠르게 구매합니다. 코드 서식은 도움이 될 수 있지만, 다른 생각은 문장을 다르게 해석합니다. 모든 사람이 "생산적"이되는 것은 아닙니다. 형식화에 대한 코드 구조를 두 번 설명하고 싶습니다. 코드 검토를 수행하고 팀이 단일 루프 모양이 아닌 프로그램 작동 방식에 대해 생각하게하기 때문입니다.

저는 Domain Driven Design의 열렬한 팬은 아니지만 코드 구성 방식 및 코드 형식 지정 규칙이 Domain Driven Design 구조화 프로그램에서 자연스럽게 흘러가는 방법에 대해 매우 잘 정의 된 최신 모델 중 하나입니다. 다시 ... 나는 DDD를 좋아하지 않지만 잘 정의되어 있기 때문에 좋은 예입니다.

이 답변의 주제는 코드 검토 를 수행하고 문화 및 검토 프로세스에서 서식이 흐르도록합니다.

일반적으로 합리적인 개발자를 고용한다고 가정하면 범용 코드 형식을 적용하는 것은 좋지 않습니다. 그러나 코드 지침 을 채택하는 것이 좋습니다 .

모든 경우에 가독성을 최적화하는 일련의 코드 형식 규칙을 본 적이 없습니다. 마찬가지로 영어에는 100 % 적용 가능한 문법 규칙이 없습니다. 우리의 두뇌는 그렇게 연결되어 있지 않습니다. 따라서 가이드 라인을 사용하되 개발자에게 적합하다고 생각되면이를 무시할 수있는 자유를 부여하십시오.

"파일 / 프로젝트에 이미 존재하는 코드 규칙을 따르십시오"라는보다 엄격한 규칙이 좋습니다.

그러나 서식은 코드의 논리적 구성보다 가독성에 훨씬 덜 기여한다는 점을 명심하십시오. 나는 완벽한 포맷을 가진 읽을 수없는 스파게티 코드를 많이 보았습니다!

나는 이것에 대한 간단한 대답이 없다고 생각합니다. 예 또는 아니오 질문이 아닙니다. 스타일과 명명 규칙이 어느 정도 중요하다고 생각하지만 너무 많은 시간을 낭비하는 것도 쉽습니다. 예를 들어 대답하는 것이 가장 좋습니다.

내가 한 특정 프로젝트에서 컨벤션이 전혀 없었습니다. 모든 개발자는 자신의 방식으로 작업을 수행했습니다. 이 팀의 상대적인 경험이 없기 때문에 한 학급에서 다음 학급으로가는 것은 정말 잘못된 일이었습니다. 스타일은 명명 규칙 문제보다 문제가 적습니다. 한 개발자는 끔찍한 헝가리어 표기법 (현대 IDE 시대의 어리석은 관행)으로 UI 요소를 참조하고, 개인 멤버는 한 가지 방법으로, 다른 멤버는 다르게 명명합니다. 당신은 당신이 무엇을보고 있는지 전혀 몰랐습니다.

반대로 극단적 인 한 팀에서는 빌드 프로세스의 일부로 StyleCop (.Net 프로젝트)을 사용했습니다. 더 나쁜 것은 그들이 대부분의 기본 규칙을 사용했다는 것입니다. 따라서 줄 간격 또는 중괄호 배치와 관련하여 완전히 정상적인 작업을 수행하면 빌드로 인해 빌드가 중단됩니다. 공간과 줄을 물건에 추가하는 데 많은 시간이 낭비되었으며 StyleCop을 사용한다고 주장한 친구들을 포함하여 모든 사람들이 거의 모든 커밋을 끝냈습니다. 그것은 엄청난 시간과 돈 낭비였다.

제가 여기서 만들고자하는 요점은 융통성이 없다는 것이 답이 아니라 서부에도 있다는 것입니다. 진정한 대답은 가장 의미있는 장소를 찾는 것입니다. 제 생각에는 자동화 된 도구로 물건을 검사하지 않고 바람에 관습을 던지지 않는 것입니다.

일반적인 코딩 스타일에 대한 나의 주요 주장은 숙련 된 프로그래머가 자신의 스타일을 읽는 데 사용된다는 것입니다. 특정 스타일을 쓰도록 손을 훈련시킬 수는 있지만, 싫어하는 스타일을 이해하기 위해 눈을 훈련시키는 것은 거의 불가능합니다. 프로그래머는 일부 코드를 한 번 작성한 다음 개발 및 디버깅 중에 반복해서 읽습니다. 그가 자신의 코드를 읽을 때마다 BAD 스타일로 코드를 작성해야했기 때문에 코드를 이해하려고 애쓰면 매우 불행하고 생산성이 떨어집니다. 이것은 내 경험에 의한 것입니다.

나는 Eclipse에 익숙하지 않지만 끔찍한 아이디어와 같은 소리를 저장할 때 자동 형식입니다. 개발자는 코딩 스타일의 적용 여부에 관계없이 자신의 코드를 완전히 제어 할 수 있어야합니다. '저장'작업은 사용자의 명시적인 동의없이 단일 문자를 변경해서는 안됩니다.

회사에서 소스 코드를 판매하는 경우 코딩 스타일이 더 중요하지만 컴파일 된 코드를 판매하면 관련성이 떨어집니다.

코딩 스타일이 원래의 코더를 덜 구별하고 자아 전쟁을 방지하기를 희망하는 것은 가장 좋은 경우에는 헛소리이고 최악의 경우에는 멍청한 짓입니다. 훌륭한 프로그래머는 스타일에 관계없이 항상 우아한 코드를 생성합니다.

또한 모든 개발자에게 특정 코드 단위의 소유권을 부여하고 모든 사람이 모든 코드를 자유롭게 만질 수 없도록 강력하게 프로합니다. 코드에서 전체 단위를 개발하고 책임을지게되면 개발자는 자신의 작업에 대한 자부심을 키우고 버그를 찾아서 사냥을하기 위해 엉터리 코드를 개발하는 것을 막을 수 있습니다.

마지막으로, 프로 코딩 스타일을 가진 사람은 항상 자신의 코딩 스타일을 선택하고 다른 모든 사람들이 따를 것이라고 가정합니다. 모든 공동 개발자가 가장 선호하는 코딩 스타일이 표준으로 선택되었다고 상상해보십시오. 여전히 코딩 스타일을 선호 하는가?

그들 모두를 지배하는 하나의 형식은 ... 정말 최적입니까?

다른 사람의 차를 운전하는 것과 같습니다.

물론 당신의 홉과 어떤 차를 운전하지만, 더 안전하고 편안하게, 그리고 당신의 좌석, 스티어링 휠 및 거울 조정 시간이 걸릴 경우이 멈추는 경우가 적고 될 것입니다 수 있습니다 당신의 선호.

코드를 사용하면 코드를 읽고 이해하는 데 편의가 형식화됩니다. 그것이 당신이 익숙한 것과 너무 멀면 더 많은 정신적 노력이 필요할 것입니다. 개발자에게 이것을 적용해야합니까?

지금까지 언급 한 모든 혜택에 +1하지만 ...

자동 시행에는 다음과 같은 비용이 고려됩니다.

코드 포맷터가 코드 포맷의 미학을 이해하지 못한다는 사실에 -1. 코드 형식 지정자가 표 형식으로 잘 정렬 된 주석 블록을 몇 번이나 삭제 했습니까? 얼마나 많은 시간을 당신이 의도적으로 복잡한 표현을 가독성을 높이기 위해 특정한 방식으로 정렬 않았습니다 만 자동 서식 "는 규칙을 따른다"하지만 멀리 뭔가를 탈수가하는 덜 읽을 수?

때로는 이러한 것들에 대한 해결 방법이 있지만 개발자는 자동 포맷터가 코드를 조작하지 못하게하는 방법보다 더 중요하게 생각해야합니다.

서식 규칙이 있지만 상식을 자유롭게 적용 할 수 있습니다.

좋은 개발자는 창조적 인 사람이며 예술적인 라이센스를 부여합니다. "간단하게 유지"는 프로그래머의 진언이어야합니다. 두 가지 규칙이 있습니다.

규칙 1 : 변수 / 커서 / 개체 / 프로 시저 / 모든 이름 코드에 의미와 이해를 제공하는 명확한 이름.

규칙 2 : 들여 쓰기를 사용하여 코드 구조를 표시하십시오.

그게 다야.

나에게있어 자동으로 적용되는 공통 형식의 주요 장점은 변경 추적 및 코드 검토에 도움이된다는 것입니다. git (및 대부분의 다른 소스 제어 도구)은 이전 버전의 파일의 차이점을 보여줄 수 있습니다. 일반적인 스타일을 적용함으로써 프로그래머 선호도 차이를 최소화합니다.

스타일 가이드를 사용하면 다양한 분석 목적으로 프로그래밍 방식으로 코드를 쉽게 파싱 할 수 있습니다.

Google은 "빌드 부채 검색 : Google의 기술 부채 관리 경험" 이라는 논문을 발표했습니다 .

코드가 아닌 언어입니다. 우리 인간은 6000 개 이상의 언어를 가지고 있으므로 번역합니다. 따라서 "코드"가 통신되도록하려면 조정해야합니다. 데이터를 잃지 않도록 사용자가 데이터 형식을 변경해야한다는 것을 알 수 있습니다.

나는 그렇지 않다고 말할 것입니다. 팀 간의 공통 코드 구조 / 형식은 가장 좋은 방법이지만 자동으로 적용하는 것은 아닙니다. 이것은 컴퓨터가 아니라 사람이해야합니다.

이 개념의 가장 큰 문제는

1. 한 형식으로 코드를 작성하고 자동으로 다시 포맷하면 실제로 해당 형식을 배우는 인센티브는 무엇입니까?
2. 이전 포인트 이후에, 형식을 배우지 않으면 코드를보다 쉽게 ​​읽고 수정하기 위해 자동 서식의 전체 포인트가 완전히 손실됩니다. 형식을 알지 못했기 때문에 코드를 읽을 때 형식을 파악하는 데 여전히 시간이 걸립니다.
3. 언젠가는 수업을 쓰고, 닫고, 다음날 돌아와서 완전히 다른 것을 보는 개발자로서 끔찍한 경험이라고 생각합니다. 즉, 다른 사람이 코드를 배울 필요 할뿐만 아니라 것을 의미 당신이 코드를 배울 수있다.
4. 또한 지연 코딩을 권장 할 수 있습니다. 개발자가 형식을 배우도록 강요하는 대신 태양 아래 어떤 형식 으로든 작성할 수 있으며 다른 사람이 원하는 방식으로 자동 표시됩니다. 스타일을 배우지 못하고 여전히 올바르게 읽을 수없는 # 2로 돌아갑니다.

이제 모든 작업이 끝난 프로젝트에서 자동 형식을 실행하는 것이 좋은 생각이라고 할 수 있습니다. 나중에 기능을 수정 / 추가 할 때 프로젝트와 동일한 단계에서 모든 개발자가 시작됩니다. 그러나 적극적인 개발 중에는 그것이 매우 좋지 않은 선택이라고 생각합니다.

기본적으로 : 회사의 스타일을 배우도록 직원에게 책임을 부여하십시오.