C # 코딩 표준 / 우수 사례 문서를 개발하기위한 제안 사항이 있습니까? [닫은]

나는 적당한 수술을 위해 일하는 최근 AI 졸업생입니다 (2 년경). 기본적으로 (유용한 부분입니까?) C # 코딩 표준 문서를 작성하는 것이 나에게 떨어졌습니다.

필자는 아마도 가장 후배의 소프트웨어 엔지니어 일 것이라고 설명해야한다고 생각하지만 실제로이 절반 정도 사용할 수있는 제품을 생산할 수 있기를 기대하고 있습니다. 인터넷을 광범위하게 검색하고 코딩 표준 문서에 포함하거나 포함하지 않아야 할 내용에 대한 기사를 읽었습니다. 이것은 어떤 제안을 요구하는 곳만큼 좋은 것 같습니다.

나는 '일을하는 가장 좋은 방법'에 대한 전 세계의 의견 불일치에 대한 문을 열었 음을 알고 있습니다. 나는 각 프로그래머가 각 개별 과제를 해결하는 선호하는 방법을 가지고 있다는 부인할 수없는 사실을 이해하고 존중합니다. 결과적으로 개인의 감각을 억압하기 위해 엄청나게 서술적인 것을 쓰지 않고 일반적인 방법론을 시도하고 동의하려고합니다. 개인 코드를 더 읽기 쉽게 만드는 표준 (예 : 명명 규칙).

그래서 여기에 간다 .... 어떤 제안? 전혀 없습니까?

우리는 시작합니다

• Microsoft의 .NET 지침 : http://msdn.microsoft.com/en-us/library/ms229042.aspx(.NET 4.5 용 링크 업데이트)
• 마이크로 소프트의 C #을 지침 : http://blogs.msdn.com/brada/articles/361363.aspx .

그런 다음 해당 기준과의 차이점과 추가 사항을 문서화하십시오.

IDesign 에는 일반적으로 사용되는 C # 코딩 표준 문서가 있습니다. 프레임 워크 디자인 가이드 라인 2nd Ed 도 참조하십시오 .

아이러니하게 실제 표준을 설정하는 것이 쉬운 부분 일 수 있습니다.

저의 첫 제안은 다른 엔지니어들로부터 그들이 다루어야 할 느낌과 그들이 중요하다고 생각하는 지침에 대한 제안을 이끌어내는 것입니다. 모든 종류의 지침을 시행하려면 어느 정도의 사람들의 바이 인이 필요합니다. 코드를 작성하는 방법을 지정하는 문서를 갑자기 내려 놓으면 가장 중학교이든 수석이든 상관없이 저항에 부딪치게됩니다.

제안서가 준비되면 팀으로 보내 피드백과 검토를 받으십시오. 다시 말하지만 사람들이 모두 구매하도록 유도하십시오.

이미 채택 된 비공식적 인 코딩 관행이있을 수 있습니다 (예 : 접두사 멤버 변수, 낙타 함수 이름). 이것이 존재하고 대부분의 코드가 그것을 준수하면 사용을 공식화하는 비용을 지불합니다. 반대 표준을 채택하면 일반적으로 권장되는 경우에도 가치보다 슬픔을 유발할 수 있습니다.

새로운 코딩 표준을 충족시키기 위해 기존 코드를 리팩토링하는 것도 고려할 가치가 있습니다. 시간 낭비처럼 보일 수 있지만 표준에 맞지 않는 코드를 사용하면 다른 스타일의 혼란이 생길 ​​수 있으므로 역효과를 낳을 수 있습니다. 또한 특정 모듈의 코드가 새로운 표준을 준수해야하는지 또는 기존 코드 스타일을 따라야하는지 딜레마에 빠지게합니다.

나는 코딩 표준 / 모범 사례를 내부적으로 수행 할 때 항상 Juval Lowy의 pdf 를 참조로 사용했습니다. 이 표준은 FxCop / Source Analysis 와 매우 유사 하며 표준을 준수하는지 확인하는 또 다른 소중한 도구입니다. 이러한 도구와 참조 간에는 모든 개발자가 따르지 않고 적용 할 수있는 훌륭한 표준을 제시 할 수 있어야합니다.

다른 포스터는 기준선에서 당신을 가리 켰습니다. 추가해야 할 것은 문서를 짧고 달콤하고 요점에 맞추는 것입니다. ".

표준 문서를 코딩하는 데있어서의 문제점은 아무도 자신이 원하는대로 읽지 않으며, 읽을 때 따르지 않는다는 것입니다. 그러한 문서가 읽히고 따를 가능성은 길이에 반비례합니다.

