12장 기본 데이터형
목차
- 12.1 숫자 일반
- 12.2 정수
- 12.3 부동 소수점 수
- 12.4 문자와 문자열
- 12.5 불린 변수
- 12.6 열거형
- 12.7 이름 상수
- 12.8 배열
- 12.9 새로운 형 만들기(형 별명)
12.1 숫자 일반
숫자를 사용할 때 오류를 유발하지 않기 위한 지침
- 매직 넘버를 피한다.
- 필요하다면 0과 1은 그냥 사용한다.
- 0으로 나눔 오류를 미리 방지한다.
- 컴파일러의 경고에 주의를 기울인다.
12.2 정수
정수를 사용할 때 고려사항
- 정수 나눗셈을 검사한다.
- 정수 오버플로를 검사한다.
- 중간 결과에서의 오버플로를 검사한다.
12.3 부동 소수점 수
부동 소수점 사용 지침
- 서로 크기가 매우 다른 수를 더하거나 빼지 않는다.
- 동치 비교를 피한다.
- 라운딩 오류를 예측한다.
- 특정한 데이터형을 지원하는 언어와 라이브러리가 있는지 확인한다.
12.4 문자와 문자열
문자열을 사용하는 몇가지 팁
- 매직 문자와 문자열을 사용하지 않는다.
- 하나 차이로 인한 오류를 주의한다.
- 자신이 사용하고 있는 언어와 환경에서 유니코드를 어떻게 지원하는지 알아둔다.
- 국제화/지역화 전략을 초기에 결정한다.
- 알파벳 기반의 단일 언어를 지원할 필요가 있다는 사실을 안다면 ISO 8859 문자 집합 사용을 고려한다.
- 다중 언어를 지우너해야 한다면 유니코드를 사용한다.
- 문자열 형 사이에 일관된 변환 전략을 결정한다.
12.5 불린 변수
불린 변수 사용 지침
- 프로그램을 문서화하기 위해서 불린 변수를 사용한다.
- 복잡한 테스트를 단순화하기 위해 불린 변수를 사용한다.
- 필요하다면 사용자 정의 불린 형을 만든다. (C언어처럼 불린이 없는 경우)
12.6 열거형
열거형 사용 지침
- 가독성 향상을 위해 열거형을 사용하라.
- 안전성을 위해 열거형을 사용하라.
- 변경하기 쉽게 열거형을 사용하라.
- 불린 변수에 대한 대안으로 열거형을 사용하라.
- 유효하지 않은 값을 검사하라.
- 반복문의 범위를 지정하기 위하여 열거의 처음과 마지막 항목을 정의하라.
- 열거형의 첫 번째 항목을 유효하지 않은 값으로 남겨라.
- 프로젝트 코드 작성 표준에 처음과 마지막 요소가 어떻게 사용될 것인지를 정확하게 정의한 후 일관성 있게 사용하라.
- 열거형의 요소에 명시적인 값을 할당할 때 발생할 수 있는 위험 요소를 주의하라.
12.7 이름 상수
이름 상수 사용 지침
- 데이터 선언에 이름 상수를 사용하라.
- 명백한 리터럴이라도 리터럴은 피하라.
- 범위가 적절하게 지정된 변수나 클래스를 사용하여 이름 상수를 흉내 내라.
- 이름 상수를 일관성 있게 사용하라.
12.8 배열
배열 사용 팁
- 배열의 모든 인덱스가 배열의 경계 내에 있는지 확인하라.
- 배열 대신 컨테이너 사용을 고려하거나 배열을 순차적인 구조체로 생각하라.
- 배열의 마지막 위치를 확인하라.
- 다차원 배열에서는 인덱스가 정확한 순서대로 사용되는지 확인하라.
- 인덱스가 혼선되지 않도록 주의하라.
- C에서는 배열을 다루기 위해서 ARRAY_LENGTH() 매크로를 사용하라.
#define ARRAY_LENGTH(x) (sizeof(x) / sizeof(x[0]))
12.9 새로운 형 만들기(형 별명)
새로운 형을 만들어야 하는 이유
- 수정하기 쉬워진다.
- 과도하게 정보를 분산시키는 것을 피할 수 있다.
- 신뢰성을 향상시킨다.
- 언어의 약점을 보완한다.
새로운 형을 만들기 위한 지침
- 기능 지향적인 이름으로 형을 생성하라.
- 미리 정의된 형을 가리키는 형 이름을 조심하라.
- 미리 정의된 형을 피하라.
- 미리 정의된 형을 재정의하지 말라.
- 다른 플랫폼으로 이식하기 쉽게 대체 형을 정의하라.
- 미리 정의된 형으로 쉽게 오인할 수 있는 형은 선언하지 말라.
- typedef를 사용하는 대신 클래스 생성을 고려하라.
느낀점
그동안 나는 매직 넘버와 매직 스트링, 리터럴을 사용하고 있었다. 그렇게 크지 않은 프로그램이었고, 그래서 수정할 때도 그렇게 힘든 것을 몰랐기 때문인 것 같다. 하지만 코드의 길이가 길어지고, 이곳 저곳에서 사용하게 되고, 만약 코드를 변경하게 되어야 하는 상황이 발생했을 때 여러곳에 퍼져있는 리터럴을 수정하는 것은 정말 상상하기도 싫다. 새로운 형을 만들고, 이름 상수를 쓰는 방법을 사용해 유지보수가 쉬운 코드를 작성해야 한다는 생각을 갖게 해주는 장이었다.