코드분석 규칙/디자인 규칙2007. 2. 21. 10:40

[번역]디자인규칙3. 제네릭 목록을 노출하지 마십시오

규칙 클래스 이름: DoNotExposeGenericList
규칙 ID: CA1002
분류: 디자인 규칙
메시지 레벨: 에러
확실도: 95%

원인: System.Collections.Generic.List<T> 타입을 외부로 노출시켰거나, 리턴 타입으로 사용하거나, 혹은 파라미터로 사용했을 때 이 규칙에 위반된다.

규칙 설명
System.Collections.Generic.List<T>는 성능을 위해서 디자인된 제네릭 컬렉션이며 상속성등은 고려되지 않았다. 그래서 어떤 가상 멤버도 그 안에 포함할 수가 없다. 아래의 제네릭 컬렉션은 상속성을 고려해서 디자인되었으므로, 리턴 타입/파라미터/외부 노출 형식에는 아래 타입들을 써야 할 것이다.

원문: http://www.gotdotnet.com/team/fxcop/Docs/Rules/Design/DoNotExposeGenericLists.html

* System.Collections.Generic.List<T>는 MSDN을 보면 나와있듯이 ArrayList의 Generic 버전이라고 생각하면 된다. 즉, 동적으로 크기가 늘어나고 빠르게 접근할 수 있는 특정 구현 형태로 보면 될 것이다.
외부 노출/리턴 타입/파라미터 등은 각 클래스들이 관계를 맺는 방식에 영향을 줄 수 있다. 이런 곳에서 상속할 수 없는 특정 구현 형태를 사용함으로써 그것에 얽매이는 것은 매우 좋지 않다는 것이 바로 이 규칙이 말하는 바라고 생각된다.

'코드분석 규칙 > 디자인 규칙' 카테고리의 다른 글

[번역]디자인규칙2. 삭제가능한 필드가 있는 형식은 삭제가능해야 합니다  (0) 2006.10.21
[번역]디자인규칙1. 정적 멤버를 제네릭 형식으로 선언하지 마십시오  (0) 2006.10.16
[Article]VSTS 코드 분석 디자인 규칙  (0) 2006.10.14
Posted by kkongchi
TAG Fxcop, Fxcop Design Rules, Fxcop 디자인 규칙, Static code analysis, Visual Studio 2005, Visual Studio 2005 Team System, VS2005, VSTS, 코드 분석
Trackback 0 Comment 6

댓글을 달아 주세요

  1. Favicon of http://ncanis.tistory.com/ BlogIcon 카니스

    자바쪽도 JDK5부터 generic이 지원됬죠. 무지 좋습니다. 타입을 정의함으로써 내부적으로 메모리 할당이나 속도면에서 획기적으로 바뀌었으니까요.
    그냥 List 보다 List<Integer> 이 더 관리측면에서는 더 좋죠. 물론 사용하는 측면에서도요. ^^

    2007.02.21 12:45 [ ADDR : EDIT/ DEL : REPLY ]
  2. Favicon of http://www.sysnet.pe.kr BlogIcon 정성태

    FAQ: Why does DoNotExposeGenericLists recommend that I expose Collection<T> instead of List<T>? [David Kean]
    ; http://blogs.msdn.com/fxcop/archive/2006/04/27/585476.aspx

    위의 토픽에서도 잘 설명해 주고 있습니다. ^^

    2007.02.21 14:12 [ ADDR : EDIT/ DEL : REPLY ]
  3. Favicon of http://blog.naver.com/NBlogMain.nhn?blogId=juliet_4 BlogIcon 모모

    좋은 정보네요~ ^^

    2007.03.28 16:09 [ ADDR : EDIT/ DEL : REPLY ]

코드분석 규칙/디자인 규칙2006. 10. 14. 00:52

[Article]VSTS 코드 분석 디자인 규칙

디자인 규칙은 클래스 라이브러리 디자인 가이드라인에 따르는 지를 검사하는 규칙들의 모음이다. 닷넷의 기본적인 사상에 부합되는 클래스, 인터페이스, 예외 처리 등의 디자인이 되었는지(예:CA1020 형식이 부족한 네임스페이스를 사용하지 마십시오), .NET Class Library에서 적용된 기본적인 설계 원칙들을 따르고 있는 지(예: CA1056 Uri 속성은 문자열이면 안 됩니다), .NET Framework의 기본적인 규칙을 따로 있는지(예:CA2210 어셈블리에는 올바른 강력한 이름을 사용해야 합니다) 등을 검사하는 것이라고 할 수 있다.

디자인 규칙에는 아래와 같은 규칙들이 있다.

CA1000 정적 멤버를 제네릭 형식으로 선언하지 마십시오
CA1001 삭제 가능한 필드가 있는 형식은 삭제 가능해야 합니다.
CA1002 제네릭 목록을 노출하지 마십시오.
CA1003 제네릭 이벤트 처리기 인스턴스를 사용하십시오.
(추가 예정... 각 규칙을 클릭하면 규칙에 대한 포스트로 이동한다)

'코드분석 규칙 > 디자인 규칙' 카테고리의 다른 글

[번역]디자인규칙3. 제네릭 목록을 노출하지 마십시오  (6) 2007.02.21
[번역]디자인규칙2. 삭제가능한 필드가 있는 형식은 삭제가능해야 합니다  (0) 2006.10.21
[번역]디자인규칙1. 정적 멤버를 제네릭 형식으로 선언하지 마십시오  (0) 2006.10.16
Posted by kkongchi
TAG .NET, .NET Design Rules, .NET FRAMEWORK, .NET 디자인 규칙, Fxcop, Fxcop Design Rules, Fxcop 디자인 규칙, Static code analysis, Visual Studio 2005, Visual Studio 2005 Team System, VS2005, VSTS, 코드 분석
Trackback 0 Comment 0

