좋은 코딩 습관 [펌]

#독학자라면

 

프로그래밍을 독학한 사람으로서,

내 멋대로 짠 코드들을 보면 한숨부터 나옵니다(나만 그런가?).

절대 처음부터 이 스크립트를 빌드하지 않은 남들은 이해할 수 없을 것이라는...

나름 효율성이나 가시성을 좀 높이려는 시도를 하긴 하지만,

그래도 같이 작업하는 동료를 두고 하는 게 아니기 때문에

급한 마음에 맘대로 변수명을 설정하거나 하네요.

 

내 인생에서 프로그래밍이 머큐리 프로젝트 하나에만 있을 게 아니기 때문에,

지금이라도 아래 글을 보면서 습관을 고쳐볼까 합니다.

 

---

이 문서는 ‘C# 코딩 표준과 좋은 프로그래밍 습관’이라는 닷넷스파이더팀에서 작성한 문건을 토대로 작성되었습니다.

 

오늘은  유지 보수에 좋고, 신뢰받는 코드를 개발하기 위한 방법들을 소개해 드리겠습니다. 'C# 코딩 표준과 좋은 프로그래밍 습관'의 저자는 이렇게 말합니다. '많은 프로그래머들이 작동되는 코드(Working code)를 만들지만, 좋은 코드(Good code)’는 아니다.'

 

그렇다면 보편적으로 생각하는 좋은 코드란 무엇일까요?

필자가 생각하는 좋은 코드와 저자의 관점에서의 좋은 코드를 비교해 봤습니다.

필자 의견	C# 코딩 표준과 좋은 프로그래밍 습관 저자 의견
모듈화가 잘 됐다	신뢰할 수 있다 (Reliable)
유지보수가 쉽다	관리하기 좋다 (Maintainable)
모두가 이해할 수 있다	효율적이다 (Efficient)

 

글은 달라도 의미는 비슷할 것이라고 생각합니다. 하지만 대부분의 개발자들은 프로젝트 기간, 성능 등 다양한 이유로 코드가 점점 복잡해지고 좋은 코드가 되지 못하는 경우가 많습니다. 그렇기 때문에 좋은 코드를 만들기 위해서는 표준을 만드는 것이 중요합니다.

팀 내에서 표준을 만드는 방법은 무엇이 있을까요?

저자가 말하는 가장 좋은 방법은 ‘회의’를 통해 표준을 마련하는 것이라고 합니다.  회의를 통해서 팀원들과 표준을 마련한 뒤 모두가 동의한 상태에서 개발이 시작되어야 합니다. 개발이 시작되면 코드 리뷰를 통해서 서로가 표준을 잘 지키고 있는지 확인합니다.

코드 리뷰에는 다음의 3개의 리뷰가 요구됩니다.

1. Peer review : 다른 개발팀의 코드를 분석하고 표준안이 지켜지는지 확인, 일부 단위 테스트 실시(모든 파일)
2. Architect review : 팀의 설계자가 핵심 모듈에 대해 설계를 충실히 지키고 있는지, 프로젝트를 장기화시킬만한 ‘큰’ 문제는 없는지 분석
3. Group review : 몇 개의 파일만 선택하여 일주일에 한 번씩 수행한다. 30분 전에 모든 팀원에게 코드를 나눠주고 의견을 내어 오도록 한다.

이제 본격적으로 저자가 가이드 해주는 표준에 대해 알아보도록 하겠습니다.

 

명명 규칙과 표준

1. 1. 클래스명 : 파스칼 케이싱
   2. 메소드명 : 파스칼 케이싱
   3. 메소드인자, 변수 : 캐멀 케이싱
   

