코딩 표준에 너무 많은 균일 성이있을 수 있습니까?

12

균일 성이 너무 높습니까? 물론 우리는 명명 규칙, 아키텍처, 활용할 프레임 워크 등의 표준을 가지고 있습니다. 그러나 최근에 더 많은 스타일을 고려할만한 비판이 많이있었습니다.

예를 들어 ifc # ??null-coalescing 연산자 대신 == null들여 쓰기 간격 등을 사용하여 여러 줄 대 한 줄로 명령문을 작성 하는 경우

나에게 이것은 개인 스타일 선택에 더 들어가기 시작하고 팀이나 회사 전체에서 균일 할 필요가 없습니다. 한 사람이 생각하는 것은 다른 사람이 더 명확하게 읽을 수 있습니다. 이 "추가"균일성에 어떤 가치가 있습니까?

programming-practices team coding-standards

— Gratzy
소스

2

안녕하세요 Gratzy, Programmers.SE는 토론 게시판 이 아닙니다 . 우리는 당신이 직면하고있는 실제 문제를 해결하기 위해 왔습니다. 해결하려는 실제 문제가 있습니까? 그렇다면, 당신이 답을 건설적이고 토론의 함정에서 벗어나지 않게하기 위해 질문에 답할 수 있습니까?

1

@ 개인적으로 직면 한 상황을 감안할 때 @Gratzy는 다른 방법으로 답하면 정답의 기준은 무엇입니까?

2

@Mark Trapp FAQ에 따르면 이것은 질문의 기준입니다. 모든 주관적인 질문은 건설적인 것으로 예상됩니다. 우리는 그것을 어떻게 정의합니까? 건설적인 주관적인 질문… 1.“왜”와“어떻게”를 설명하는 답변에 영감을줍니다. 2. 짧고 짧은 답변이있는 경향이 있습니다. 3. 건설적이고 공정하며 공정한 어조를 갖습니다. 4. 의견에 대한 경험 공유. 5. 의견은 사실과 참고 문헌으로 뒷받침되어야한다고 주장한다. 6. 단순한 정신 재미 이상의 것입니다. 나는 내 질문이 최소한 처음 4 개를 다룬다 고 믿는다

— Gratzy

2

@Gratzy는 또한 FAQ에서 : "실제로 직면하고있는 실제 문제에 기초하여 실용적이고 응답 가능한 질문 만해야합니다. 채팅, 개방형 질문은 사이트의 유용성을 떨어 뜨리고 다른 질문은 첫 페이지로 넘깁니다."

2

@Mark Trapp 나는 이미 수용 가능한 대답에 대한 기준을 언급했으며, 이것이 실제 문제이며 솔직히 질문에 대한 관심과 다른 사람들의 의견에 대한 솔직한 답변이라고 대답했습니다.

— Gratzy

16

균일 성은 문제 (좋은)는 아니지만 강성 또는 유연성 이 없을 수 있습니다. 균일 성을 위해 노력할 때 독단적이되면 팀에 해를 끼치는 피해는 (균등 한) 균일 성에서 비롯된 이익보다 클 수 있습니다.

가장 중요한 것 (네이밍 및 대문자 표기 표준, 들여 쓰기, 줄 바꿈 및 대괄호 배치 등)에 대한 기본 스타일을 설정하고 덜 중요한 것에 대한 권장 사항을 설정하는 것이 가장 좋습니다 (문구 형식, 괄호 주변의 기타 공백 등). 나머지는 걱정하지 않아도됩니다.

— 니콜
소스

1

나는 거기에 있었다

+1, 내가 의미하는 바를 말했지만 더 좋습니다!

— FrustratedWithFormsDesigner

@ 피에르는 왜 지금 프리랜서입니까? :)

— Nicole

실제로는 아니지만 가이드 라인에 대해 소위 집착 한 사람들을 만났습니다. 그것이 극단적 일 수있는 방법은 무섭습니다. 나는 당신이 한계를 꽤 잘 정의했다고 생각합니다.

7

수십 명이 수십 년 동안 프로젝트를 진행할 때 스타일을 뛰어 넘어야 할 때 때때로 혼란스러워집니다. 글쓰기 스타일을 어느 정도 유지 하는 다른 저자들이 다른 장을 쓴 책을 읽는다고 상상해보십시오 . 가능하지만 성가시다.

요즘 대부분의 IDE는 스타일을 적용 할 수 있으므로 필요한 경우 선택한 코딩 스타일을 지정하는 IDE 환경 설정 파일 (프로젝트 소스 코드의 일부로)을 배포하고 모든 사람이이를 설치하여 작성중인 코드의 형식을 지정하는 데 사용할 수있는 IDE 환경 설정 파일을 배포 할 수 있습니다 . 체크인시 코드를 다시 포맷하거나 스타일을 지정할 수있는 방법이 있습니다 (아직 조사하지 않아도 됨).

