코드분석 규칙2008. 1. 19. 11:49

[ETC]FxCop Custom Rule 작성에 대한 좋은 문서

이 블로그에서도 간단하게나마 FxCop Custom 규칙을 만드는 방법을 "[HowTo]FxCOP(비주얼 스튜디오 2005 코드 분석) Custom 규칙 작성하기(C#)" 라는 제목으로 소개한 바 있었다. 내용이 너무 부실해서 민망하긴 해도, 아주 간단한 규칙 정도는 작성할 수 있는 수준의 글이었다.

오늘 MS의 Code Analysis Team Blog에 "Tutorial on writing your own Code Analysis rule" 이라는 글이 올라와서 봤더니, BinaryCoder.Net의 Jason Kresowaty라는 친구가 올린 "FxCop: Writing Your Own Custom Rules"이라는 글을 소개하는 포스팅이었다.

아직은 대충 봤는데, Introspection Object Model에 대해서 아주 자세하게 다루는 것이 눈에 띈다. Introspector라는 자기가 만든 유틸리티도 소개를 하고 있고. 찬찬이 읽어 봐야 겠다.

아래는 그 Instrospector라는 유틸리티의 스크린샷

사용자 삽입 이미지

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

[Article]Visual Studio 2005 Team System 코드 분석  (2) 2006.10.14
Posted by kkongchi
코드분석 규칙/디자인 규칙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
코드분석 규칙/디자인 규칙2006. 10. 21. 10:07

[번역]디자인규칙2. 삭제가능한 필드가 있는 형식은 삭제가능해야 합니다

규칙클래스이름:TypesThatOwnDisposableFieldsShouldBeDisposable
규칙ID:CA1001
분류:디자인 규칙
메시지 레벨:심각한 에러
확실도:95%

원인: System.IDisposable 인터페이스를 구현한 인스턴스 필드를 선언한 클래스에서 IDisposable 인터페이스를 구현하지 않은 경우에 해당한다.

규칙설명
클래스는 가지고 있는 관리되지 않는 리소스(파일 스트림 등의)를 제거하기 위해서 IDisposable 인터페이스를 구현하게 된다. IDisposable 형식의 인스턴스 필드가 있다는 것이 바로 그 필드가 관리되지 않는 리소스를 가지고 있다는 것을 말해 주는 것이다. 간접적으로 관리되지 않는 리소스를 가지고 있는 IDisposable 필드를 선언한 클래스는 반드시 IDisposable 인터페이스를 구현해야 한다. 또 주의해야 할 것은 직접적으로 어떤 관리되지 않는 리소스를 가지고 있지 않는 클래스는 finalizer를 구현해서는 안된다.

예제코드

[C#]
using System;
using System.IO;
 
namespace DesignLibrary
{
   //규칙을 위반한 예제이다.
   public class NoDisposeMethod
   {
      FileStream newFile;

      public NoDisposeMethod()
      {
         newFile = new FileStream(@"c:\temp.txt", FileMode.Open);
      }
   }

   //이 클래스 구현은 규칙을 만족한다.
   public class HasDisposeMethod: IDisposable
   {
      FileStream newFile;

      public HasDisposeMethod()
      {
         newFile = new FileStream(@"c:\temp.txt", FileMode.Open);
      }

      public void Dispose()
      {
         newFile.Close();
      }
   }
}


[VB.NET]
Imports System
Imports System.IO
 
Namespace DesignLibrary

  '규칙을 위반한 예제이다
   Public Class NoDisposeMethod
   
      Dim newFile As FileStream

      Sub New()
         newFile = New FileStream("c:\temp.txt", FileMode.Open)
      End Sub

   End Class

  '규칙을 만족하는 구현이다.
   Public Class HasDisposeMethod
      Implements IDisposable
   
      Dim newFile As FileStream

      Sub New()
         newFile = New FileStream("c:\temp.txt", FileMode.Open)
      End Sub

      Sub Dispose() Implements IDisposable.Dispose
         newFile.Close()
      End Sub

   End Class

End Namespace


관련 규칙
삭제가능한 필드는 삭제되어야 한다.
삭제가능한 형식은 finalizer를 선언해야 한다.
Dispose 메서드는 베이스 클래스의 Dispose 메서드를 호출해야 한다.
native 리소스를 가지고 있는 형식은 삭제가능해야 한다.


원문주소: http://www.gotdotnet.com/team/fxcop/Docs/Rules/Design/TypesThatOwnDisposableFieldsShouldBeDisposable.html

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

[번역]디자인규칙3. 제네릭 목록을 노출하지 마십시오  (6) 2007.02.21
[번역]디자인규칙1. 정적 멤버를 제네릭 형식으로 선언하지 마십시오  (0) 2006.10.16
[Article]VSTS 코드 분석 디자인 규칙  (0) 2006.10.14
Posted by kkongchi
코드분석 규칙/디자인 규칙2006. 10. 16. 22:48

[번역]디자인규칙1. 정적 멤버를 제네릭 형식으로 선언하지 마십시오

규칙 클래스 이름: DoNotDeclareStaticMembersOnGenericTypes
규칙 ID: CA1000
분류: 디자인 규칙
메시지 레벨: 에러
확실도: 95% (확실도는 코드 분석에서 이 규칙에 위반 사례를 찾는 것에 대한 것이다. 즉, 이 규칙에 위반되었다는 것에 대해서 95%의 확실도로 보증할 수 있다는 것이다)

원인: 외부에 노출된 제네릭 타입이 정적(static, vb.net에서는 shared) 멤버를 가질 때 이 규칙에 위반된다.

규칙 설명
제네릭 타입의 정적 멤버를 호출할 때는 형식 매개 변수를 반드시 명시되어야 한다. Inference(유추 - 컴파일러가 인자를 통해서 형식 인자를 자동으로 알아내는 것을 말한다)를 지원하지 않는 제네릭 인스턴스 멤버를 호출할 때도, 형식 매개 변수의 형식이 반드시 명시되어야 한다. 이 두 케이스의 형식 매개 변수를 지정하는 구문은 다르지만, 아래 예에서 보듯이 혼동되기 쉽다.

[C#]

// Static method in a generic t.
GenericType<int>.StaticMethod();

// Generic instance method that does not support inference.
someObject.GenericMethod<int>();

[VB]
'Shared method in a generic type.
GenericType(Of Integer).SharedMethod()

'Generic instance method that does not support inference.
someObject.GenericMethod(Of Integer)()

위의 두 가지 코딩 방법은 멤버가 호출될 때 형식 매개 변수를 특정한 형식으로 정하지 않기 위해서 피해야 한다. 위와 같은 코딩을 하면 결과적으로 제네릭 타입을 쓰지 않은 것과 차이가 없다. 이 위반 사항을 고치기 위해서는, 정적 멤버를 없애고 그것을 인스턴스 멤버로 바꾸어야 한다.

관련 규칙
제네릭 타입에 과도한 파라미터를 피한다.
컬렉션 타입은 제네릭 인터페이스를 구현해야 한다
제네릭 리스트를 public으로 노출하지 않는다
제네릭 타입을 중첩하지 않는다

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

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

[번역]디자인규칙3. 제네릭 목록을 노출하지 마십시오  (6) 2007.02.21
[번역]디자인규칙2. 삭제가능한 필드가 있는 형식은 삭제가능해야 합니다  (0) 2006.10.21
[Article]VSTS 코드 분석 디자인 규칙  (0) 2006.10.14
Posted by kkongchi
코드분석 규칙/디자인 규칙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
코드분석 규칙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

티스토리툴바