1. 4. 인터페이스 : ‘I’+파스칼 케이싱 (Ex) IEntity
   5. 변수명에 대해 헝가리안 표기법을 사용하지 말라. (Ex) string m_sName, int nAge
   6. 변수에 의미를 부여하라. (축약하지 말라.) (Ex) string address, int salary
   7. i, n, s와 같은 한 글자로 이루어진 변수를 사용하지 말라. (Ex) for (int i = 0; i < 10; i++) {…}
   8. 지역변수에 언더 스코어 문자를 사용하지 말라.
   9. 멤버 변수는 언더 스코어로 시작하여 지역변수와 구분하라.
   10. 변수명을 예약어와 유사하게 사용하지 말라.
   11. 불린 값을 리턴하는 메서드, 프로퍼티, 변수는 ‘is’ 접두어를 붙여라.
   12. 네임스페이스는 아래와 같은 규칙으로 작성하라 <회사명>.<제품명>.<상위 모듈>.<하위 모듈>
   13. UI 구성요소에 대해서 알맞은 접두어를 붙여서 다른 변수와 구분하라.
   14. 파일명은 해당 클래스명으로 사용한다.
   15. 파일명은 파스칼 케이싱을 사용한다.
   
   

들여 쓰기, 공백

1. 공백 말고 TAB으로 들여쓰기 한다. (크기 4)
2. 주석은 코드와 같은 수준의 들여 쓰기에서 작성한다.
3. 중괄호는 감싸고 있는 밖의 코드와 동일한 레벨에서 작성한다.
4. 논리적으로 로직이 구분되는 곳에는 빈 줄을 삽입한다.
5. 클래스 내의 메서드 사이의 구분은 빈 줄 하나로만 하라.
6. 중괄호는 한 줄을 단독으로 사용하라. (좋은 예, 안 좋은 예)

7. 공백을 사용하는 명령이나 괄호 등의 구분에는 한 칸의 공백만 사용하라.
8. #region 을 활용하여 관련 있는 코드는 묶어 두어라.
9. Private 멤버 변수, 메서드는 파일의 맨 위에 두고, 그 바로 아래 public 멤버를 작성하라.

좋은 프로그래밍 습관

 

1. 메서드는 1~25줄 정도로 짧게 작성하라. 길다면 리팩토링을 통해 분리하라.
2. 메서드명은 수행하는 이름을 명확히 하여 작성하라. 이렇게 하면 주석이 필요 없다.
3. 아무리 작은 단위의 작업을 하는 메서드라 할지라도 하나의 메서드는 하나의 작업만 하라.
4. System 네임스페이스에 정의된 자료형 대신 C#에서 사용하도록 Alias 된 자료형을 사용하라.

5. 언제나 예상치 못한 값에 대비하라.

6. 숫자 값을 하드코딩하지 말라. (대신 readonly, const 사용)
7. 문자열을 하드코딩하지 말라. (대신 리소스 파일을 사용)
8. 문자열을 비교할 때는 대(소) 문자로 변경한 뒤 수행하라.
9. “” 대신에 string.Empty를 사용하라.
10. 멤버 변수의 사용을 자제하라. 여러 메서드에서 사용해야 될 필요가 있는 변수는 메서드의 인자로 전달하는 구조를 사용하라.
11. 열거형 대신 숫자나 문자열을 사용하지 말라.
12. 멤버 변수를 public이나 protected로 선언하지 말라. private로 선언한 후에 public, protected 프로퍼티로 노출하라.
13. 이벤트 핸들러에서 해당 이벤트의 작업을 수행하지 말고, 별도의 메서드를 호출하여 처리하라.

14. 클릭과 같은 이벤트 핸들러에서 호출하는 별도의 작업메서드를 직접 호출하지 말라. 필요하다면 해당 이벤트 핸들러를 호출하라.

15. 로컬 경로나 드라이브 명을 하드코딩하지 말라.

16. 실행 경로가 특정한 곳(C:\)일 것이라는 가정하에 코딩하지 말라

17. 어플리케이션이 시작되면 '셀프 체크'를 수행하여 필요한 파일들이 있는지 등을 확인하고 문제가 있다면 사용자에게 친절한 오류메시지를 보여주어라.

18. 환경설정 파일이 없다면 기본 설정의 파일을 만들어 주어라.

19. 환경설정 파일 등에서 문제가 있는 값이 있다면 문제가 있는 항목과 함께, 어떠한 값이 올바른 값인지를 보여주어라.

