프로그래머라면 "코딩 스타일" 에 대한 고민을 하고 있을 것이라고 생각합니다. 누구나 자신의 코드가 읽기 좋은 코드이기를 바랄 테니까요. 저도 항상 좋은 코딩 스타일이 무엇인지 고민했지만, 이렇다 할 답을 찾지는 못했습니다. 사실 사람마다 편하다고 느끼는 스타일이 다르다 보니, 여러 의견을 들을 수록 "과연 절대적으로 좋은 코딩 스타일이라는 것이 있는가?" 하는 생각도 들곤 했습니다.


이러한 고민을 풀고자 하는 노력의 일환으로 Style Cop 를 개인적으로 진행하는 C# 프로젝트에 적용 해 보았습니다. Style Cop 는 Microsoft 에서 제시하는 코딩 스타일을 제대로 따르는 지를 체크하는 정적 코드 분석기입니다. C# 을 다루는 분 중 Style Cop 를 몰랐던 분이 있다면 한 번 사용해 보는 것도 좋을 것 같습니다.


사용 방법은 아주 간단합니다. http://stylecop.codeplex.com 에서 프로그램을 다운 받아 설치 한 후, Visual studio 를 열어서 코딩 스타일 체크를 실행 할 프로젝트를 우클릭하면 아래와 같은 메뉴가 나타납니다.



"StyleCop Settings" 메뉴를 이용하면 적용 할 코딩 스타일 가이드를 선별 할 수 있습니다. "Run StyleCop" 를 실행하면 코딩 스타일 가이드를 잘 지키고 있는 지 체크한 결과가 오류 목록의 "경고" 에 나타납니다. 또는, 상단 도구 메뉴-"Run StyleCop" 를 이용하거나 단축키 Ctrl+Shift+Y 를 눌러서 실행 할 수도 있습니다.



이렇게 얻은 결과 중에서는 불필요하거나 너무 까탈스러운(?) 코딩 가이드라고 생각해서 제외 한 규칙도 있습니다만, 그동안 제가 잘못된 습관을 들여 왔다는 것을 깨닫게 해 준 고마운 규정들도 꽤 있었습니다. 아래에서는 제게 도움이 된 코딩 스타일 가이드를 정리 해 보았습니다.


[SA1027] Tabs Must Not Be Used

tab 을 사용하지 마세요.


역시 tab 보다는 space 인가 봅니다. 사실 tab 이 사용하기는 편합니다만, tab 은 프로그램에 따라 또는 사용자의 설정에 따라 공백 크기를 다르게 보여준다는 단점이 있습니다. Visual Studio 에서는 tab 간격을 작게 설정 해 두었는데 다른 편집기에서 열어 보니 간격이 너무 넓어서 당황한다거나 하는 일이 생기는 것이지요. space 보다 tab 을 선호하는 이유는 space 를 여러 번 치기가 번거로워서일텐데요, 요즘은 똑똑한 IDE 들이 자동으로 들여쓰기를 해 주니 tab 대신 space 를 사용하는 불편함도 크지 않은 것 같습니다.

하지만 아쉽게도, 제가 다니는 회사 표준은 tab 입니다... 허허.


[SA1101] Prefix Local Calls With This, [SA1126] Prefix Calls Correctly

호출 시에는 앞에 "this.", "base." 또는 "클래스 이름." 를 붙이세요.

"이런 규칙도 있네..?" 싶었던 스타일 가이드입니다.

지키는 사람이 많은지 궁금한 마음에 유명한 C# 프로젝트들(NuGet, nunit, gitextension)을 살펴 보았는데요, 딱히 잘 지켜지는 규칙은 아닌 듯 합니다^^;;

해당 멤버가 base 에 속하는 지 아니면 this 에 속하는 지 헷갈릴 때, overloading 된 현재 객체의 메서드를 가리킬 때, 또는 VS intelliSense 의 도움을 받고 싶을 때 도움을 받을 만한 규칙인 것 같습니다.

신기한(?) 마음에 목록에 추가 해 보았습니다.


[SA1122] Use String Empty For Empty Strings

"" 대신 string.Empty 를 사용하세요.

string.Empty 가 더 명시적입니다. 만약 프로젝트 개발자 모두가 이 규칙을 따른다면, "a" 를 쓰려고 했는데 오타로 "" 를 쓴 결과로 런타임 에러가 발생하는 일은 막을 수 있을 것입니다.


[SA1200-SA1215] Order of items in classes

클래스 내의 요소들은 순서에 따라 나열하세요.

사실 제가 코딩 스타일을 찾아보기 시작한 이유는 이것 때문입니다. 클래스 내의 많은 요소들을 어떻게 배치해야 할 지 기준이 잘 서지 않았거든요. 기능 별로 묶어서 나열하는 방식은 클래스가 커지면 제 역할을 하지 못하는 듯 싶습니다.

StyleCop 에서 제시하는 방식대로 요소들을 나열한 후, "정의 부분만 보이기(Ctrl+M, Ctrl+O)" 기능을 이용하면 클래스의 요소들을 한 눈에 파악하기가 쉬워 지는 느낌입니다. 접힌 내용을 다시 펼쳐보고 싶을 때에는 "전체 개요 표시/숨기기(Ctrl+M, Ctrl+L)" 기능을 이용하면 됩니다.

알파벳 순서로 개체의 요소들을 보고 싶을 때에는 "개체 브라우저(Ctrl+Alt+J)" 를 이용하고,

개별 참조를 따라가고 싶을 때에는 Visual Studio 의 "정의로 이동(F12)" 기능을 이용하는 것이 효율적인 것 같습니다.


[SA1305] Field Names Must Not Use Hungarian Notation

헝가리안 표기법을 사용하지 마세요.

아무래도 헝가리안 표기법을 사용하던 시대는 지나간 듯 합니다. StyleCop 의 문서에서는 변수 이름을 지을 때 변수의 type 이 아닌 변수의 목적을 나타내라고 권하고 있습니다. 마우스를 hovering 만 하면 Type 을 보여 주니까요. 키보드에서 손을 떼기 싫다면? "Ctrl+Space" 또는 "Ctrl+K, Ctrl+I" 를 누르면 됩니다.


[SA1503] Curly Brackets Must Not Be Omitted

if 문 내에 명령문이 하나일 때에도 {} 를 생략하지 마세요.

개인적으로는 if 문 내의 명령문이 하나일 경우 {} 가 없는 것이 더 깔끔하다고 생각 했습니다. 그런데 기억을 더듬어 보면, 이로 인해 오류가 발생한 적이 간간이 있었던 것 같습니다. 특히 다른 사람이 사용한 중첩 if 문 내에 명령문을 추가하는 경우가 위험하지요.

그래서 앞으로는 {} 를 생략하지 않으려 합니다.


[SA1600] Elements Must Be Documented

주석을 쓰세요.

사실 환경설정에서 체크를 해제했다가, 설정했다가를 반복했네요...하하;;

이 규칙은 반성과 동경의 의미로 남겨둡니다. 주석을 써야 하는 모든 자리에 정말로 주석을 남길 수 있는 날을 만날 수 있을 지...