헤더 파일에 헤더 파일 추가하지 않는 법

1. 프리컴파일 해더에는 표준, 써드파티 또는 거의 변경되지 않는 라이브러리의 해더만 포함하자
2. #include보다는 forward declaration을 사용하자
1. class
2. struct
3. function
4. enum 
5. typedef
3. value 맴버보다 reference 맴버를 사용하라
4. inner 클래스나 enum을 만들지 마라
5. 구현부를 숨겨라
6. 인터페이스로 만들어라

참고자료

1. Effective C++, 항목 31

기획이 불확실한 경우에 프로그래밍 절차

프로젝트의 기획이 명확하지 않은 경우 - 게임의 경우, 항상 그런것 같다 - 나에게는 잘 맞는 개발 절차다.

기본 철학

1. 실용주의 - 할 일만 최소한으로 한다
2. 빠른 피드백 루프 - 만들고, 보여주고, 수정한다 
3. 좋은 코드 - 읽기 쉽고 요구사항을 충족한다

절차

1. 핵심기능을  단순하고 빠르게 구현한다
2. 피드백을 받아서 코드를 수정한다
3. 다음 작업을 시작하기 전에 리팩토링을 한다
4. 1번으로 돌아간다

설명

핵심기능을  단순하고 빠르게 구현한다

요구사항에 있는 선에서 최대한 빠르게 실행해볼 수 있는 구조로 코드를 작성한다. 이 때는 좋은 코드에 대해서 고민하지 않는다. 그저 적은 코드로 빠르게 테스트 하는 것에 집중한다.
좋은 코드란, 읽기 쉽고 요구사항을 최대한 충족하는 것이다. 요구 사항의 핵심 기능만 분명할 뿐, 나머지는 변경의 여지가 있다. 그래서 핵심 기능만 단순하게 구현하여 변경 사항을 확인하고 코드에 대비한다.

피드백을 받아서 코드를 수정한다

빠른 피드백 루프의 핵심을 빠른 수정이다. 빠른 수정을 위해서 가장 좋은 대비 방법은 단순한 개념과 코드다. 개념과 코드를 단순하게 유지하면, 수정하기 쉽다. 개념이 단순하면 사고도 유연해 진다.

다음 작업을 시작하기 전에 리펙토링을 한다

리펙토링을 아무런 기준없이 하는 것은 끝이 없는 일을 하는 것과 같다. 리펙토링은 좋은 코드를 만들기 위해서 한다. 좋은 코드란 읽기 쉽고 요구사항을 최대한 충족하는 것이다. 따라서, 다음 추가할 작업은 리펙토링의 좋은 기준이 된다.

1번으로 돌아간다

3번과 4번은 동시에 진행된다. 다음 요구사항을 빠르고 구현하기 위해서 리펙토링을 중간중간에 하는 것이다.

결론

리펙토링은 다음 수정사항을 목표로 코드 작성 중간중간에 해야된다. 따라서, 프로그래머에게 충분한 작업 시간을 주는 것이 무엇보다도 중요하다

10가지 Visual Studio 디버거 팁

출처: 10 More Visual Studio Debugging Tips for Native Development

1. 예외 시에 멈추기
2. 조사식 창에서 가상 변수(Pseudo-variables)
3. 영역을 빠져나간 후에 힙 객체 보기
4. 배열을 영역으로 보기
5. 원하지 않는 함수로 한단계 들어가서 실행 안하기
6. 코드에서 디버거 실행하기
7. 출력 창에 프린트
8. 메모리 누수 고립 시키기
9. 릴리즈 빌드에서 디버깅하기
10. 원격 디버깅하기

추상 데이터 형(ADT)

출처: Code Complete2 6.1절 요약

효율적인 프로그래머가 되기 위한 핵심 요소는 다른 코드를 작업하는 동안 무시해도 좋은 프로그램의 부분을 최대화하는 것이다