20. 오류 메시지는 사용자로 하여금 문제 해결에 도움을 주는 단서가 된다. '오류가 발생하였습니다.', '어플리케이션 오류' 와 같은 메시지 대신 '데이터베이스 접속에 실패하였습니다. 로그인 ID와 비밀번호를 확인하여 주십시오.' 와 같은 메시지를 보여주어라.

21. 오류 메시지를 보여줄 때 해결 방법도 제시하라.

22. 사용자에게는 짧지만 친절한 메시지를 보여주되, 실제로는 알 수 있는 모든 정보를 기록한 로그파일을 만들어 두어라. 이는 나중에 디버깅할 때 도움이 된다.

23. 하나의 파일에는 하나의 클래스만 작성하라.

24. Visual Studio는 코딩에 대한 템플릿을 작성할 수 있는 기능을 제공해준다. 이를 활용하라.

25. 너무 긴 소스를 가지는 클래스를 작성하지 말라. 1000라인 이상이 된다면, 이는 리팩토링 대상으로 좋다. 둘 이상의 클래스로 분할하라.

26. public 메서드나 프러퍼티는 정말 꼭 필요한 곳에서만 사용하고, 만약 동일 어셈블리 내에서만 사용된다면 internal 을 사용하라.

27. 메서드에 너무 많은 인자를 넘기지 말라. 4~5개 이상의 인자가 전달되는 메서드가 있다면, 클래스 혹은 메서드의 구조를 재조정하라.

28. 컬렉션을 리턴 값으로 가지는 메서드가 있다면, 값이 없는 경우에 null 을 리턴하지 말고 빈 컬렉션을 넘겨줘라. 리턴 받은 리턴 값을 체크할 때 null 체크를 하지 않고 count만 체크하면 되며, 설사 잊어먹었다 하더라도 null 참조 예외가 발생하지 않는다.

29. 버전, 어셈블리에 대한 설명, 회사명, 저작권 정보 등을 AssemblyInfo 파일에 작성해 두어라.

30. 프로젝트에 사용하는 파일들은 폴더를 통해 논리적으로 분리하라. 2단계의 계층 구조로 분리하는데, 최상위 폴더는 10개 이하의 폴더를 가지고, 그 하위 폴더는 5개 이하의 폴더를 가지도록 분리하다. 폴더가 너무 많아서 이러한 구조로 분리할 수 없다면, 어셈블리를 별도로 분리하여 파일을 나누도록 하라.

31. 좋은 로그 클래스를 작성하라. 로그 클래스는 설정하기에 따라 오류메시지만을 기록할 수도 있고, 오류 시의 경고나 스택 정보와 같은 세부정보를 기록할 수도 있다. 또한 로그 방법을 파일, SQL 서버, 윈도우즈 로그 이벤트, 이메일 등으로 작성할 수 있도록 하여 어플리케이션에 맞추어 사용하라. 이는 나중에 오류 수정에 도움이 될 것이다.

32. 데이터 베이스를 소켓, 파일 스트림 등을 통해 열었을 때는 닫는 로직을 finally에 두어라. 이는 열고난 이후 닫기 전에 오류 발생하여도 마지막에는 닫을 수 있도록 해준다.

33. 변수 선언은 해당 변수가 최초로 사용되는 곳에 선언하도록 하라. 한 줄에 하나의 변수만 선언하라..

34. 루프 문에서 문자열 처리를 해야 할 때는 String 클래스 대신에 StringBuilder 클래스를 사용하라. String 객체는 동작 방식이 미묘하여 문자열에 대해 새로운 작업(+, remove 등)이 일어날 때 이전 객체는 파기하고 항상 새로운 객체를 생성하도록 되어있다. 이러한 작업은 비용이 많이 든다.

이 외에도 아키텍처, ASP.NET, 주석, 예외 처리에 대한 내용이 있지만 그것은 직접 찾아보길 권장합니다. 이 모든 표준을 기억하고 실제로 적용하기엔 어려움이 따를 것으로 보입니다. 그만큼 시간도 투자해야 하고 실무자 모두가 이 표준을 지키려고 노력을 해야만 가능할 것입니다.

 

[출처] C# 코딩 표준과 좋은 프로그래밍 습관 | 작성자 슈어소프트테크