[ Item 1 ] 데이터 멤버 대신에 항상 프로퍼티를 사용하라
[ Item 3 ] cast 보다는 is나 as가 좋다
형변환은 가능한 한 피해야 하지만, 어쩔 수 없이 사용해야 하는 경우에는 as나 is를 사용하도록 한다.
as 와 is 연산자는 항상 일관된 동작을 보여주며 형변환이 정확히 수행될 수 있는지를 확인하고 정확한 형변환을 수행한다. 따라서, cast 연산을 수행하였을 때 발생할 수 있는 의도하지 않은 동작들을 피할 수 있다.
[ Item 4 ] #if 대신 Conditional Attribute를 사용하라
#if ~ #endif 구문으로 기능을 분리하는 하는 것은 버그를 유발시킬 우려가 높다. 메서드의 경우 #if ~ #endif 대신 Conditional Attribute 를 사용해 이러한 경우를 예방할 수 있다.
써 놓고 보니 이건 웬지 효용이 높지는 않을듯한 느낌도 드는군요...
관련 MSDN 페이지 : http://msdn.microsoft.com/ko-kr/library/aa664622(VS.101).aspx
[ Item 5 ] 항상 ToString()을 작성하라
System.Object.ToString() 은 닷넷 환경에서 가장 빈번하게 사용되는 메서드이며, 타입에 대한 정보를 알아보기 쉬운 문자열로 표현한다.
출처 - Effective C# (한빛미디어)
- 프로퍼티는 데이터 멤버처럼 접근 가능하면서 메서드의 형태로 구현되는 C# 언어의 요소.
- 프로퍼티는 메서드로 취급되므로 virtual로도 지정이 가능하며, abstract 형태로 정의되거나 interface의 한 부분으로 정의될 수도 있다.
- get / set 에 따로 접근한정자를 지정할 수 있다.
- 인덱서를 정의해 배열처럼 사용할 수 있다.
[ Item 2 ] const 보다는 readonly가 좋다
- 컴파일 타임 상수. 즉, 컴파일 타임에 const 에 정의된 실제값으로 치환된다.
- const는 어셈블리에 실제값이 기록되므로, const 값이 변경되면 해당 const 값을 사용한 모든 어셈블리를 재빌드해서 배포해야 한다.
- 속도가 빠른대신 유연성이 떨어진다.
- 런타임 상수. 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# (한빛미디어)
'C# > Effective C#' 카테고리의 다른 글
| 이펙티브 C# - 요점 정리 (Item 26~30) (2) | 2010.06.25 |
|---|---|
| 이펙티브 C# - 요점 정리 (Item 21~25) (1) | 2010.06.18 |
| 이펙티브 C# - 요점 정리 (Item 16~20) (3) | 2010.06.12 |
| 이펙티브 C# - 요점 정리 (Item 11~15) (3) | 2010.06.06 |
| 이펙티브 C# - 요점 정리 (Item 6~10) (1) | 2010.05.29 |
| 이펙티브 C# - 요점 정리 (Item 1~5) (2) | 2010.05.24 |
TAGC#
댓글을 달아 주세요
감사합니다. 이팩티브 C# 퍼갑니다~
안녕하세요. 글을 읽다가 몇가지 의견이 있어서 덧글을 답니다.
2번
콘스트가 리드온리보다 빠르긴 해도 효과가 미미하단 건 근거가 무엇인가요?
3번
유니티에서 널비교 때 주로 쓰는 효과인데, 그 차이가 압도적이더군요.
class == null 보단 class is null이 40배는 더 연산이 빠릅니다.
유니티의 개발 블로그에서 널비교에 대한 글이 올라왔던 걸로 기억합니다.
4번
콘디셔널 어트리뷰트를 쓰긴 쓰는데 더 적극적으로 쓸 필요가 있겠네요.
말씀하신 것처럼 디파인 심볼에 누락되면 컴파일에서 체크를 안 해주니 빌드할 때마다 컴파일 에러를 일일이 체크하기 번거롭더라구요...
좋은 정보 감사합니다.