C 샤프 프로그래밍/명명 규칙

위키책, 위키책
Jump to: 둘러보기, 검색

이 부분에서는 일반적으로 C# 개발 커뮤니티에서 허용하는 명명 규칙을 정의합니다. 일부 회사에서는 이것과는 다르게 명명 규칙을 정의할 수 도 있습니다. 이 부분에서 설명하는 객체의 일부는 이 시점에서 독자의 지식 밖의 내용일 수도 있습니다. 하지만 나중에 언제든지 다시 이 부분을 확일 할 수 있습니다.

추론[+/-]

명명 표준의 대부분은 Microsoft의 .NET 프레임워크 라이브러리에서 파생되었습니다. 이 표준들은 읽기 싶고, 한 눈에 이해할 수 있음을 입증 하였습니다. 객체의 이름을 정할 때 올바른 규칙을 이용하면 다른 C# 프로그래머가 당신의 코드를 읽을 때 헤매지 않고 쉽게 이해할 수 있습니다.

규칙[+/-]

네임스페이스[+/-]

네임스페이스(Namespace)는 언더바("_")가 없는 파스칼 케이스(카멜 케이스라고도 불림)을 이용하여 이름 짓는다. 이 의미는 이름에서 매 단어의 첫글자를 대문자로 입력하는것을 뜻한다. 예를 들어: MyNewNamespace. 또한 파스칼 케이스에서는 3글자 이상의 약어를 사용할 때에도 첫글자만 대문자로 작성해야한다. (MyXMLNamespace 대신에 MyXmlNamespace )

어셈블리[+/-]

하나의 네임스페이스만을 포함하는 어셈블리의 경우, 같은 이름으로 사용할 수 있다. 마찬가지로, 어셈블리들은 일반적인 파스칼 케이스 형식을 따라야 한다.

클래스와 구조체[+/-]

파스칼 케이스를 따르며 언더바를 사용하거나 "C", "cls", 또는 "I"로 시작해서는 안된다. 클래스는 클래스를 포함하고 있는 네임스페이스와 같은 이름을 사용해서는 안된다. 3글자 이상의 어떠한 약어라도 파스칼 케이스를 따라 모두 대문자로 작성해서는 안된다. 가능하면 약어를 피해 명사를 사용하도록 하여라.

Exception 클래스[+/-]

클래스 명명 규칙을 따릅니다만 이름의 끝에 예외가 붙습니다. 닷넷프레임워크 2.0 에서 모든 클래스는 System.Exception 기본 클래스로 부터 상속 받아야했고 System.ApplicationException으로 부터 상속 받지 않았습니다.

인터페이스[+/-]

클래스 명명 규칙을 따릅니다만 대문자 "I"로 시작합니다. 예: IFoo

접두어 "I"는 인터페이스와 클래스간의 차이를 인지하는데 도움을 주고 이름의 충돌을 피하는데 도움을 주기도 합니다.

함수[+/-]

파스칼 케이스를 따르며 이벤트 핸들러를 제외하고 언더바("_")를 사용해서는 안된다. 약어를 피하도록 하여라.

프로퍼티와 Public 멤버 변수[+/-]

파스칼 케이스를 따르며, 언더바를 사용해서는 안된다. 약어를 피하도록 하여라.

매개변수와 프로시져 수준의 변수[+/-]

카멜 케이스(또는 소문자 카멜 케이스)를 따른다. 카멜 케이스는 파스칼 케이스와 같다. 하지만, 첫번째 단어의 첫글자가 소문자이다. (예를 들어: camelCase, iPhone, iPad 등)

클래스 수준의 Private와 Protected 변수[+/-]

언더바("_")로 시작하는 카멜 케이스를 따른다. 항상 선언부에 "protected" 또는 "private"를 가르킨다.언더바로 시작하는 것은 이 문서에서 유일하다. 접두어를 붙이는것은 생성자에서 이름의 충돌을 피하는데 유리하다. (매개변수와 private 변수는 같은 이름을 가진다.)

폼 컨트롤[+/-]

Pascal Case with a prefix that identifies it as being part of the UI instead of a purely coded control (example a temporary variable). Many developers use "ui" as the prefix followed by a descriptive name such as "tbxUserName" or "lblUserNickName" ("tbx" stands for TextBox control and "lbl" for Label control)

상수[+/-]

Pascal Case. The use of SCREAMING_CAPS is discouraged. This is a large change from earlier conventions. Most developers now realize that in using SCREAMING_CAPS they betray more implementation than is necessary. A large portion of the .NET Framework Design Guidelines is dedicated to this discussion.

예제[+/-]

여기 이러한 명명 규칙들이 총 망라하는 클래스의 예제가 있다.

using System;
 
namespace MyExampleNamespace
{
    public class Customer : IDisposable
    {
        private string _customerName;
        public string CustomerName 
        { 
            get 
            { 
                return _customerName; 
            }
            set
            {
                _customerName = value;
                _lastUpdated = DateTime.Now;
            }
        }
 
        private DateTime _lastUpdated;
 
        public DateTime LastUpdated
        {
            get
            {
                return _lastUpdated;
            }
            private set
            {
                _lastUpdated = value;
            }
        }
 
        public void UpdateCustomer(string newName)
        {
            if( !newName.Equals(CustomerName))
            {
                CustomerName = newName;
            }
        }
 
        public void Dispose()
        {
            //Do nothing
        }
    }
}