— 좌절 된 폼 디자이너
소스

네, 아마도 어딘가에 개미를 넣을 수있을 겁니다

— Michael K

1

최소한 IntelliJ에는 체크인 전에 코드를 다시 포맷하는 옵션이 있습니다.

— Nicole

3

내가 본 초과 균일 성 사례 중 하나는 적절성에 관계없이 모든 프로그래밍 언어에 적용되는 단일 표준을 사용하는 것입니다.

낙담 goto하지 않고 C와 같은 언어로도 try... catch.
사용 InitialCaps표준 라이브러리는 자바 스크립트 (마이크로 소프트의 MFC와 C #에서와 같이) 이름을 initialLowerCase.

— dan04
소스

2

균일 성이 너무 높다고 생각하지 않습니다. 그러나 나는 종종 코딩 표준에서 너무 많은 사양을 발견합니다. 오프닝 브레이스를 별도의 줄에 배치하는 모든 사람의 이점은 기껏해야 모호하며 논쟁하거나 코드의 미용 문제를 해결하는 데 소비하는 시간보다 중요하지 않습니다.

— JohnFx
소스

2

@Tungano 나는 더 이상 동의 할 수 없었다. 코딩 표준의 역설은 가치가 있지만 논쟁의 가치가 없다는 것입니다.

— Charles E. Grant

3

프로그래머의 목을 특정 스타일로 강요하는 것이 그러한 주장을 피하는 데 어떻게 도움이되는지 모르겠습니다. 사실, 나는 프로그래머가 그러한 주장을 좋아하지 않는 스타일에 적응 시키거나 최소한 분개하는 것을 주장한다.

— JohnFx

1

@JohnFx는 대부분의 프로그래머가 스타일의 일관성이 특정 스타일의 선택보다 코드 품질과 유지 관리에 크게 기여한다는 것을 인식 할 것이기 때문입니다. 내 경험상 팀의 코 수를 빠르게 계산하고 사람들이 좋아하는 것과 싫어하는 것을보고 신속하게 합의에 도달 할 수 있습니다. 때때로 누군가가 독특한 버가 부를 가지고 당신이 그것들을 수용하면, 그들은 다른 누군가의 버가 부를 만들어냅니다. 낙타 사건이 사악한 이유에 대해 5 분 동안 팀을 꾸리 게된다면, 나는 그것을 포기하고 내 개인적인 유연성을 시험하는 것입니다.

— Charles E. Grant

1

나는 대부분의 프로그래머가 스타일의 일관성이 큰 기여를한다고 생각하지만 실제로는 그렇지 않다고 생각한다. 그것은 당신의 애완 동물 스타일에 맞지 않는 코드를 보는 것을 귀찮게하는 것처럼 보이며 사소한 미용 문제에 대해 "정리"하는 코드 블록을 통과하는 것이 미루는 좋은 방법입니다. 내가 금도금에 초점을 맞추고 배달 물이 아니라는 것을 깨달을 때까지 나는 그 악 대차에 있었었다.

— JohnFx

1

저는 독일 팀의 코드, 몇 가지 OSS 프로젝트 및 현재 가지고있는 일부 고대 코드와 함께 작업합니다. 일부는 C, 일부 C ++, 일부 C #입니다. 그래서 항상 여러 가지 다른 코드 스타일로 작업해야합니다. 그렇게하면 표준에 따라 의무화 된 스타일 가이드 라인이 얼마나 사소한 지 알게됩니다. 한 프로젝트에서 다른 프로젝트로 전환 할 수 있으면 다른 사람이 {}을 (를) 다른 곳에 배치 할 수 있습니다. 이것이 내가 가치있는 유일한 표준은 "각 프로젝트 내에서 일관성"이라는 하나의 규칙을 가진 표준이라고 생각하는 이유입니다.

— gbjbaanb

2

균일성에 대한 두 가지 주장이 있습니다.

단체 소유권 증진. 누군가 "아기"가 변경에 의해 다 치지 않을까 염려하지 않고 다른 사람의 코드를 편집 할 수 있습니다. 일종의 "우리 모두 함께이"정신입니다.
쉽게 추가 할 수 있습니다. 다른 곳에서 이미 수행 된 작업이 있으면 가능한 한 재사용 할 수 있습니다. 어떤 규칙은 글을 더 쉽게 읽거나 바꾸는 데 도움이되므로 이것이 내 마음에 또 다른 이점입니다.

— JB 킹
소스