귀사에는 코딩 표준이 있습니까? [닫은]

최근에 Microsoft가 코딩 표준 문서 ( All-In-One Code Framework Coding Standards )를 발표 한 것을 보았습니다. 제가 일하는 회사에는 공식적인 코딩 표준이 전혀 없습니다. 개발자는 거의 없으며 비슷한 스타일로 발전 할 수있을만큼 오랫동안 함께 해왔으며 결코 문제가되지 않았습니다.

근무하는 회사에 문서화 된 코딩 표준이 있습니까? 아니라면 왜 안됩니까? 표준을 적용하면 차이가 있습니까? 처음부터 표준을 작성하는 것이 가치가 있습니까, 아니면 다른 표준을 자신의 표준으로 채택해야합니까 (즉, Microsoft 표준을 귀하의 표준으로 설정)?

팀이 몇 가지 문제를 피하기 위해 각 언어에 대해 단일 코딩 표준을 갖는 것이 중요합니다.

• 표준이 없으면 코드를 읽을 수 없게됩니다.
• 표준에 대한 의견 불일치로 인해 개발자간에 체크인 전쟁이 발생할 수 있습니다.
• 같은 클래스에서 다른 표준을 보는 것은 극도로 자극적 일 수 있습니다.

나는 밥 아저씨가 표준에 대해 말한 것에 대한 열렬한 팬입니다 .

1. 처음 몇 번의 반복 동안 진화하게하십시오.
2. 회사 별이 아닌 팀별로 지정하십시오.
3. 피할 수 있으면 적어 두지 마십시오. 오히려 표준이 포착되는 방식으로 코드를 작성하십시오.
4. 좋은 디자인을 제정하지 마십시오. (예 : 사람들에게 goto를 사용하지 말라고 말하지 마십시오)
5. 모든 사람이 표준이 의사 소통에 관한 것임을 알도록하십시오.
6. 처음 몇 번의 반복 후에 팀이 함께 결정하도록하십시오.

"우리는 3 칸 들여 쓰기를 사용하고 대괄호를 다음 줄에 사용한다"고 말하더라도 코딩 표준을 갖추는 것이 필수적이라고 생각합니다. 몇 가지 장점 :

• 파일 간 코딩 스타일 간 전환이 성가 시므로 전체 코드베이스를 훨씬 쉽게 읽을 수 있습니다.
• 충돌하는 스타일을 가진 두 개발자가 업데이트 한 파일은 결국 해당 스타일을 혼합하는 경향이 있기 때문에 단일 파일을보다 쉽게 ​​읽을 수 있습니다. 탭과 공백이 혼합 된 파일을 읽고 나중에 편집하는 것은 어려운 일입니다.
• 암묵적인 표준이 아닌 명시적인 표준이있는 경우 새로운 개발자가 좋은 스타일을 쉽게 사용할 수 있습니다.
• 일관된 명명 규칙을 사용하면 함수 / 변수를 훨씬 쉽게 찾을 수 있습니다. ArraySort 또는 array_Sort 또는 sortTheArray 또는 doSortArray 또는 ...입니까?

기존 표준의 채택 여부와 관련하여 실제로 중요하지는 않습니다. 일관성은 중요합니다. 개발자가 12 가지 다른 스타일을 사용하는 경우 기존의 게시 된 스타일을 선택할 수도 있습니다. 모두 꽤 일관된 스타일로 발전했다면 그 스타일을 적어 사용하십시오.

"우리는 X 상점입니다"라는 의견에 동의하지 않으므로 모든 언어로 동일한 방식으로 코드를 형식화합니다.

개인적으로 나는 대부분의 언어가 다른 허용 스타일을 가지고 있음을 발견했습니다.

C 프로그래머가 C 형식으로 Java 코드를 작성할 때 정말 견딜 수 없습니다. Java처럼 보이지 않을뿐만 아니라 Java에서 다른 C와 유사한 관행을 사용할 수 있다고 생각하는 사람들을 속입니다.

나는 당신이 표준을 가지고 있다면 언어마다 있어야한다고 생각합니다.

저의 전 고용주는 코딩 표준을 가지고 있습니다. 공식적으로 문서화하는 것도 고려하고 있습니다.

또는 당신이 제안한대로, 괜찮은 기존 표준을 찾고 그것을 수정 / 채택하십시오. 회사의 경우 기존 코딩 표준을 살펴보고 자신의 특정 요구에 맞는 표준을 작성 / 수정하는 것이 좋습니다. 처음부터 새로 만들어야 할 필요는 없지만 코딩 표준이 회사가 만드는 소프트웨어 유형에 적합하도록주의를 기울여야합니다.

그렇습니다. 코딩 표준을 적용하면 차이가 발생하지만 은총 알이 아닙니다. 서로 다른 스타일 충돌이 많지 않고 일반적인 실수 / 함정을 피할 수 있으므로 코드가 더 읽기 쉽습니다. 표준을 사용하더라도 코딩 스타일에는 약간의 차이가 있지만 그 변동성은 줄어 듭니다. 목표는 모든 변형을 피하거나 가능한 모든 상황에 대비하는 것이 아닙니다. 코딩 표준이 너무 복잡하면 어느 것보다 나빠질 수 있습니다.

