나의 C/C++ 프로그램 코딩 스타일 - 2009/02/09 16:49
나의 C/C++ 코딩 스타일에 대해서는 1999년도 즈음에 정리 하였던 것 같다.
두가지 정도의 코딩 스타일 참조 문서를 기반으로 나만의 프리스타일을 만들었었다.
1. 모든 소스 코드는 Introductory와 Comment를 포함해서 작성 되어야 한다.
=> 필요성에 대해서는 두 말 하면 잔소리이기 때문에 생략
2. #include상에 상대경로방식을 이용하여서는 안된다.
=> 복잡한 상대경로방식(예, #include "portable/class/include/index.h" )은 코드 이식이나 관리에 불편함. 해당 헤더 파일의 위치를 컴파일 옵션인 -I 을 이용하여 코딩(예, #include "index.h" ) 하는 것이 바람직.
3. 모든 global class, enum, typedef, function, const, variable은 라이브러리 고유의 Prefix를 적용하여야 한다.
=> 예를 들어 PCI 클래스 류의 변수/함수일 경우 enumpciFailure, lwpciConnected, pci_init(), pci_open(), pci_read() 등으로 고유의 접두어(예, pci)을 삽입하여 선언한다.
4. Variable, const, function은 소문자(lowercase)로 시작되어야 한다.
=> 자기만의 규칙으로 사용하면 무방
5. Abstract data type, structure, typedef, enum은 대문자(uppercase)로 시작되어야 한다.
=> 예를 들면 typedef enum{ YELLOW, BLUE, RED, CYAN, PURPLE, MAX_COL }EnumCOLOR
6. 하나의 word 이상으로 이루어진 데이터 타입의 각 워드는 대문자(uppercase)로 시작되어야 한다.
=> 예를 들면 comRegisteredName[], resAddressQueue
7. 해당 prefix 이후에 첫번째 문자는 대문자(upper case)로 시작한다.
=> 예를 들면 enumpciFailure, lwpciConnected
8. 효과적인 코드를 작성 하기 위하여 #define 대신 inline 함수를 이용한다.
=> 컴파일시 전달인자나 리턴값의 유형체크를 해주는 inline 의 사용이 보다 바람직하다.
9. constant 값은 #define 대신 const 혹은 enum을 이용한다.
=> 특별할 이유는 없고 다만 소정의 메모리를 차지하는 단점이 있기는 하지만 const나 enum 을 사용하면 툴(ICE)을 이용한 디버깅
시에 그의 값을 쉽게 확인 가능하게 함.
10. 코드 상에 숫자 상수를 이용 하지 않고 symbol(#define)를 이용한다.
=> 하드코딩은 항상 소프트웨어 코딩/디버깅의 적(敵)이다.
11. 가능한 대입(assignment) 대신에 초기화(initialization)를 이용한다.
=> 왜 이렇게 하였는지 지금 생각해 보니, 기억이 안난다.
12. 포인터에 NULL을 비교하거나, 대입 할시 NULL 대신에 ‘0’을 이용한다.
=> 기계마다 표현 방식에 차이가 있는 NULL의 사용을 피한다.
13. 결코 const를 unconst로 변환하여 사용하지 않는다.
=> 임베디드에서는 그 사용 하는 것을 피해야 한다.
14. 하나의 include 파일은 하나의 클래스 정의 이상을 포함 하지 않아야 한다.
=> C++ 클래스 선언시 클래스 정의 하나당 한 헤더 파일을 사용하는 것을 추천한다는 의미임.
15. 코멘트는 가급적이면 ‘// ‘ 을 이용한다.
=> C 코드에서도 사용 가능한 주석 표기법임. /* */ 표기법에 비해 단순함. 추천!
16. Large scope 에서 사용하는 변수는 긴이름(long name)을 가져야 한다.
=> 전역 변수와 지역 변수가 혼재되어 있을 경우 이런 규칙을 가지고 있다면 서로 분별할때 유리할 것임.
17. 데이터 타입의 이름을 지을적에는 사용 하는 기능에 가장 합당한 이름을 적용 해야 한다.
=> 데이터 변수의 이름을 정하는 것도 중요한 일의 하나로 생각하고 반드시 신중하게 정의 할것.
18. 한 라인의 문자열은 ‘80’ 컬럼(column)으로 적용한다.
=> 보기 좋은 길이임.
19. 많은 파라미터를 가지는 함수(function)를 작성 하지 않는다.
=> 효율면으로도 많은 파라미터는 바람직 하지 않음. 전달인자는 많아야 4개를 넘지 않도록 작성하는 것이 필요함.
그 이상의 전달 인자는 구조체로 만들어 그의 포인터 전달 방법을 사용 하는 것이 좋다.
20. 함수 포인터를 선언 할시 프로그램 문법을 단순하게 하기 위하여 typedef를 이용한다.
=> typedef 는 적극적으로 많이 사용 하는 것이 좋음.
21. 절대로 음(negative)의 값을 가질수 없는 변수는 unsigned를 사용한다.
=> 통상 무시하기 쉽지만 치명적인 잘못된 사용은 추후 많은 경제 비용과 육체적(?)인 노동의 댓가를 지불하게 한다. 변수의 선언시 부터 데이터 형의 부호 있음과 부호 없음을 명확히 개념을 부여 하는 습관이 중요함.
22. test가 포인터일 경우에 if(test)나 if(!test)방식보다는 if(test = = 0)나 if(test != 0)을 이용한다.
=> 코딩시 오류를 방지해 주고 눈으로 보기에도 또 명확해서 후자가 바람직 함.
이와 관련 하여 if(test == 0) 보다는 if(0 == test) 의 습관이 바람직 함. 왜냐하면 전자의 기입법은 사용자의 실수로 if(test = 0)으로 오타를 하여도 컴파일러는 이러한 실수를 경고하지 않을 것임. 반면 후자로 코딩하는 습관은 이러한 코딩 실수를 만회하는 기회를 제공 해 줄 수 있슴. 실수로 if(0 = test)로 '='을 하나 빼먹어도 컴파일러는 이러한 오류를 알려줄 것임.
23. 항상 int와 long의 데이터 타입의 바이트 사이즈가 같을 것 이라고 가정하지 말라.
=> 크로스 플랫폼 코딩시 항상 생각 해야 할 주제임. 아무리 강조 해도 지나치지 않음.
24. 8비트 ASCII가 사용될 경우에 char를 unsigned타입으로 정의하라.
=> 기억이 안남.
-홍익컴닷컴-
http://www.hongikcom.com
♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->
=> 필요성에 대해서는 두 말 하면 잔소리이기 때문에 생략
2. #include상에 상대경로방식을 이용하여서는 안된다.
=> 복잡한 상대경로방식(예, #include "portable/class/include/index.h" )은 코드 이식이나 관리에 불편함. 해당 헤더 파일의 위치를 컴파일 옵션인 -I 을 이용하여 코딩(예, #include "index.h" ) 하는 것이 바람직.
3. 모든 global class, enum, typedef, function, const, variable은 라이브러리 고유의 Prefix를 적용하여야 한다.
=> 예를 들어 PCI 클래스 류의 변수/함수일 경우 enumpciFailure, lwpciConnected, pci_init(), pci_open(), pci_read() 등으로 고유의 접두어(예, pci)을 삽입하여 선언한다.
4. Variable, const, function은 소문자(lowercase)로 시작되어야 한다.
=> 자기만의 규칙으로 사용하면 무방
5. Abstract data type, structure, typedef, enum은 대문자(uppercase)로 시작되어야 한다.
=> 예를 들면 typedef enum{ YELLOW, BLUE, RED, CYAN, PURPLE, MAX_COL }EnumCOLOR
6. 하나의 word 이상으로 이루어진 데이터 타입의 각 워드는 대문자(uppercase)로 시작되어야 한다.
=> 예를 들면 comRegisteredName[], resAddressQueue
7. 해당 prefix 이후에 첫번째 문자는 대문자(upper case)로 시작한다.
=> 예를 들면 enumpciFailure, lwpciConnected
8. 효과적인 코드를 작성 하기 위하여 #define 대신 inline 함수를 이용한다.
=> 컴파일시 전달인자나 리턴값의 유형체크를 해주는 inline 의 사용이 보다 바람직하다.
9. constant 값은 #define 대신 const 혹은 enum을 이용한다.
=> 특별할 이유는 없고 다만 소정의 메모리를 차지하는 단점이 있기는 하지만 const나 enum 을 사용하면 툴(ICE)을 이용한 디버깅
시에 그의 값을 쉽게 확인 가능하게 함.
10. 코드 상에 숫자 상수를 이용 하지 않고 symbol(#define)를 이용한다.
=> 하드코딩은 항상 소프트웨어 코딩/디버깅의 적(敵)이다.
11. 가능한 대입(assignment) 대신에 초기화(initialization)를 이용한다.
=> 왜 이렇게 하였는지 지금 생각해 보니, 기억이 안난다.
12. 포인터에 NULL을 비교하거나, 대입 할시 NULL 대신에 ‘0’을 이용한다.
=> 기계마다 표현 방식에 차이가 있는 NULL의 사용을 피한다.
13. 결코 const를 unconst로 변환하여 사용하지 않는다.
=> 임베디드에서는 그 사용 하는 것을 피해야 한다.
14. 하나의 include 파일은 하나의 클래스 정의 이상을 포함 하지 않아야 한다.
=> C++ 클래스 선언시 클래스 정의 하나당 한 헤더 파일을 사용하는 것을 추천한다는 의미임.
15. 코멘트는 가급적이면 ‘// ‘ 을 이용한다.
=> C 코드에서도 사용 가능한 주석 표기법임. /* */ 표기법에 비해 단순함. 추천!
16. Large scope 에서 사용하는 변수는 긴이름(long name)을 가져야 한다.
=> 전역 변수와 지역 변수가 혼재되어 있을 경우 이런 규칙을 가지고 있다면 서로 분별할때 유리할 것임.
17. 데이터 타입의 이름을 지을적에는 사용 하는 기능에 가장 합당한 이름을 적용 해야 한다.
=> 데이터 변수의 이름을 정하는 것도 중요한 일의 하나로 생각하고 반드시 신중하게 정의 할것.
18. 한 라인의 문자열은 ‘80’ 컬럼(column)으로 적용한다.
=> 보기 좋은 길이임.
19. 많은 파라미터를 가지는 함수(function)를 작성 하지 않는다.
=> 효율면으로도 많은 파라미터는 바람직 하지 않음. 전달인자는 많아야 4개를 넘지 않도록 작성하는 것이 필요함.
그 이상의 전달 인자는 구조체로 만들어 그의 포인터 전달 방법을 사용 하는 것이 좋다.
20. 함수 포인터를 선언 할시 프로그램 문법을 단순하게 하기 위하여 typedef를 이용한다.
=> typedef 는 적극적으로 많이 사용 하는 것이 좋음.
21. 절대로 음(negative)의 값을 가질수 없는 변수는 unsigned를 사용한다.
=> 통상 무시하기 쉽지만 치명적인 잘못된 사용은 추후 많은 경제 비용과 육체적(?)인 노동의 댓가를 지불하게 한다. 변수의 선언시 부터 데이터 형의 부호 있음과 부호 없음을 명확히 개념을 부여 하는 습관이 중요함.
22. test가 포인터일 경우에 if(test)나 if(!test)방식보다는 if(test = = 0)나 if(test != 0)을 이용한다.
=> 코딩시 오류를 방지해 주고 눈으로 보기에도 또 명확해서 후자가 바람직 함.
이와 관련 하여 if(test == 0) 보다는 if(0 == test) 의 습관이 바람직 함. 왜냐하면 전자의 기입법은 사용자의 실수로 if(test = 0)으로 오타를 하여도 컴파일러는 이러한 실수를 경고하지 않을 것임. 반면 후자로 코딩하는 습관은 이러한 코딩 실수를 만회하는 기회를 제공 해 줄 수 있슴. 실수로 if(0 = test)로 '='을 하나 빼먹어도 컴파일러는 이러한 오류를 알려줄 것임.
23. 항상 int와 long의 데이터 타입의 바이트 사이즈가 같을 것 이라고 가정하지 말라.
=> 크로스 플랫폼 코딩시 항상 생각 해야 할 주제임. 아무리 강조 해도 지나치지 않음.
24. 8비트 ASCII가 사용될 경우에 char를 unsigned타입으로 정의하라.
=> 기억이 안남.
-홍익컴닷컴-
http://www.hongikcom.com
♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->
Trackback Address :: http://www.hongikcom.com/trackback/11
