반응형
1. Introduction
먼저, .NET Framework Design Guideline들을 읽도록 해라. 대부분의 모든 네이밍 결정, 캐스팅 룰, 등등은 이 문서에서 설명한다. Design Guideline 문서들과는 다르게, 당신은 이 문서를 제안된 guideline들의 집합으로 간주하게 될 것이다. 이러한 일반적인 것은 고객들이 원하지 않는다면 고객의 시점에서 아무 효과도 없을 것이다.
2. Style Guidelines
2.1 Tabs & Indenting
Tab 문자 (?x09)는 코드에서 사용하지 않도록 한다. 모든 들여쓰기는 4개의 스페이스 문자를 사용한다.
2.2 Bracing
시작하는 중괄호는 항상 명령문의 다음 라인의 시작 지점에서 지역의 시작에 위치한다. 중괄호의 내용은 4개의 스페이스들로 들어가도록 한다.
if (SomeExpression)
{
DoSomething();
}
else
{
DoSomething();
}
“case” 명령문은 switch 명령문에서 안쪽으로 다음과 같이 들어가야 한다:
switch (someExpression)
{
case 0:
DoSomething();
break;
case 1:
DoSomethingElse();
break;
case 2:
{
int n = 1;
DoAnotherThing(n);
}
break;
}
중괄호는 선택적으로 고려해야 되어야 하는 것이 아니다. 단일 명령 지역에서 조차, 당신은 언제나 중괄호를 사용하여야 한다. 이것은 코드의 가독성과 유지보수를 증가 시킨다..
for (int i=0; i<100; i++) { DoSomething(i); }
2.3 Single line statements
단일 명령문은 같은 줄에 시작과 끝을 나타내는 중괄호를 가진다.
public class Foo
{
int bar;
public int Bar
{
get { return bar; }
set { bar = value; }
}
}
이것은 모든 제어 구문(if, while, for, 등등.)에서 중괄호를 사용하도록 제안하지만, 필요한 것은 아니다.
2.4 Commenting
주석은 목적, 알고리즘 개요, 로직 흐름을 기술하는데 사용된다. 주석이 단일적으로 읽혀지는 것에서 누군가 다른 저작자가 작성한 함수가 필요한 목적과 일반적인 운영을 이해할 수 있다면 이것은 이상적인 주석이다. 최소한의 주석 요구가 없고, 확실하게 매우 작은 루틴들은 주석처리가 필요하지 않겠지만 대부분의 루틴들은 프로그래머들의 목적과 접근성을 반영하는 주석들을 가지는 것이 좋다.
2.4.1 Copyright notice
각 파일은 저작권에 대한 것으로 시작해야 한다. 문서의 주석을 빌드하는 것에서 에러를 피하고 싶어서 XML방식으로 작업하고 싶지는 않겠지만, 미래에는 XML 주석 방식이 매우 편하게 될 것이다. 마지막으로 텍스트는 제품에 따라서 변경되지만 (당신은 정확한 텍스트를 위한 법률에 대하여 알아야 한다), 다음과 비슷할 것이다:
//-----------------------------------------------------------------------
//
// Copyright (c) Microsoft Corporation. All rights reserved.
//
//-----------------------------------------------------------------------
2.4.2 Documentation Comments
모든 메소드들은 XML 문서 주석을 사용한다. 내부 개발 주석을 위하여 태그를 사용해야 한다.
public class Foo
{
/// Public stuff about the method
/// What a neat parameter!
/// Cool internal stuff!
///
public void MyMethod(int bar) { … }
}
그렇지만 However, 당신이 공유되는 외부 파일에 XML 주석 문서를 이동하기를 원하는 경우가 있다면 태그를 사용하도록 한다.
public class Foo
{
///
///
public void MyMethod(int bar) { … }
}
작업 중 § 이것들은 우리가 사용하는 모든 주석 태그들은 매우 커다란 문서가 될 것이다.
2.4.3 Comment Style
주석 구문의 // (two slashes) 방식은 대부분의 경우에 사용된다. 가능한 모든 곳에 코드의 곁에 주석을 위치시키도록 한다. 여기에 예제가 있다:
// This is required for WebClient to work through the proxy
GlobalProxySelection.Select = new WebProxy("http://itgproxy");
// Create object to access Internet resources
//
WebClient myClient = new WebClient();
주석들은 스페이스가 뒤따를 때 줄의 끝에 위치할 수 있다:
public class SomethingUseful
{
private int itemHash; // instance member
private static bool hasDoneSomething; // static member
}
2.5 Spacing
공백은 코드의 밀집 상태를 감소시켜 가독성을 향상시킨다. 여기에 코드 사이에 공백 문자를 사용하는 약간의 지침이 있다:
• 함수의 인자 사이의 콤마 뒤에 단일 공백을 사용한다.
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);
• 함수 인자들과 소괄호 뒤에 공백을 사용하지 않는다.
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )
• 함수 이름과 소괄호 사이에 공백을 사용하지 않는다.
Right: CreateFoo()
Wrong: CreateFoo ()
• 대괄호 사이에 공백을 사용하지 않는다.
Right: x = dataArray[index];
Wrong: x = dataArray[ index ];
• 제어 구분 전에 공백을 사용한다.
Right: while (x == y)
Wrong: while(x==y)
• 비교 연산자 앞뒤로 공백을 사용한다.
Right: if (x == y)
Wrong: if (x==y)
2.6 Naming
내부와 외부 멤버들을 위한 모든 .NET Framework Design Guideline들은 다음과 같다:
• 헝가리안 표기법을 사용하지 않는다.
• 멤버 변수들을 위한 접두사를 사용하지 않는다 (_, m_, s_, 등등) . 만약 당신이 지역 변수와 멤버 변수들을 구분하기를 원한다면 “this.”을 사용해야 한다.
• 멤버 변수들을 위하여 camelCasing을 사용한다.
• 인자들을 위하여 camelCasing을 사용한다.
• 지역 변수들을 위하여 camelCasing을 사용하도록 한다.
• 함수, 속성, 이벤트, 클래스 이름을 위하여 PascalCasing을 사용하도록 한다.
• 인터페이스들의 이름에 접두사 “I”를 사용한다.
• enum, class나 어떠한 무자를 대표하는 문자를 위한 접두사를 사용하지 않는다.
일반적인 규칙들 (헝가리안 표기법의 사용안함, 멤버 변수들을 위한 접두사를 사용 안함, 등등)을 확장하는 이유는 모순되는 소스 코드의 형식을 생산하기 때문이다. 추가적인 목적은 명확한 가독성을 가지는 소스를 만드는 것이다. 코드를 읽기 쉽도록 하는 것이 최대의 목적이다.
2.7 File Organization
• 소스 파일은 여러 내부 클래스들을 따르는 것을 허용하지만, 오직 하나의 일반적인 종류 만을 허용해야 한다.
• 소스 파일들은 파일 안의 일반적인 클래스의 이름으로 작명한다.
• 디렉토리 이름은 클래스를 위한 namespace에 따른다.
에를 들면, 나는 “SystemWindowsFormsControl.cs”… 안에서 일반적인 “System.Windows.Forms.Control” 클래스를 같는다.
• 클래스 멤버는 알파벳으로 표현되고 섹션으로 그룹화 된다 (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types).
• 구문을 사용하는 것은 namespace 정의 안쪽에 위치한다.
namespace MyNamespace
{
using System;
public class MyClass : IFoo
{
// fields
int foo;
// constructors
public MyClass() { … }
// properties
public int Foo { get { … } set { … } }
// events
public event EventHandler FooChanged { add { … } remove { … } }
// methods
void DoSomething() { … }
void FindSomethind() { … }
//private interface implementations
void IFoo.DoSomething() { DoSomething(); }
// nested types
class NestedType { … }
}
}
먼저, .NET Framework Design Guideline들을 읽도록 해라. 대부분의 모든 네이밍 결정, 캐스팅 룰, 등등은 이 문서에서 설명한다. Design Guideline 문서들과는 다르게, 당신은 이 문서를 제안된 guideline들의 집합으로 간주하게 될 것이다. 이러한 일반적인 것은 고객들이 원하지 않는다면 고객의 시점에서 아무 효과도 없을 것이다.
2. Style Guidelines
2.1 Tabs & Indenting
Tab 문자 (?x09)는 코드에서 사용하지 않도록 한다. 모든 들여쓰기는 4개의 스페이스 문자를 사용한다.
2.2 Bracing
시작하는 중괄호는 항상 명령문의 다음 라인의 시작 지점에서 지역의 시작에 위치한다. 중괄호의 내용은 4개의 스페이스들로 들어가도록 한다.
if (SomeExpression)
{
DoSomething();
}
else
{
DoSomething();
}
“case” 명령문은 switch 명령문에서 안쪽으로 다음과 같이 들어가야 한다:
switch (someExpression)
{
case 0:
DoSomething();
break;
case 1:
DoSomethingElse();
break;
case 2:
{
int n = 1;
DoAnotherThing(n);
}
break;
}
중괄호는 선택적으로 고려해야 되어야 하는 것이 아니다. 단일 명령 지역에서 조차, 당신은 언제나 중괄호를 사용하여야 한다. 이것은 코드의 가독성과 유지보수를 증가 시킨다..
for (int i=0; i<100; i++) { DoSomething(i); }
2.3 Single line statements
단일 명령문은 같은 줄에 시작과 끝을 나타내는 중괄호를 가진다.
public class Foo
{
int bar;
public int Bar
{
get { return bar; }
set { bar = value; }
}
}
이것은 모든 제어 구문(if, while, for, 등등.)에서 중괄호를 사용하도록 제안하지만, 필요한 것은 아니다.
2.4 Commenting
주석은 목적, 알고리즘 개요, 로직 흐름을 기술하는데 사용된다. 주석이 단일적으로 읽혀지는 것에서 누군가 다른 저작자가 작성한 함수가 필요한 목적과 일반적인 운영을 이해할 수 있다면 이것은 이상적인 주석이다. 최소한의 주석 요구가 없고, 확실하게 매우 작은 루틴들은 주석처리가 필요하지 않겠지만 대부분의 루틴들은 프로그래머들의 목적과 접근성을 반영하는 주석들을 가지는 것이 좋다.
2.4.1 Copyright notice
각 파일은 저작권에 대한 것으로 시작해야 한다. 문서의 주석을 빌드하는 것에서 에러를 피하고 싶어서 XML방식으로 작업하고 싶지는 않겠지만, 미래에는 XML 주석 방식이 매우 편하게 될 것이다. 마지막으로 텍스트는 제품에 따라서 변경되지만 (당신은 정확한 텍스트를 위한 법률에 대하여 알아야 한다), 다음과 비슷할 것이다:
//-----------------------------------------------------------------------
//
// Copyright (c) Microsoft Corporation. All rights reserved.
//
//-----------------------------------------------------------------------
2.4.2 Documentation Comments
모든 메소드들은 XML 문서 주석을 사용한다. 내부 개발 주석을 위하여 태그를 사용해야 한다.
public class Foo
{
/// Public stuff about the method
/// What a neat parameter!
/// Cool internal stuff!
///
public void MyMethod(int bar) { … }
}
그렇지만 However, 당신이 공유되는 외부 파일에 XML 주석 문서를 이동하기를 원하는 경우가 있다면 태그를 사용하도록 한다.
public class Foo
{
///
///
public void MyMethod(int bar) { … }
}
작업 중 § 이것들은 우리가 사용하는 모든 주석 태그들은 매우 커다란 문서가 될 것이다.
2.4.3 Comment Style
주석 구문의 // (two slashes) 방식은 대부분의 경우에 사용된다. 가능한 모든 곳에 코드의 곁에 주석을 위치시키도록 한다. 여기에 예제가 있다:
// This is required for WebClient to work through the proxy
GlobalProxySelection.Select = new WebProxy("http://itgproxy");
// Create object to access Internet resources
//
WebClient myClient = new WebClient();
주석들은 스페이스가 뒤따를 때 줄의 끝에 위치할 수 있다:
public class SomethingUseful
{
private int itemHash; // instance member
private static bool hasDoneSomething; // static member
}
2.5 Spacing
공백은 코드의 밀집 상태를 감소시켜 가독성을 향상시킨다. 여기에 코드 사이에 공백 문자를 사용하는 약간의 지침이 있다:
• 함수의 인자 사이의 콤마 뒤에 단일 공백을 사용한다.
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);
• 함수 인자들과 소괄호 뒤에 공백을 사용하지 않는다.
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )
• 함수 이름과 소괄호 사이에 공백을 사용하지 않는다.
Right: CreateFoo()
Wrong: CreateFoo ()
• 대괄호 사이에 공백을 사용하지 않는다.
Right: x = dataArray[index];
Wrong: x = dataArray[ index ];
• 제어 구분 전에 공백을 사용한다.
Right: while (x == y)
Wrong: while(x==y)
• 비교 연산자 앞뒤로 공백을 사용한다.
Right: if (x == y)
Wrong: if (x==y)
2.6 Naming
내부와 외부 멤버들을 위한 모든 .NET Framework Design Guideline들은 다음과 같다:
• 헝가리안 표기법을 사용하지 않는다.
• 멤버 변수들을 위한 접두사를 사용하지 않는다 (_, m_, s_, 등등) . 만약 당신이 지역 변수와 멤버 변수들을 구분하기를 원한다면 “this.”을 사용해야 한다.
• 멤버 변수들을 위하여 camelCasing을 사용한다.
• 인자들을 위하여 camelCasing을 사용한다.
• 지역 변수들을 위하여 camelCasing을 사용하도록 한다.
• 함수, 속성, 이벤트, 클래스 이름을 위하여 PascalCasing을 사용하도록 한다.
• 인터페이스들의 이름에 접두사 “I”를 사용한다.
• enum, class나 어떠한 무자를 대표하는 문자를 위한 접두사를 사용하지 않는다.
일반적인 규칙들 (헝가리안 표기법의 사용안함, 멤버 변수들을 위한 접두사를 사용 안함, 등등)을 확장하는 이유는 모순되는 소스 코드의 형식을 생산하기 때문이다. 추가적인 목적은 명확한 가독성을 가지는 소스를 만드는 것이다. 코드를 읽기 쉽도록 하는 것이 최대의 목적이다.
2.7 File Organization
• 소스 파일은 여러 내부 클래스들을 따르는 것을 허용하지만, 오직 하나의 일반적인 종류 만을 허용해야 한다.
• 소스 파일들은 파일 안의 일반적인 클래스의 이름으로 작명한다.
• 디렉토리 이름은 클래스를 위한 namespace에 따른다.
에를 들면, 나는 “SystemWindowsFormsControl.cs”… 안에서 일반적인 “System.Windows.Forms.Control” 클래스를 같는다.
• 클래스 멤버는 알파벳으로 표현되고 섹션으로 그룹화 된다 (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types).
• 구문을 사용하는 것은 namespace 정의 안쪽에 위치한다.
namespace MyNamespace
{
using System;
public class MyClass : IFoo
{
// fields
int foo;
// constructors
public MyClass() { … }
// properties
public int Foo { get { … } set { … } }
// events
public event EventHandler FooChanged { add { … } remove { … } }
// methods
void DoSomething() { … }
void FindSomethind() { … }
//private interface implementations
void IFoo.DoSomething() { DoSomething(); }
// nested types
class NestedType { … }
}
}
반응형
'.Net' 카테고리의 다른 글
WPF & Atlas 가 먼가요? (0) | 2007.08.12 |
---|---|
메모리 릭을 제거 하자 ( 펌 ) (0) | 2007.03.13 |
닷넷 내부에서 배포파일을 만들수 있는걸로 아는데 (0) | 2007.03.13 |