버그 안녕! (Writing Solid Code) - 정말 버그가 사라진다면야...

1장. 가상 컴파일

단위 테스트 등의 버그의 위치를 알려주는 도구를 이용하라.
모든 컴파일러의 경고 옵션을 활성화 시켜라. (최고 Lv, 경고를 에러로 처리)
코드의 빈틈을 파악하고, 그 빈틈이 발생했을 때 알 수 있게끔 코드를 작성하라. 블랙 박스식 검사에 의존하지 말자.

2장. 주관을 갖자
릴리즈, 디버그에 다른 코드를 작성하라. 예외 검사는 디버그 모드에서 활성화 시키고, 디버그 버전으로 테스트하라.
디버그 테스트를 위해 assert를 적응 이용하라.
정의되지 않은 동작 또는 의도하지 않은 동작을 캐치할 때 assert를 사용하라.
assert는 Release에서 포함될 코드를 포함하면 안된다. Release에서도 포함될 코드라면 예외 처리를 하라.
방어적 프로그래밍을 하되, 버그를 숨기지 않도록 주의하라. 큰 그림을 보라. 해당 로직이 처리되지 않음으로 인해 발생할 수 있는 파생효과도 고민하도록하라.
병목 루틴은 다른 방식의 이차적인 알고리즘을 구현해서 두가지 경우 모두 다 성공하도록 작성하라.

3장. 서브시스템(Subsystem)을 굳건하게!
불규칙한 동작을 제거하라. 발견된 버그를 재현할 수 있도록 조치하라.
메모리 내의 쓸모 없는 데이터는 오용되지 않도록 파괴하라.
디버그 버전에서는, 각종 정보를 오래 보관하도록하라.
서브 시스템 점검용 루틴을 작성하고, 가능한 한 자주 사용하라.
테스트용 루틴을 세심하게 설계하라. 아무렇게나 선택된 것이 있어선 안된다.

4장. 코드를 추적하라
디버거를 이용하라.
코드를 추적할 때는 데이터의 흐름에 초점을 맞춰라.
코드의 모든 진행 경로를 최소한 한번 이상 추적했는가 확인해라.

5장. 자동 판매기 인터페이스
프로그래머들은 자기가 작성한 함수를 다른 프로그래머들이 어떻게 사용할까를 생각하는 훈련이 되어 있지 않다.
에러가 일어나는 조건을 명시하여, 알아보기 쉽게 하라. 
작성한 인터페이스에 함정이 없도록 하라. (에러 코드와 결과 값을 분리하라. 결과 값을 보고 성공 여부를 판단하게 하지 말라)
다 기능 함수를 만들지 말라.
함수의 변수들을 명료하게 정의하라.
적합한 데이터를 입력하면 절대로 실패하지 않는 함수를 작성하라.

6장. 위험한 사업
정확하게 정의된 데이터 형을 사용하자.
이 변수 또는 표현식이 오버플로우 또는 언더 플로우를 일으킬 수 있을까 고민하자.
함수의 의도를 완벽하게 구현하라.
모든 함수가 자기 기능을 단번에 발휘 할 수 있도록 작성하라.
삼항 연산자(?:)를 사용하지 말라.
불필요한 if문을 제거하라.
프로그래밍 언어의 위험한 구문은 사용하지 말라.
서로 다른 종류의 연산자를 함께 사용하지 말라. 어쩔 수 없는 경우라면 괄호로 우선 순위를 명시적으로 표현하라.
실패하는 함수는 사용하지 말라.

7장. 꾀부리는 프로그래머
자신에게 주어진 영역이 아닌 메모리는 절대 사용하지 말라.
소유권을 해제한 메모리는 다시 사용하지 말라.
출력용 메모리를 작업용 버퍼로 사용해선 안된다.
데이터를 정적 메모리나 전역 메모리에 임시 저장 하지 말라.
언어가 제공하는 의도에 어긋나게 코드를 작성하지 말라.
C코드가 짧다고 기계어 코드도 짧아지지 않는다.
코드는 읽기 쉽게 작성하라

8장. 남은 것은 ‘자세뿐’
버그는 저절로 생기지 않으며, 저절로 없어지지도 않는다.
버그는 즉각 수정하라.
버그 추적시 버그의 근본적인 원인을 파악하라.
이유 없이 코드를 수정하지 말라.
함수나 기능을 작성할 때 확장성 보다는, 사용 편의성과 직관성에 중점을 둬라.
런 앤 픽스하지말라.
테스트 하기 쉽게 작성하고 테스트를 미루지 말라.