.NET / C # 프로젝트에 어떤 코딩 표준이 중요하다고 생각하십니까? 이것은 중괄호와 간격 및 페던 트리를 다루는 것에서 발생할 수 있습니다. 또는 .NET Framework에서 피해야 할 네임 스페이스, 구성 파일의 모범 사례 등과 같은보다 근본적인 질문 일 수 있습니다.
단순히 다른 사람의 추론 인 게시물을 작성하지 않도록하십시오. 예를 들어, 중괄호에 중점을 둔 게시물 하나를 갖는 것이 좋습니다. 하나의 스타일과 다른 스타일을 지원하기 위해 두 가지가 필요하지 않습니다. 아이디어는 애완 동물 표준에 투표하는 것이 아니라 표준을 만들 때 고려해야 할 사항을 구체화하는 것입니다.
답변:
다음은 .NET Framework 버전 4.0의 코딩 표준에 대한 공식 Microsoft 가이드입니다.
1.1 이전 버전을 사용하려면 여기를 시도 하십시오 .
나는 그들이 말하는 것처럼 반드시 이것을 'T'에 따를 필요는 없습니다. 그러나 의심스러운 경우 현재 .NET 프레임 워크와 일관성을 유지하기에 가장 적합한 곳으로, 특정 프로젝트를 처음 시작했는지 여부에 관계없이 모든 사람이 쉽게 사용할 수 있습니다.
Microsoft의 지침 :
우리는 이것을 사무실에서 채택했습니다. Lance Hunt가 작성했으며 상당히 포괄적입니다.
http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx
다양한 출처에서 일반적인 스타일 세트를 선택하려고합니다. 전에 언급되지 않은 일부 :
SSW (호주 컨설팅 회사)가 제공 한 표준을 권장해야합니다.
코딩뿐만 아니라 프로젝트 관리 등… 엄청나게 귀중한 자료입니다.
나는 다음 응용 프로그램을 사용하여 카멜 백 규칙, 메소드 이름 등의 코딩 표준을 유지합니다.
GhostDoc- 각 방법의 상단에 자동 생성 주석을 추가합니다. 응용 프로그램은 방법의 좋은 초기 요약을 제공합니다. (비어 있는)
http://submain.com/products/ghostdoc.aspx
Resharper- 코드 분석 및 리팩토링 http://www.jetbrains.com/resharper/
StyleCop -TFS에 체크인하기 전에 최종 정리합니다. (비어 있는)
나는 확립 된 코딩 표준을 싫어합니다. 모두 약간 실수를하지 말라고 말하거나 코드를 어떻게 든 다른 형식으로 포맷하는 방법에 대해 걱정하고 있습니다. 모두 사소한 것입니다.
내 말은, 그들이 사업자 사이에 넣어 얼마나 많은 공간이 당신을 말할 것이다, 조언을 충돌하여 변수 (회원에 대한 예 _) 사용에 무슨 헝가리어 스타일 '접두사를 구분하는 방법 (예를 들어, 당신은 클래스 Cxyz를 호출 할 수 없습니다하지만 당신은 해야합니다 인터페이스 Ixyz 호출), 코드 레이아웃 방법 (변수를 클래스 상단 또는 하단에 배치)
큰 그림에서는 모두 쓸모가 없습니다.
효과적이고 유지 보수 가능하며 읽을 수있는 코드를 작성하는 데 중요한 사항은이 표준에서 언급되지 않았습니다.
예를 들어 : 변수를 클래스의 맨 위 또는 맨 아래에 놓습니까? 글쎄, 누가 신경 써야-중요한 것은 기능 영역별로 변수를 그룹화하면 중요합니다. 중요합니다 (장소에 흩어져있는 20 개의 변수를 본 적이 있다면 이것을 알게 될 것입니다).
그들은 중괄호를 특정 장소에 두라고 말합니다. 큰 거래! K & R 및 ANSI 스타일 브라케팅 모두에서 코드를 읽을 수 있지만 중요하지 않습니다. 중요한 것은 모든 Window 클래스가 어떻게 든 양식이나 Dlg 등의 접미사와 같이 차별화되어 어떤 파일이 윈도우 코드를 포함하고 어떤 객체가 일반 객체인지 확인할 수 있습니다.
이와 같은 것은 표준에 일반적으로 포함되는 사소한 점보다 훨씬 중요합니다. 왜 이런 식으로 개발되었는지는 모르지만 종종 효과적이고 생산적인 코딩을 방해하는 수많은 규칙 일뿐입니다.
내 표준은 코드 및 파일 구성에 더 중점을 둡니다. 파일을 찾을 수있는 곳을 나타내는 특정 표준이 있습니다. 예를 들어, 개발자가 아닌 사람은 프로젝트 중 하나를보고 필요한 문서 파일을 즉시 선택할 수 있습니다. 마찬가지로, 우리는 프로젝트 코드를 다른 프로젝트와 비슷한 방식으로 실용적으로 (노트가 적절하지 않을 수 있지만 많이 규정되지 않은 방식으로) 레이아웃하려고 시도하고 기본적으로 표준 지침을 작성하려고합니다. 필요에 따라 수정할 수 있습니다.
한마디로 - 그들은 도움말을 우리가 항상 제한 규칙의 집합으로, 서로가 작동있어 이 준수해야 할.
경고 : 아래의 실용주의 – 문제는 "적절한"중괄호 스타일 등에 대한 토론을 이끌어내는 것으로 보입니다. 나는 그 말도 안되는 시간을 낭비하지 않습니다.
ReSharper를 설치 하고 기본값을 그대로두고 그대로 사용하십시오.
이익-팀의 모든 직원은 Microsoft 지침과 거의 같은 스타일을 가지게되며, Resharper 표준이 실제로 업계에서 더 널리 사용되는 것을 반영하고 (논쟁 적으로) 개선되는 몇 가지 점만 벗어납니다.
팀이 엄청난 문서 나 책을 작성하고 참조하는 데 소요되는 시간이 적거나 curly braces다른 정신에 대해 더 많은 시간을 소비 할수록 더 많은 코딩 작업을 수행 할 수 있습니다. ReSharper는 입력시 이름과 스타일을 적용합니다. 끝난. 토론 끝. 논쟁의 여지가 없습니다. 계속합니다.
즉, 고전적인 Code Complete를 읽으면 코딩 표준에 대한 이론적 근거를 이해하는 데 도움이되고 표준 문서 나 검사 프로그램으로는 할 수없는 코드를 통해 효과적으로 의미를 전달하는 데 도움이되는 많은 포인터를 제공 할 수 있습니다.
당신은 스텝 업 ReSharper에서 당신을 위해 무엇을 할 수 있는지를 원하는 경우, 추가 StyleCop을 StyleCop ReSharper에서에 대한 플러그인으로. 언급 한 바와 같이 MS 지침과 ReSharper 기본값 사이에는 약간의 충돌이 있습니다. 나는 그저 ReSharper와 함께 갈 것입니다. 그러나 어느 쪽이든 결과를 ReSharper 구성 파일에 저장하고 팀 전체에서 공유하고 완료하십시오.
(아니요, 저는 행복한 고객 인 ReSharper의 유료 실책이 아닙니다. 다른 많은 기능 외에도 표준 문서 나 코드 검토 시스템보다 기본 스타일 문제를 더 비용 효율적으로 처리 하여 중요한 사안에 대한 두뇌 힘을 남깁니다. .)