1. ADT는 데이터와 연산의 집합이다. 그러나 "데이터"는 느슨하게 사용된다
2. ADT를 먼저 생각하고 클래스를 두 번째로 생각하는 것은 언어로의 프로그래밍과 언어에서의 프로그래밍의 한 예이다
3. 저수준 구현 도메인보다 문제 도메인에서 작업할 수 있는 힘을 사용하도록 하라!

ADT 예

1. 선박제어
1. 속력을 설정한다
2. 현재 설정을 얻는다
3. 이전 속력으로 달린다
4. 사용을 중지한다
2. 전구
1. 켠다
2. 끈다

ADT 혜택

1. 세부적인 구현 사항을 감출 수 있다
2. 변경이 전체 프로그램에 영향을 미치지 않는다
3. 인터페이스가 보다 많은 정보를 제공하도록 만들 수 있다
4. 성능을 향상시키기가 쉽다
5. 외관상으로 프로그램이 정확하다는 것을 더 잘 알 수 있다
6. 프로그램이 보다 더 스스로를 설명하게 된다
7. 프로그램에 모든 데이터를 넘길 필요가 없다
8. 저수준 구현 구조체 대신 실세계의 개체들을 다룰 수 있다

ADT 사용지침

1. 전형적인 저수준 데이터 형을 ADT로  만들어라
2. 파일과 같은 일반적인 객체들을 ADT로 취급하라
3. 간단한 항목이라도 ADT로 취급하라

ADT와 클래스

• 클래스에 대해서 생각하는 한 가지 방법은 ADT에 상속과 다형성을 더한 것으로 생각하는 것이다

AStyle과 Google Cpplint로 C++ 코드 스타일 자동화하기

코드 스타일을 잘 지키는 것도 중요하지만, 스타일을 지키는 비용도 중요하다. 구글 스타일 가이드를 지향하되 20/80 법칙에 따라 비용을 최소화하기 위해 절충했다.

준비물

1. AStyle Extension
2. Cpplint
3. Python2.7 이상

AStyle Extension

AStyle Extension을 설치한다. Visual Studio 설정에서 AStyle Formatter를 선택하고 C/C++에서 구글 스타일 가이드에 맞는 설정을 한다.

--style=google --indent=spaces=2 --max-code-length=80 --pad-header --unpad-paren --keep-one-line-blocks --mode=c

그리고, "Format on save"옵션을 체크하면된다.

이제 문서를 수정하다가 저장하면 자동으로 포맷을 수정해준다.

Python2.7

그냥 설치하면된다.

Cpplint

Cpplint.py는 그냥 파이썬 스크립트이다. 따라서 대강 어딘가에 저장한다. - 솔수션 파일과 같은 위치 -. Visual Studio에서 자동으로 사용하기 위해서는 외부도구로 연결 시켜줘야 한다.

제목: cpplint
명령: c:\python27\python.exe
인수: cpplint.py --output=vs7 --verbose=0 --verbose=1 --verbose=2 --verbose=3 --verbose=4 --extensions=h,cpp $(ItemPath)
초기 디렉토리: $(SolutionDir)
출력 창 사용 : 체크

그리고 솔루션 폴더에 CPPLINT.cfg라는 파일을 만들고 다음 내용을 입력한다

set noparent
exclude_files=resource.h
exclude_files=targetver.h
filter=-legal/copyright.h
filter=-build/c++11
filter=-build/include_what_you_use
filter=-readability/multiline_comment
filter=-build/header_guard
filter=-whitespace/comments

각자 편한데로 설정해서 쓰면된다.

10가지 코드 주석과 서식 습관

출처: 10 Best Practices of Code Commenting & Formatting

코드 주석과 서식은 코드를 이해하기 위한 것이다. 코드의 이해는 유지보수와 밀접하게 관계있다.

주석

