7. Style Case Studies

스타일에 대해 경우 스터디를 해 보자.

34. Index Tables

기본적으로 코드의 명료함과 정확성을 우선하라. 묵시적 int에 의존하지 마라. 이는 표준 C++가 아니다. void main()이나 main()은 C++ 표준이었던 적이 없다. 많은 컴파일러가 이를 확장으로 지원하긴 하지만. const 정확성을 연습하라. 코드 중복을 피하라. 명료하고 의미있는 이름을 선택하라. 적절한 경우, 직접 손으로 코딩하는 대신 표준 라이브러리를 활용하라. 하드코딩될 필요 없는 제네릭 타입에 대해서는 재사용성을 확장하라. 반복자는 <가 아닌 !=로 비교하라. 이전 값을 쓸 필요가 없다면 전치 증가를 후치 증가보다 선호하라.

35. Generic Callbacks

타입 변환을 정말 가능하게 해야 하지 않는다면 생성자를 explicit로 하라. const 정확성을 지켜라. 함수 오브젝트에는 execute() 대신 operator()를 써라. 함수 인자는 꼭 필요하지 않다면 템플릿 인자 대신 함수 인자로 써라. 오브젝트가 컨테이너와 호환 가능하도록 하라. 즉, 오브젝트는 대입 가능해야 한다. 클래스 템플릿에서 그것이 적절하다면 다형성을 가능케 해서 클래스 템플릿의 서로 다른 인스턴스화가 상호 호환 가능하게 하라. 그 경우엔 클래스 템플릿의 모든 인스턴스화에 공유되는 공통 기반 클래스를 제공하라. 템플릿 제한을 피하라. 덜 일반적인 타입에 대해서 타입을 하드코딩하는 것을 피하라.

36. Construction Unions

5의 법칙을 지켜라. 클래스가 복사 생성자/복사 대입 연산자/이동 생성자/이동 대입 연산자/소멸자 중 하나가 있으면 다섯 개를 전부 제공해야 한다. 코드를 더 불안정하게 하고 유연성을 깨는 고정 정보를 피하라. 항상 모든 데이터 멤버는 private여야 한다. 예외는 캡슐화를 제공하지 않는 C 스타일 struct이다. 유용한 주석만 써라. 코드를 반복하는 주석은 쓰지 마라. 코드를 설명하고 왜 그 코드를 썼는지에 대한 주석을 쓰라. const 정확성을 연습하라. 타입 변환을 피하라. 타입 안정성을 선호하라. _나 __로 시작하는 이름을 피하라. 그것은 컴파일러나 표준에 의해 예약되어 있다. union 대신 C++17의 std::variant, std::any를 써라.

37. Monoliths “Unstrung”, Part 1: A Look at std::string

단일 클래스 단일 책임을 선호하라. 가능하다면 함수를 비 프렌드 비멤버 함수로 쓰라.

38. Monoliths “Unstrung”, Part 2: Refactoring std::string

std::string은 단일 클래스에 너무 많은 멤버 함수를 갖고 있는 설계 미스이다. 이를 반복하지 말라.

39. Monoliths “Unstrung”, Part 3: std::string Diminishing

std::string에서 여러 함수는 사실 비프렌드 비멤버 함수로 만들 수 있다.

40. Monoliths “Unstrung”, Part 4: std::string Redux

범위를 체크하지 않는 버퍼에 쓰는 함수를 쓰지 말라. 널로 끝나는 C 스타일 문자열에 실패하는 함수를 쓰지 말라. 이는 크래시 뿐만 아니라 버퍼 오버런이라는 보안 취약점의 문제가 되어 해커와 멀웨어 제작자들에게 위협적이다. 단일 클래스 단일 책임을 선호하라. 가능하다면 함수를 비 프렌드 비멤버 함수로 쓰라.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중