'프로그래머'에 해당되는 글 3건
C Programming FAQs - 2009/02/09 16:59
cfaq.zip첨부된 문서
'C Programming FAQs.pdf' 는 원문 'cfaqs-ko.pdf' 에서 제가 원하는 내용만을 발췌한 것임을
알려 드립니다.
posted by 가일
♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->
Trackback Address :: http://www.hongikcom.com/trackback/17
나의 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
[펌]임인건의 프로그래머 10계명 - 2009/02/09 16:03
도스시절 한글라이브러리인 한라 프로를 만드신 임인건님께서 쓰신 글입니다.
프로그래밍을 공부하시는 분들께 큰 도움이 되리라 생각합니다.
시작부터 경지에 이르기까지…
1. 정보를 모음에 소홀히 하지 말고 설명서를 읽음에 게을리 하지 말지어
다. 오늘 필요 없는 정보는 내일 필요하리라. 가장 가치 있고도 저렴한
지식은 책 속에 있느니라. 서점과 동료의 책꽂이에 무엇이 꽂혀 있는지
때때로 살피어라. 무심코 흘렸던 종이 한 장이 너의 근심을 풀어 주었
으리라. 설명서는 충분히, 꼼꼼히 읽을지어다. 모든 의문은 설명서를
안 보는 데서 생기니라. 그렇더라도 모두 다 읽을 필요는 없느니라.
2. 너의 PC가 안전하다고 믿지 말지어다. 5분 후에 정전이 되고 내일 너의
하드가 맛이 가리라. 그러하니 너의 소중한 소스 코드는 정기적으로 여
러 군데에 단계별로 백업해 두어라.
3. 변하는 수를 다룰 때에는 늘 조심할지어다. 정수가 절대로 그 한계를
넘지 않으리라 가정하는 것은 어리석음이라. 127, -128, 255, 32767,
-32768, 65535, 이 숫자들을 너의 골수에 새기어라. 0.0은 0이 아니니
실수는 원래부터 결코 정밀하지 않느니라. 부호 없는 것과 있는 것을
어울리거나 정수끼리 나눌 때에는 늘 조심하여라.
4. 무슨 일을 반복시킬 때에는 처음과 끝에 유의할지어다. 너의 컴퓨터는
1보다는 0을 좋아 하니라. 배열의 첨자가 그 범위를 넘지 않을지 손 댈
때마다 따져 보아라. 수식에 1을 더하거나 뺄 때에는 늘 긴장하라. 너
의 프로그램은 단지 한 번 덜해서 틀리고 한 번 더해서 다운되느니라.
5. 항상 모든 경우의 수를 고려하고 섣불리 생략하지 말지어다. 절대로 일
어나지 않을 일은 반드시 일어나고, 가장 드물게 일어날 일이 가장 너
를괴롭히리라. 그러하니 언제나 논리에 구멍이 없는지 꼼꼼히 따져 보
고, if를 쓸 때에는 else부터 생각하라.
6. 함수 안에서 매개 변수값은 결코 믿지 말지어다. 지금 그 매개 변수가
결코 가질 수 없다는 값을 내일부터는 가지리라. 그러하니 매개 변수값
이 올바름을 항상 검사할지어다. 그렇더라도 처리 속도가 문제가 되는
경우는 예외이니라.
7. 오류를 알려 주는 기능은 있는 대로 모두 활용할지어다. 컴파일러의 경
고는 모두 켜 두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결
과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든
메모리 할당은 조만간 실패할 것이라.
8. 한 번의 수정과 재컴파일만으로 연관된 모든 것이 저절로, 강제로 바뀌
도록 할지어다. 어떠한 것을 수정했을 때에 연관된 것이 따라서 변하지
않는다면 그것이 곧 벌레이니라. 컴파일러로 하여금 매개 변수 리스트
를 완전하게 검사하도록 하고, 언젠가 손대야 하거나 따라서 변해야 하
는 수치는 전부 매크로로 치환하며, 형 정의를 적극 활용하여라.
9. 사용자가 알아서 잘 써 주리라고 희망하지 말지어다. 너의 프로그램은
항상 바보와 미친놈만이 쓰느니라. 사용 설명서를 쓸 때에는 결코 빠뜨
리지 말아라. 빠뜨린 만큼 사용자는 너를 괴롭힐 것이니라.
10.매사에 겸손하고 항상 남을 생각할지어다. 가장 완벽한 프로그램일수록
가장 완벽하게 숨은 벌레가 있느니라. 네가 이 세상 최고의 프로그래머
라고 떠들며 자만할 때, 옆집 곳간에서는 훨씬 더 뛰어난 것을 묵묵히
만들고 있느니라. 아무렴 프로그래밍은 혼자 잘나서 할 게 아니니, 너
로 인해 다른 사람들도 더불어 잘 되면 그얼마나 좋은 것이냐.
♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->
프로그래밍을 공부하시는 분들께 큰 도움이 되리라 생각합니다.
시작부터 경지에 이르기까지…
1. 정보를 모음에 소홀히 하지 말고 설명서를 읽음에 게을리 하지 말지어
다. 오늘 필요 없는 정보는 내일 필요하리라. 가장 가치 있고도 저렴한
지식은 책 속에 있느니라. 서점과 동료의 책꽂이에 무엇이 꽂혀 있는지
때때로 살피어라. 무심코 흘렸던 종이 한 장이 너의 근심을 풀어 주었
으리라. 설명서는 충분히, 꼼꼼히 읽을지어다. 모든 의문은 설명서를
안 보는 데서 생기니라. 그렇더라도 모두 다 읽을 필요는 없느니라.
2. 너의 PC가 안전하다고 믿지 말지어다. 5분 후에 정전이 되고 내일 너의
하드가 맛이 가리라. 그러하니 너의 소중한 소스 코드는 정기적으로 여
러 군데에 단계별로 백업해 두어라.
3. 변하는 수를 다룰 때에는 늘 조심할지어다. 정수가 절대로 그 한계를
넘지 않으리라 가정하는 것은 어리석음이라. 127, -128, 255, 32767,
-32768, 65535, 이 숫자들을 너의 골수에 새기어라. 0.0은 0이 아니니
실수는 원래부터 결코 정밀하지 않느니라. 부호 없는 것과 있는 것을
어울리거나 정수끼리 나눌 때에는 늘 조심하여라.
4. 무슨 일을 반복시킬 때에는 처음과 끝에 유의할지어다. 너의 컴퓨터는
1보다는 0을 좋아 하니라. 배열의 첨자가 그 범위를 넘지 않을지 손 댈
때마다 따져 보아라. 수식에 1을 더하거나 뺄 때에는 늘 긴장하라. 너
의 프로그램은 단지 한 번 덜해서 틀리고 한 번 더해서 다운되느니라.
5. 항상 모든 경우의 수를 고려하고 섣불리 생략하지 말지어다. 절대로 일
어나지 않을 일은 반드시 일어나고, 가장 드물게 일어날 일이 가장 너
를괴롭히리라. 그러하니 언제나 논리에 구멍이 없는지 꼼꼼히 따져 보
고, if를 쓸 때에는 else부터 생각하라.
6. 함수 안에서 매개 변수값은 결코 믿지 말지어다. 지금 그 매개 변수가
결코 가질 수 없다는 값을 내일부터는 가지리라. 그러하니 매개 변수값
이 올바름을 항상 검사할지어다. 그렇더라도 처리 속도가 문제가 되는
경우는 예외이니라.
7. 오류를 알려 주는 기능은 있는 대로 모두 활용할지어다. 컴파일러의 경
고는 모두 켜 두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결
과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든
메모리 할당은 조만간 실패할 것이라.
8. 한 번의 수정과 재컴파일만으로 연관된 모든 것이 저절로, 강제로 바뀌
도록 할지어다. 어떠한 것을 수정했을 때에 연관된 것이 따라서 변하지
않는다면 그것이 곧 벌레이니라. 컴파일러로 하여금 매개 변수 리스트
를 완전하게 검사하도록 하고, 언젠가 손대야 하거나 따라서 변해야 하
는 수치는 전부 매크로로 치환하며, 형 정의를 적극 활용하여라.
9. 사용자가 알아서 잘 써 주리라고 희망하지 말지어다. 너의 프로그램은
항상 바보와 미친놈만이 쓰느니라. 사용 설명서를 쓸 때에는 결코 빠뜨
리지 말아라. 빠뜨린 만큼 사용자는 너를 괴롭힐 것이니라.
10.매사에 겸손하고 항상 남을 생각할지어다. 가장 완벽한 프로그램일수록
가장 완벽하게 숨은 벌레가 있느니라. 네가 이 세상 최고의 프로그래머
라고 떠들며 자만할 때, 옆집 곳간에서는 훨씬 더 뛰어난 것을 묵묵히
만들고 있느니라. 아무렴 프로그래밍은 혼자 잘나서 할 게 아니니, 너
로 인해 다른 사람들도 더불어 잘 되면 그얼마나 좋은 것이냐.
♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->
Trackback Address :: http://www.hongikcom.com/trackback/3