모든 코딩 규칙은 어떻습니까?

회사 나 특정 프로젝트의 개발자를 위해 코딩 규칙을 사용한다는 아이디어를 항상지지했습니다. 특히 회사의 규모가 10보다 큰 경우 회사가 클수록 필요가 커집니다. 많은 사람들이 동의하지 않을 것을 알고 있지만 프로젝트가없는 프로젝트를 보았고 코드는 완전히 재난처럼 보입니다.

이로 인한 실제 문제는 if 문에서 대괄호를 사용하지 않거나 코드의 모든 곳에서 동일한 연결 문자열을 사용하거나 코드 규칙을 반대하지 않고 코딩 규칙을 사용하지 않는 하드 헤드를 만드는 방법입니다. 아이디어?

싸우는 규칙보다는 문제를 해결하는 데 참여하게하십시오. 나는 개인적으로 "스타일 가이드", "코딩 표준"또는 이와 유사한 아이디어를 선호한다. 이는 무릎 경련의 "규칙 = 나쁜"반응을 막기 위함이다.

그러나 그것이 가능하더라도-규칙이 이유가 있다고 생각하는 경향이 있으며, 어려운 사람들을 돌이킬 수있는 방법은 지침을 따르면 코드를 쉽게 만들 수 있도록 돕는 것입니다. 모두를 위해 읽으십시오.

때로는 동료 압력이 가장 좋은 해결책입니다.

우리는 다음 세 가지 솔루션을 모두 사용합니다.

1) 우수한 Checkstyle (Java의 경우) 또는 StyleCop (C #의 경우) 과 같은 코드 스타일 검사기를 채택하십시오 . 이들은 코딩 스타일 / 규칙 편차를 자동으로 강조 할 수있는 쉽게 구성된 도구입니다. 모든 사람에게 중립적 인 제 3자를 제공하여 무엇이 허용되고 허용되지 않는지를 결정합니다.

2) 자동 저장 형식 변경 코드 템플릿 (여기에는 Eclipse를 사용하는 예) (및 Visual Studio 용 예제 )을 채택하여 저장시 자동으로 코드 형식을 지정합니다. 이는 원하는 방식으로 코딩 할 수 있지만 저장 / 커밋시 모든 코드의 형식은 동일합니다. 나는 이것을 정말로 좋아하고 우리 코드는 더 일관성이 없었습니다.

3) 코드 검토. 어쨌든 이러한 작업을 수행하고 있지만 코딩 규칙 / 스타일이 규칙을 어 기고있는 부분이 강조되어야합니다.

위의 사항 외에도 모든 사람이 같은 보트에 있고 그들이 작업하는 스타일 / 규칙에 동의하는 것이 중요합니다. 모든 것에 대해 모든 사람의 동의를 얻지 말고 팀의 결정에 충실하도록 팀의 약속을 요청하십시오. 실제 사용 경험과 팀 회전율을 고려하여 선택한 스타일 / 규칙을 때때로 검토하십시오.

이로 인한 실제 문제는 if 문에서 대괄호를 사용하지 않거나 코드의 모든 곳에서 동일한 연결 문자열을 사용하는 것을 좋아하지 않는 하드 헤드를 만드는 방법입니다.

대괄호를 사용하지 않고 "하드 헤드"입니까? 아니면 "하드 헤드"요청입니까?

전투를 선택하십시오. 나는 이것이 고를 가치가있는 것 중 하나라고 의심합니다. "코드의 첫 번째 체크인"에 대해이 수준의 세부 사항 근처에서 예상되는 작업은 즐겁지 않습니다 . 이것은 팀이 리팩토링을 이해하지 못한다는 빨간색 플래그 표시기입니다.

OO 101 : "제품이해야 할 일을 할 때 리팩터링". 전에는 아니었다.

대규모 팀에서 모든 단일 개발자의 어깨에 앉는 것은 매우 어렵습니다. 그들이 당신 이 가야한다고 생각하는 곳에 중괄호를 두십시오 .

실제로 느끼는 것이 개발을 방해하고 있다면 "게이트 키퍼"가 필요할 것입니다. 예를 들어 사람들이 코드 검토없이 체크인하지 못하게하십시오. 기술 설계자 또는 팀 리더에게 코드를 검토하고 코드 스타일이 "수정"될 때까지 거부하도록하십시오. 그들은 곧 이것에 질려서 규칙에 적응할 것입니다.

물론 일부 회사는 주니어 프로그래머로부터 체크인 권한을 완전히 빼앗습니다. 회사가 규칙을 코딩하는 회사를 마침내 알게되면 특권을 얻게됩니다.

