2010. 5. 24. 17:22
[ Item 1 ] 데이터 멤버 대신에 항상 프로퍼티를 사용하라

  • 프로퍼티는 데이터 멤버처럼 접근 가능하면서 메서드의 형태로 구현되는 C# 언어의 요소.
  • 프로퍼티는 메서드로 취급되므로 virtual로도 지정이 가능하며,  abstract 형태로 정의되거나 interface의 한 부분으로 정의될 수도 있다.
  • get / set 에 따로 접근한정자를 지정할 수 있다.
  • 인덱서를 정의해 배열처럼 사용할 수 있다.

 

[ Item 2 ] const 보다는 readonly가 좋다

const
  • 컴파일 타임 상수. 즉, 컴파일 타임에 const 에 정의된 실제값으로 치환된다.
  • const는 어셈블리에 실제값이 기록되므로, const 값이 변경되면 해당 const 값을 사용한 모든 어셈블리를 재빌드해서 배포해야 한다.
  • 속도가 빠른대신 유연성이 떨어진다.
readonly
  • 런타임 상수. const와 달리 치환되지 않고 변경이 불가능하다.
  • readonly는 어셈블리에 실제값이 아닌 readonly의 참조가 기록되므로, readonly가 정의된 어셈블리만 재빌드해서 배포하면 된다.
  • 유연성이 높은 대신 속도가 떨어진다.


const를 사용할  때 얻을 수 있는 속도 향상은 미미하므로, 대부분의 경우 const 보다는 readonly 를 사용하는 것이 좋다.


[ Item 3 ] cast 보다는 is나 as가 좋다

형변환은 가능한 한 피해야 하지만, 어쩔 수 없이 사용해야 하는 경우에는 as나 is를 사용하도록 한다.

  • C 언어 방식의 cast 는 상황에 따라서 다르게 동작할 수 있지만, as 연산자는 항상 일관되게 동작한다.
  • as 연산자는 사용자가 정의한 형변환 연산자를 전혀 고려하지 않는다.
  • as 연산자는 value 타입에 대해서는 동작하지 않는다. 이 경우에는 is 연산자로 먼저 value 타입인지를 판단하면 된다.
  • 완전히 동일한 타입인지를 검사하려면 GetType() 메서드를 사용한다.

as 와 is 연산자는 항상 일관된 동작을 보여주며 형변환이 정확히 수행될 수 있는지를 확인하고 정확한 형변환을 수행한다. 따라서, cast 연산을 수행하였을 때 발생할 수 있는 의도하지 않은 동작들을 피할 수 있다.

[ Item 4 ] #if 대신 Conditional Attribute를 사용하라

#if ~ #endif 구문으로 기능을 분리하는 하는 것은 버그를 유발시킬 우려가 높다. 메서드의 경우 #if ~ #endif 대신 Conditional Attribute 를 사용해 이러한 경우를 예방할 수 있다.

  • Conditional Attribute 는 void의 return type을 가지는 메서드에 한해 사용할 수 있다. 이 경우가 아니라면 #if ~ #endif 를 사용해야 한다.
  • Conditional Attribute 를 사용한 메서드는 #if ~ #endif 처럼 빌드에서 제외되는 것이 아니라, 어셈블리에 포함은 되지만 사용되지 않을 뿐이다.
  • Conditional Attribute 는 "or" 조건으로 여러개를 조합해 사용할 수 있다.
  • "and" 조건은 지원하지 않기 때문에, #if ~ #endif 를 사용해야 한다.

써 놓고 보니 이건 웬지 효용이 높지는 않을듯한 느낌도 드는군요...
관련 MSDN 페이지 : http://msdn.microsoft.com/ko-kr/library/aa664622(VS.101).aspx

[ Item 5 ] 항상 ToString()을 작성하라

System.Object.ToString() 은 닷넷 환경에서 가장 빈번하게 사용되는 메서드이며, 타입에 대한 정보를 알아보기 쉬운 문자열로 표현한다.
  • System.Object 에 기본으로 제공되는 ToString() 은 단순히 타입 이름만을 반환하기 때문에 별다른 도움이 되지 못한다. 자신이 작성하는 타입에 대한 ToString() 을 제공해 도움이 되는 정보를 주도록 한다.
  • 정교한 출력을 위해 IFormattable.ToString() 을 사용할 수도 있다. IFormattable을 구현한 클래스에 대해 IFormatProvider와 ICustomFormatter을 선택적으로 구현할 수 있다.


출처 - Effective C# (한빛미디어)
Posted by mobilism
TAG

댓글을 달아 주세요

  1. 태워니 2011.03.31 15:14  댓글주소  수정/삭제  댓글쓰기

    감사합니다. 이팩티브 C# 퍼갑니다~

  2. Cargold 2020.11.06 13:53 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 글을 읽다가 몇가지 의견이 있어서 덧글을 답니다.

    2번
    콘스트가 리드온리보다 빠르긴 해도 효과가 미미하단 건 근거가 무엇인가요?

    3번
    유니티에서 널비교 때 주로 쓰는 효과인데, 그 차이가 압도적이더군요.
    class == null 보단 class is null이 40배는 더 연산이 빠릅니다.
    유니티의 개발 블로그에서 널비교에 대한 글이 올라왔던 걸로 기억합니다.

    4번
    콘디셔널 어트리뷰트를 쓰긴 쓰는데 더 적극적으로 쓸 필요가 있겠네요.
    말씀하신 것처럼 디파인 심볼에 누락되면 컴파일에서 체크를 안 해주니 빌드할 때마다 컴파일 에러를 일일이 체크하기 번거롭더라구요...
    좋은 정보 감사합니다.