FxCop이 좋은 도구이지만이 중 너무 많으면 프로그래밍에서 모든 재미를 얻을 수 있으므로주의하십시오.

자신 만의 코딩 표준을 작성하지 마십시오. MS 표준 (또는 Sun 표준 또는 언어에 따라)을 사용하십시오. 단서는 표준이라는 단어에 있습니다. 각 조직이 자체적으로 작성하기로 결정하지 않으면 세상은 훨씬 쉽게 코딩 할 수 있습니다. 팀 / 프로젝트 / 역할을 변경할 때마다 새로운 '표준'을 배우는 것은 누구의 시간이든 잘 활용하는 사람입니다. 당신이해야 할 가장 중요한 것은 요점을 요약하는 것입니다. 그러나 중요한 것은 사람마다 다르기 때문에 그렇게하지 않는 것이 좋습니다. 코딩 표준에 대해 말하고 싶은 두 가지 다른 점

1. 닫기는 충분합니다-코드에 따라 코딩 표준을 따르도록 코드를 변경하는 것은 코드가 충분히 가까운 한 시간 낭비입니다.
2. 코드를 변경하는 경우 '로컬 코딩 표준'을 따르지 않고 새 코드를 주변 코드처럼 보이게합니다.

이 두 가지 점은 모두가 똑같이 보이는 코드를 작성하기를 희망하는 현실입니다.

다음 문서가 매우 유용하고 간결하다는 것을 알았습니다. idesign.net 사이트에서 제공되며 Juval Lowy가 작성했습니다.

C # 코딩 표준

주의 : 위의 링크는 이제 죽었습니다. 당신이 (솔직히 ...하지만 그들은 마케팅을 위해 그것을 사용하지 않습니다) 그 (것)들에게 당신의 이메일 주소를 줄 필요가 .zip 파일을 얻으려고 여기

방금 코딩 표준이 멤버 변수에 m_, 매개 변수에 p_, 문자열에 대한 'str'과 같은 유형에 대한 접두어를 사용해야하는 곳에서 시작했습니다. 따라서 메소드 본문에 다음과 같은 내용이있을 수 있습니다.

m_strName = p_strName;

끔찍 해요 정말 끔찍 해요

Code Complete 2 를 목록에 추가 하고 싶습니다 (제프가 여기에 팬이라는 것을 알고 있습니다) ... 주니어 개발자 인 경우이 책은 최고의 기초를 설정하는 방식으로 마음을 정하는 데 편리합니다. 코드 작성 관행과 소프트웨어 구축이 있습니다.

나는 내 경력에 약간 늦었다 고 말해야하지만, 직업 생활에서 코딩 및 프레임 워크 개발에 대해 생각하는 많은 방법을 지배합니다.

체크 아웃 할 가치가 있습니다.)

Microsoft의 자체 규칙은 훌륭한 출발점입니다. FxCop으로 시행 할 수 있습니다.

Microsoft의 StyleCop을 표준으로 적용하고 싶습니다. 빌드시에 시행 할 수 있습니다. 그러나 레거시 코드가 있으면 새 코드에서 StyleCop을 사용하십시오.

http://code.msdn.microsoft.com/sourceanalysis

결국 코드를 ​​정리하는 리 팩터 옵션이 있습니다.

http://blogs.msdn.com/sourceanalysis/

개인적으로 저는 IDesign 이 만든 것을 좋아합니다 . 그러나 그것이 내가 게시하는 이유는 아닙니다 ...

우리 회사의 까다로운 부분은 모든 다른 언어를 고려하고있었습니다. 그리고 나는 내 회사가 이것에 혼자가 아니라는 것을 알고 있습니다. 우리는 C #, C, 어셈블리 (장치를 만든다), SQL, XAML 등을 사용합니다. 표준에는 약간의 유사점이 있지만, 일반적으로 각각 다르게 처리됩니다.

또한 높은 수준의 표준이 최종 제품의 품질에 더 큰 영향을 미친다고 생각합니다. 예 : 댓글 사용 방법 및시기, 예외가 필수 인 경우 (예 : 사용자가 시작한 이벤트), 예외를 사용할지 여부 또는 반환 값, 컨트롤러 코드와 프레젠테이션 코드를 결정하는 객관적인 방법은 무엇입니까? 저를 오해하지 마십시오. 저수준 표준도 필요합니다 (포맷은 가독성에 중요합니다!) 나는 전체 구조에 대한 편견이 있습니다.

명심해야 할 또 다른 부분은 매입 및 집행입니다. 코딩 표준이 훌륭합니다. 그러나 아무도 그들에게 동의하지 않고 (아마도 더 중요하게) 아무도 그들을 강요하지 않는다면 그것은 모두 버릇없는 일입니다.