나는 당신이 매우 다른 수준의 문제에 대해 이야기하고 있다고 생각합니다.

if 문에서 대괄호를 사용하지 않는 어려운 사람들을 만드는 방법,

명백한 연산자 우선 순위 문제가 없다면, 이는 대부분 스타일 / 가독성 문제입니다. 후자는 매우 일반적이어서는 안되며, 어쨌든 단위 테스트가 가능하므로 쉽게 고칠 수 있습니다. 전자는 거의 얻지 못하지만 팀 사기에 심각한 부정적인 결과를 초래하면서 성전으로 쉽게 복귀 할 수 있습니다. 따라서 최소한 일부 팀 / 커뮤니티가 승인하고 작동하는 것으로 입증 된 규칙 만 푸시 하십시오 .

코드의 어느 곳에서나 동일한 연결 문자열을 사용하거나

Magic Constants를 의미한다면, 그것은 실제로 유지 관리 (및 잠재적으로 보안) 문제이며, IMHO와 마찬가지로 노련한 개발자는 그것이 나쁜 것임을 이해하고 받아 들일 것입니다.

또는 아이디어를 반대하지 않고 코딩 규칙을 사용하려면?

사람들이 어떤 코딩 규칙에 동의하도록 강요 할 수는 없습니다. 유일한 기회는 토론 및 (때로는 치열한) 토론을 통해 팀 구성원들로부터 공통적 인 이해와 구매 를 얻는 것 입니다. 논리적이고 설득력있는 논증 을 사용해야하며 , 각 규칙의 가치를 보여주고, 뿌리 깊은 습관을 조정하는 불편 함을 어떻게 따를 것인지 설명해야합니다. 반면 에, 수락 된 규칙에 따라 체크인시 자동 코드 형식을 도입하여 가능한 한 쉽게 전환 할 수 있도록 노력 하십시오.

그러나 때때로 사람들은 의견이 다르다는 사실을 받아 들여야합니다 . 따라서 모든 사람이 받아 들일 수있는 코딩 규칙은 특정 측면에서 관대합니다. 이를 받아들이고 적은 노력으로 일을 개선 할 수있는 영역에 집중하십시오.

규칙 설정에 참여하도록하십시오. 이것은 보통 사람들이 그들을 따르도록 격려하는 데 도움이됩니다.

이것이 코드 검토를위한 것입니다. 코드 검토자는 표준을 충족하지 않는 코드를 통과시키지 않아야합니다. 긴급한 수정에 대한 규칙을 완화하지 마십시오. 그것을하기 위해 몇 번의 압박을 받고 다시해야한다면 처음으로 자신의 일을하기를 꺼려하는 사람들이 고쳐질 것입니다.

어디에서나 동일한 연결 문자열? 이에 대한 해결책은 모든 중복을 제거 할 때까지 리팩토링하는 것입니다. 복사-붙여 넣기 코더는 프로그래머 감옥에 가야합니다. (웃지 마! 스티브 발머는 소장이다.)

그러나 여기서 진짜 문제는 당신의 동사 "make" 입니다. 프로그래머가 아무 것도하지 못하게 할 수 있으며, 그렇게하면 가장 소중한 특성, 즉 관심있는 무언가에 대한 작업에서 오는 깊은 지적 참여를 낭비하게됩니다.

내가 해결하는 방법 :

1. 팀은 공통의 코딩 표준을 가지고 있다고 주장하십시오. 길이는 5 줄이 될 수 있지만 모두 동의해야합니다.
2. 당신이 주장하는 주장을 발견 할 때마다 그것들은 그것을 정리하고 코딩 표준에 넣습니다. 사람들이 물건을 앞뒤로 재 포맷하는 것을 보게되면, 그것을 논증으로 취급하십시오.
3. 표준 항목에 동의 할 때마다 전체 코드베이스를 한 번에 정리할 수있는 도구가 있는지 확인하십시오.
4. 두 달마다 코딩 표준을 살펴보고 어떤 것이 여전히 진실되고 관련성이 있는지 확인하십시오. 표준은 사람들이하는 일을 문서화합니다. 그리고 표준으로 품목을 명확하게 유지하는 데 아무런 의미가 없습니다.

프로그래밍은 팀 스포츠 또는 집단 예술 작품입니다. 사람들이 동의하는 것은 그들이 동의하는 것만 큼 중요하지 않으며, 필요에 따라 새로운 계약을 잘 수행합니다.