불행히도. 따라서 모든 사람은 간격, 들여 쓰기 등을 사용하는 모든 방법을 혼합하여 사용할 수 있습니다 (이 방법으로 우리는 "비난"기능을 사용하여 누가 코드 라인의 작성자인지 알 필요조차 없습니다!)

그러나 최악의 경우, 누군가는 이탈리아어로 변수 및 클래스 이름을 작성하고 다른 사람은 영어로 작성합니다 ...

나는 항상 소스 코드가 균일하고 평범하게 보이도록 사용중인 언어, 라이브러리 및 프레임 워크의 스타일에 맞게 스타일을 조정합니다.

이 문서는 복합기 코드 프레임 워크에 특정한 코딩 표준 문서입니다 .

나는 여러 회사에서 근무했으며, 그 중 일부는 기존 표준을 가지고 있었고 일부는 표준 개발에 도움이되었습니다. 대부분의 경우 .NET 기반 개발을 수행하고 있고 (그렇지 않은 경우에도 대부분의 규칙이 여전히 적용되는 경우) 프레임 워크 디자인 지침을 살펴보십시오 . 이것은 공개 API를 작성하기위한 것이지만 대부분의 지침은 모든 코드에 동일하게 적용됩니다.

코드 표준에 대한 가장 큰 관심사는 비교적 간단하고 간단하게 유지하는 것입니다. 개발자가 제시된 지침을 내부화 할 수 있기를 원하므로 50 페이지 이상의 문서를 제공하는 것은 쓸모가 없습니다. 배경, 예제 등을 제공하려는 경우에도 해당 문서를 작성할 수 있지만 일련의 글 머리 기호 지침으로 요약되는 것을 원할 것입니다. 코딩 표준은 또한 기술이 변화함에 따라 변화해야하는 유연하고 살아있는 문서 여야합니다.

코딩 표준 토론은 다음과 같습니다.

• 그렇습니다. 일관성과 깨끗한 코드는 좋은 개발의 초석입니다.
• 그들이이 거의 것은 너무 오래 모두가 같은 기준을 다음과 같이 중요하지 않습니다.
• 자신의 글을 쓰지 마십시오. 끝없는 고통스러운 토론으로 끝납니다. 인기있는 것들이 많이 있습니다.
• MSDN의 표준과 같은 공개 표준을 사용하면 논쟁의 여지가없는 불가지론적인 타사가 제공됩니다. 그들과 논쟁하고 싶다면 포인트 2를 참조하십시오.

Visual Studio에서 C #으로 개발하는 경우 StyleCop 은 은색 총알입니다. ReSharper를 사용하는 경우 ReSharper 용 StyleCop 플러그인은 훌륭합니다.

우리는 blub shop이므로 blub 프로그래밍 규칙을 사용합니다.

이제 Paul Graham과 친구는 우리보다 훨씬 똑똑하지만, 우리는 blub 프로그래머입니다. 우리는 모두 서로의 blub을 읽을 수 있습니다. 실제로 모든 blub 프로그래머는 우리의 blub 코드를 읽을 수 있습니다.

실제로 blub의 설계로 인해 blub 프로그래머는 단일 blub 파일을 읽고 이해할 수 있습니다. blub에는 매크로 시스템이 없기 때문입니다.

우리가 C 또는 C ++로 프로그래밍한다면 (우리는 blub로 프로그래밍하더라도 다국어입니다) 우리는 새로운 코드 또는 우리가 작업중 인 프로젝트의 표준 인 오픈 소스 자료에 주로 blub 스타일을 사용합니다.

하나의 표준이 필요합니다. 나는 "그들의 방식대로"하고 싶었던 다른 리드를 가진 애플리케이션의 다른 구석에서 다른 표준을 보았다. 아마도 "표준"이라는 개념이 잘못 이해되었을 것입니다. 매우 미쳤다. 그리고 최악의 표준은 한 사람에 의해 생성됩니다. 그 사람이 누구인지는 중요하지 않습니다. 한 사람이 혼자서 표준을 개발한다면 그것은 나쁜 사람이라는 것이 거의 확실합니다.

사람들에게 도움이 될 수 있으며 도구와 관련하여 실제로 도움이 될 수 있습니다.

모든 종류의 자동 코드 형식을 사용하려면 실제로 사용할 규칙을 표준화해야합니다. 그렇지 않으면 의미없는 형식 변경이 계속해서 차이가 생길 수 있습니다.

정적 분석 도구의 기본 규칙 세트는 특정 이름 지정 스타일을 확인하는 것이 좋으며 모든 규칙을 준수하기가 더 쉬울 것입니다. (규칙을 완전히 해제하지 않는 한)

마지막으로 팀 외부의 누군가와 상담해야 할 모든 것을 표준화하는 것이 좋습니다. 즉, 회사 법률 팀을 통해 작성한 새 파일을 모두 실행하지 않으려는 경우 헤더에 표준 저작권 표시를 원할 것입니다. 공개 API의 이름을 처음으로 얻고 싶습니다.