댓글을 달아 주세요

코드분석 규칙2006. 10. 14. 00:52

[Article]Visual Studio 2005 Team System 코드 분석

이 블로그의 이전 글(FxCOP - 비주얼 스튜디오 2005 코드 분석 Custom 규칙 작성하기)에서 이미 소개한 바 있지만, Visual Studio 2005 Team System에서는 아주 강력한 코드 분석 도구를 제공한다. 이 코드 분석 도구는 자체적으로 200개 이상의 규칙을 가지고, 코드를 검사하게 된다. 이 규칙들은 Microsoft가 제안하는 닷넷 클래스 라이브러리에서의 지켜야 할 디자인 가이드라인과 성능 등의 분야에서 검증된 Best Practice 등을 토대로 이루어져있기 때문에, 코딩 시 지켜야 함은 물론이고 .NET Framework을 공부하는 이들에게도 매우 유용한 리소스라고 할 수 있다.

코드 분석의 규칙은 아래의 카테고리로 나누어진다.

디자인 규칙
명명 규칙
보안 규칙
사용 규칙
상호 운용성 규칙
성능 규칙
안정성 규칙
유지 관리 규칙
이동성 규칙
이식성 규칙
전역화 규칙

* 앞으로 각 카테고리 별로 개요와 그 카테고리에 속한 각각의 규칙들에 대해서 하나하나 짚어 볼 생각이며, 글이 업데이트 될 때마다 링크가 연결될 예정이다.

* 그리고, VSTS 한글판에 있는 현재 규칙들의 이름은 너무나 번역이 부실해서...이름만으로는 도저히 그 규칙의 내용에 대해서 알 수가 없다. 이 점도 이 글을 쓰게 된 동기라고 할 수 있다.

'코드분석 규칙' 카테고리의 다른 글

[ETC]FxCop Custom Rule 작성에 대한 좋은 문서  (0) 2008.01.19
Posted by kkongchi
TAG Static code analysis, Visual Studio 2005, Visual Studio 2005 Team System, VS2005, VSTS, 코드 분석
Trackback 0 Comment 2

댓글을 달아 주세요

  1. Favicon of http://machari.tistory.com BlogIcon 마차리

    연재가 기대됩니다.

    2007.01.18 17:03 [ ADDR : EDIT/ DEL : REPLY ]

.NET General2006. 5. 4. 21:20

[Tip]Visual Studio 2005에서 직접 실행 창을 보이게 하는 방법

비주얼 스튜디오 닷넷 2003 을 사용할 때, 디버깅 시에 가장 유용하게 사용했던 도구라고 한다면, 내 경우는 직접 실행 창이었다. 물론 자동, 지역, 조사식 등의 도구들도 있지만, 난 대부분의 경우 직접 실행 창을 사용했다. 인텔리센스 기능도 지원하기 때문에, 코드 외의 여러 가지를 실행시켜보면서 작업할 수 있기도 하고, 변수에 담긴 값이 꽤 클 때도 보기가 편하다는 장점이 있어서, 디버깅을 할 때 코드를 step by step으로 실행시키면서 직접 실행창만을 가지고 작업을 했었다.

비주얼 스튜디오 2003(그리고 그 이전 버전)에서는 메뉴중에서 디버그->창->직접실행 을 선택하면 디버그 중에서 직접 실행 창을 볼 수 있었다. 그런데, 이번에 새로 출시된 Visual Studio 2005에서는 (내가 못 찾은 것인지 아니면 어딘가 숨어 있는지는 모르겠지만) 디버그->창 까지는 있는데 거기에 직접실행창을 띄우는 메뉴는 없다.

이 직접 실행 창을 띄우는 방법은 다음과 같다.

1. 기본적으로 명령 창은 디버그 시에 자동으로 나오게 된다. 이 명령 창에서 immed를 입력하고 엔터를 누른다




2. 그러면 직접 실행 창이 나오게 된다. 여기서 이전처럼 사용하면 된다.


'.NET General' 카테고리의 다른 글

[Etc]MS - PHP - Linux Alliance?  (11) 2006.11.03
[HowTo]FxCOP(비주얼 스튜디오 2005 코드 분석) Custom 규칙 작성하기(C#)  (0) 2006.07.25
[Article]SQL Injection(.NET, C#)  (2) 2006.07.22
[Etc]MCPD Beta Exam  (0) 2006.03.05
[HowTo]NANT 사용하기  (0) 2006.02.20
Posted by kkongchi
TAG VS2005
Trackback 0 Comment 2

댓글을 달아 주세요

  1. 그나

    어.. 안녕하세요 저 김근아 에요.
    우연찮게 검색하다 일루 들어왔는데 꽁치 그림이 보이네요 ㅎㅎ
    잘 계시죠 ㅋ

    2007.08.18 15:56 [ ADDR : EDIT/ DEL : REPLY ]
    • Favicon of https://lazydeveloper.net BlogIcon kkongchi

      오랜만에 뵙는데요 ㅎㅎ 요즘 이 블로그 거의 방치하다시피 했는데..-_-;; 검색을 타고 들어오시다니..블로그 인기가 올라가고 있는건지..^^;;; 암튼 엄청 반갑네요. 자주 놀러오세요 ㅎㅎ

      2007.08.20 00:38 신고 [ ADDR : EDIT/ DEL ]