필립스 메디컬 시스템즈 (Philips Medical Systems)와 http://csharpguidelines.codeplex.com 에 실린 문서를 모두 썼을 때 약간 편견이있을 수 있지만 10 년 이상 코딩 표준의 작성, 유지 및 홍보에 대한 경험이 있습니다. 나는 의견의 차이를 염두에두고 하나의 CodePlex를 작성하려고 시도했으며 특정 조직에서이를 처리하는 방법에 대한 소개의 대부분을 보냈습니다. 그것을 읽고 피드백을 제공하십시오 .....

SSW 규칙

여기에는 일부 C # 표준 + 훨씬 더 많은 내용이 포함되어 있습니다. 주로 Microsoft 개발자를 대상으로합니다.

실패하도록 설정되어있을 가능성이 큽니다. 업계에 오신 것을 환영합니다.

동의하지 않습니다. 문서를 작성하는 한, 최악의 상황은 모든 사람이 문서를 잊어 버리는 것입니다.

다른 사람이 콘텐츠에 문제가있는 경우 원하는 내용을 표시하도록 업데이트하도록 요청할 수 있습니다. 그렇게하면 당신의 판에서 벗어나고 다른 사람들은 그들의 변화를 정당화 할 책임이 있습니다.

최근에 다른 여러 출처 (IDesign, Philips, MSDN)의 아이디어가 포함 된 Encodo C # Handbook을 발견 했습니다 .

또 다른 출처는 Professional C # / VB .NET 코딩 지침 일 수 있습니다.

Francesco Balena 책 " VB 및 C # 개발자를위한 실용 가이드 라인 및 모범 사례 "를 좋아 합니다.

그것은 매우 상세하고 모든 필수 주제를 다루며, 규칙을 제공 할뿐만 아니라 규칙의 이유를 설명하고 두 가지 반대되는 모범 사례가있을 수있는 반 규칙을 제공합니다. 유일한 단점은 .NET 1.1 개발자를 위해 작성된 것입니다.

우리의 전체 코딩 표준은 대략 "Use StyleCop"이라고 읽습니다.

이 참조 : http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx를 .

dotnetspider.com 문서 를 제안 해야 합니다.
어디에서나 유용하고 훌륭하고 자세한 문서입니다.

나는 Juval의 이전을 사용했지만 과잉이 아닌 경우에는 통과되었지만 게으르고 이제는 Resharper 의 의지에 따릅니다 .

당신은 C #은이, 최고 7 코딩 표준 및 가이드 라인 문서를 확인하실 수 있습니다 /. NET 개발자는 http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html 이 도움이되기를 바랍니다

나는 이미 연결된 MS guidlines가 훌륭한 출발점이라는 다른 의견을 반향한다고 생각합니다. 나는 그 코드를 주로 모델링합니다.

내 관리자가 과거에 너무 열중하지 않았다고 말했기 때문에 흥미 롭습니다.

내 친구보다 재미있는 일이 있습니다. 행운을 빕니다. 더 필요한 것이 있으면 물어보십시오. :)

필립스 의료 시스템의 표준은 잘 작성되었으며 대부분 Microsoft 지침을 따릅니다. www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

내 표준은 이것을 약간 조정하고 .NET 2.0에 대한 일부 업데이트를 기반으로합니다 (필립스 표준은 .NET 1.x 용으로 작성되었으므로 약간 날짜가 있습니다).

나는 또한 Resharper를 따릅니다. 또한 scott guthrie 블로그 http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net 에 언급 된 가이드 라인 .aspx 및 http://csharpguidelines.codeplex.com/releases/view/46280

필자가 작성한 코드에서는 일반적 으로 공개적으로 노출 된 API에 대한 .NET Framework 디자인 지침 과 개인 멤버 케이싱 및 들여 쓰기에 대한 모노 코딩 지침 을 따릅니다 . 모노는 .NET의 오픈 소스 구현이며 그 사람들이 자신의 사업을 알고 있다고 생각합니다.

Microsoft 코드가 공간을 낭비하는 방법이 싫습니다.

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

Mono 지침에서 이상한 점은 8 개의 공백 탭을 사용한다는 것입니다. 그러나 몇 가지 연습을 한 후에 일종의 들여 쓰기 제한을 적용하여 덜 꼬인 코드를 작성하는 데 실제로 도움이된다는 것을 알았습니다.

나는 또한 괄호를 열기 전에 공백을 넣는 방법을 좋아합니다.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

그러나 동료가 싫어하는 경우 (Mono에 기꺼이 기여하지 않는 한) 그런 것을 강요하지 마십시오.