1. "요구되는" 주석을 사용하라
1. 라인마다 불필요한 주석은 가독성을 떨어뜨린다
1. int count = 0; // 0을 초기값으로 count에 할당한다(?!?)
2. 주석의 부족은 유지보수 시간을 증가시킨다. 또한,  변수/메소드  이름을 이해될 만하고 스스로 설명을 하도록 짓는다
1. int s = sqrt(v1) + v2 / v3 + fread(s). getChar(0) //(?!?)
2. List<int> getVal(int val, int len, String op) //(?!?)
2. 틀린 주석을 작성하지 마라. 틀린 설명은 없는 주석보다 나쁘다
3. 변수가 중요하거나 스스로 설명하는 이름을 지을 수 없으면 주석을 작성하라
4. 공개 메소드의 주석을 작성하는 것은 좋은 습관이다. 물론, 이 주석들은 "정말 필요"하고 "요구되는" 것이어야 한다
5. "깨달음(gotcha)"와 "할 일(todo)"는 발견 즉시 문서화하라. 이것들은 훗날 현재를 기억하는데 도움이 될 것이다. 문서화하지 않으면, 당장 내일만 되도 기억하지 못 할 것이다. 결국 문제 있는 코드는 계속될 것이다

서식

1. 괄호는 일관성있게 사용하라. 열린 괄호를 현재 라인 끝에 놓던지 새로운 라인 처음에 놓던지 일관성을 유지하라
2. 요구되는 빈 라인을 일관성있게 사용하라. 빈 라인은 코드들을 가독성을 위해 의미적으로 분리하기 위해서 사용한다. 예를들어, 메소드 끝에 3줄 빈 라인, 빈 줄 없는 코드 또는 각 라인 마다 1~2줄 빈 라인은 가독성을 떨어뜨리고 눈에도 안 좋다.
3. 들여쓰기에 주의하라. 명령문 그룹을 위한 올바른 들여쓰기는 괄호와 빈 라인을 사용하는 것만큼 중요하다
4. 한 라인의 글자수는 가독성을 위해 제한하라. 보통 80자다. 그러나 약간을 조절될 수 있다
5. 코드 사이에 빈칸을 일관성있게 사용하라. 빈칸 사용의 적합한 상황은 다음과 같다
1. 연산자와 피연산자 사이
   a += b , c = 0; (a == b)
2. 명령문 키워드와 괄호 사이
   if (value) {, public class A {
3. 루프에서 ';'글자 다음에
   for(int i = 0; i < length; i++)
4. 타입 변환자와 피연산자 사이
   (int) value, (String) value

나의 생각

한가지 추가하고 싶은 서식이 하나 있다

1. 변수는 최대한 사용하기 바로 전에 선언하라

이는 가독성을 올려주고, 리펙토링 시에도 도움이 된다. 이 습관을 그대로 따를 필요는 없지만, 어떤 형태로든 위의 습관들에 대해서 팀내 합의를 통해 결정을 하고 일관성있게 유지하도록 노력해야한다

서식의 경우, AStyle과 Google Cpplint로 C++ 코드 스타일 자동화하기를 참고하자

프로그래밍 데드라인에서

원본: On Programming Deadline

데드라인에 가까워졌을 때, 실행하면 좋은 규칙들이 있다.

1. 코드를 작성하기 전에 지속적인 배포 시스템을 설정하라
2. 테스트를 먼저 작성하라
3. 투명성을 유지하라
4. 일일 TODO 목록을 수행하라
5. 옳은 일을 해라

3번의 경우, 투명성이란, 현재 진행되고 있는 상황에 대해서 솔직하게 보스와 고객에게 공개하는 것이다. 일일 보고서도 좋고 직접 만날 수 있다면, 아침에 짧은 미팅을 가지는 것도 좋다. 가장 좋은 것은 1번이 구축되어서 이들에게 현재까지 진행된 결과물을 테스트해 볼 수 있도록 하는 것이다. 투명성을 확보해서 신뢰를 얻게 되면 데드라인 변경을 설득할 때도 도움이 된다.

5번의 경우, 시간에 쫓기더라도 올바르다고 생각하는 것을 해라. 물론 지연에 대한 질책이 걱정이 될 것이다. 하지만, 억지로 이번 데드라인을 넘긴다고 해도 다음 데드라인 때는 더욱 어려운 상황이 될 것이다. 그러니, 자신의 감각을 믿고 옳다고 생각하는데로 하라