-
3.1 코딩 스타일의 중요성
-
3.1.1 가늠해보기
-
3.1.2 바람직한 스타일의 기준
-
3.2 코드 문서화
-
3.2.1 주석을 작성하는 이유
-
3.2.2 주석 스타일
-
3.3 코드 분해
-
3.3.1 리팩터링을 통한 코드 분해
-
3.3.2 설계 기준으로 코드 분해하기
-
3.3.3 이 책에 나온 코드 분해 사례
-
3.4 명명 규칙
-
3.4.1 좋은 이름과 나쁜 이름
-
3.4.2 명명 규칙
-
3.5 언어의 기능에 스타일 적용하기
-
3.5.1 상수 사용법
-
3.5.2 포인터 대신 레퍼런스 사용하기
-
3.5.3 사용자 정의 익셉션
-
3.6 코드 서식
-
3.6.1 중괄호 정렬 문제
-
3.6.2 스페이스와 소괄호에 대한 논쟁
-
3.6.3 스페이스, 탭, 줄바꿈
-
3.7 스타일과 관련하여 해결할 문제
-
3.8 정리
-
3.9 연습 문제
3.1 코딩 스타일의 중요성
3.1.1 가늠해보기
3.1.2 바람직한 스타일의 기준
- 바람직한 코드 작성 스타일의 정확히 제시하기는 쉽지 않다. 시간이 갈수록 자신만의 선호하는 스타일이 생기고, 다른 사람이 작성한 코드를 보다가 좋은 스타일을 발견할 때도 있기 때문이다.
- 잘 작성된 코드에서 볼 수 있는 공통적인 속성을 다음과 같이 골라낼 수 있다.
- 문서화
- 코드 분해
- 명명 규칙
- 언어 사용
- 코드 서식(포매팅)
3.2 코드 문서화
- 프로그래밍에서 말하는 문서화란 주로 소스 파일에 주석을 다는 것을 의미한다.
3.2.1 주석을 작성하는 이유
- 주석을 작성해야 하는 여러가지 이유를 알아보자.
+ 사용법을 알려주는 주석
- 함수가 던지는 익셉션, 매개변수, 리턴 타입 등에 대한 설명을 명시해줄 수 있다.
- 회사의 코딩 가이드라인에 함수 주석 방식을 따로 정해두지 않았다면 상식적으로 판단해서 작성한다. 이때 함수의 이름, 리턴값의 타입, 매개변수의 이름 및 타입으로 분명히 드러나지 않는 정보만 주석으로 남긴다.
+ 복잡한 코드를 설명하는 주석
- 코드 중간에 주석을 잘 다는 것도 중요하다. 실전에서 개발하는 코드는 알고리즘 자체가 복잡하거나 너무 난해해서 코드만 봐서는 이해하기 힘들 때가 많다.
+ 메타 정보를 제공하는 주석
- 코드 내용과는 다른 차원의 정보를 제공하기 위한 목적으로도 주석을 단다. 이러한 메타 정보는 코드의 구체적인 동작에 대해서는 표현하지 않고, 코드 생성에 대한 세부사항만 표현한다.
- 예를 들어 코드 작성자, 저작권 문구 등 정보를 담을 수 있다.
3.2.2 주석 스타일
- 코드에 주석을 다는 방식은 조직마다 다르다.
- 코드에 주석을 다는 다양한 방식을 살펴보자.
+ 문장 단위 주석
- 문서화에 소홀하지 않는 한 가지 방법은 모든 문장에 주석을 작성하는 것이다.
- 코드 전체를 주석으로 도배하면 복잡하고 지저분해보일 뿐만 아니라 프로그래밍이 단순 노동으로 전락해버릴 수도 있다.
- 한 눈에 들어오지 않는 표현식을 그대로 적지 말고 이해하기 쉬운 이름으로 된 함수로 바꾸면 좋다. 그러면 코드 자체가 문서의 역할을 하기 때문에 그 함수에 대한 주석을 따로 달 필요가 없고, 코드 재사용성도 높아진다.
- 코드가 난해하다면 장황하더라도 주석을 많이 다는 것이 코드를 이해하지 못하는 것보다는 낫다.
- 모든 문장마다 주석을 다는 방식이 바람직하지 않을 때가 많지만, 코드가 복잡하고 난해해서 굳이 이 방식을 적용해야 한다면 코드를 그대로 번역하지 말고 앞선 예제처럼 코드의 작성 의도를 설명한다.
+ 머리말 주석
- 소스 파일의 첫머리를 항상 표준 주석으로 시작하도록 정하는 방법도 있다.
- 소스 파일의 첫머리에 남기면 좋은 정보는 다음과 같다.
- 저작권 정보
- 파일과 클래스에 대한 간략한 설명
- 최종 수정 일자*
- 최초 작성자*
- 변경 내역*
- 파일에서 구현한 기능의 ID*
- 미완성 기능**
- 발견된 버그**
- 파일을 새로 생성할 때 자동으로 머리말 주석이 제일 먼저 나오는 템플릿을 작성하게 하는 개발 환경도 있다. 서브버전( SVN)을 비롯한 몇몇 소스 관리 시스템은 메타데이터를 추가하는 기능도 제공한다.
- 예를 들어 주석에 $Id$란 스트링을 적어두면 그 자리에 작성자, 파일명, 리비전 번호 그리고 작성 일자를 SVN이 넣어준다.
+ 고정 양식 주석
- 최근에는 주석을 외부 문서화 도구로 처리할 수 있도록 표준 양식에 따라 작성하는 사례가 늘고 있다.
- C++ 프로그래머는 HTML 기반 문서, 클래스 다이어그램, 유닉스 맨페이지를 비롯한 여러 가지 유용한 문서를 자동으로 생성해주는 Doxygen이란 무료 툴을 많이 사용한다.
- Doxygen은 C++ 문법을 인식할 수 있을 뿐만 아니라 @param, @return 그리고 @throws와 같은 특수한 주석 지시자를 이용하여 출력 형태를 원하는 형태로 꾸밀 수 있다.
- 자동으로 문서를 생성하는 도구를 사용하더라도 의미 없는 주석이 담기지 않도록 주의한다.
+ 임의 주석
- 정해진 형식과 관계없이 필요할 때마다 주석을 달 때가 있다. 이런 주석을 작성할 때는 다음과 같은 가이드라인을 따른다.
+ 코드가 곧 문서인 코드
- 잘 작성된 코드는 대체로 주석이 적고 쉽게 이해할 수 있다. 모든 문장마다 주석을 달아야 한다면 코드를 주석 내용과 최대한 가깝게 수정할 수 없는지 검토한다.
- 이름 수정, const 활용, 순서 변경 등
- 코드가 문서 역할을 하도록 작성하는 또 다른 방법은 코드를 더 작은 단위로 코드 분해하는 것이다.
3.3 코드 분해
- 코드 분해란 코드를 더 작은 단위로 나눠서 작성하는 방식이다.
- 가장 바람직한 형태는 함수나 메서드마다 한 가지 작업만 하는 것이다. 한 가지 작업을 처리하는 데 필요한 일도 복잡하다면 별도의 함수나 메서드로 분해한다.
3.3.1 리팩터링을 통한 코드 분해
- 자잘한 코드가 누적되면서 원래 세련되었던 코드가 패치나 특수한 경우를 처리하는 코드로 뒤덮이게 되는 것을 흔히 누더기(크러프트)가 되었다고 표현한다.
- 리팩터링이란 코드의 구조를 재조정하는 작업이다.
- 리팩터링할 때는 테스팅 프레임워크를 활용하는 것이 좋다.
3.3.2 설계 기준으로 코드 분해하기
- 프로그램을 구현할 때 모든 기능을 빠짐없이 코드로 작성하지 말고, 코드 분해 기법을 적용해서 나중에 모듈, 메서드, 함수에서 구현할 부분을 따로 빼놓는 방식으로 작성하면 코드의 복잡도를 낮추고 구조를 좀 더 체계적으로 만들 수 있다.
- 먼저 프로그램 설계부터 하고 나서 코드 작성에 들어가야 한다.
3.3.3 이 책에 나온 코드 분해 사례
3.4 명명 규칙
- C++ 컴파일러는 다음과 같은 명명 규칙을 따른다.
- 이름의 첫 글자로 숫자가 나올 수 없다. 9to5
- 더블 언더스코어는 특정한 용도로 사용되기 때문에 이름에 넣을 수 없다. my__name
- 언더스코어가 나온 다음 대문자로 시작하는 것도 특수한 용도로 정해져 있기 때문에 사용하면 안 된다. _Name
- 글로벌 네임스페이스에서 언더스코어로 시작하는 이름은 용도가 따로 있기 때문에 사용할 수 없다. _name
- 이름의 목적은 본인뿐만 아니라 동료 프로그래머가 프로그램의 구성 요소를 쉽게 다루는 데 있다는 점을 명심한다.
3.4.1 좋은 이름과 나쁜 이름
- 변수, 메서드, 함수, 매개변수, 클래스, 네임스페이스 등에 대한 가장 좋은 이름은 그 용도가 명확히 드러나는 것이다.
또한 타입이나 구체적인 용도와 같은 부가 정보도 이름에 담을 수 있다.
- 명명 규칙에 대해 확실히 정해진 것은 없으나 적절하다고 보기 힘든 이름은 분명 존재한다.
3.4.2 명명 규칙
- 흔히 사용하는 명명 규칙을 따르는 것만으로도 좋은 이름을 쉽게 지을 수 있다. 이름을 잘 짓는 데 흔히 적용하는 몇 가지 관례를 소개한다.
+ 카운터
- 프로그래밍을 처음 배울 때 카운터로 사용할 변수를 i로 표현한 코드를 본 적이 있을 것이다. 중첩된 반복문에서 최상위 카운터를 i로 쓰고 그 안에 있는 반복문의 카운터를 j로 표기하는 것이 거의 관행으로 굳어졌다. 하지만 이런 식으로 중첩된 반복문을 작성할 때는 표기하는 실수를 저지르기가 쉽다.
- 따라서 i와 j보다는 row와 column, outerLoopIndex와 innerLoopIndex로 써야한다는 의견도 있다.
+ 접두어
- 변수 이름 앞에 그 변수의 타입이나 용도를 암시하는 문자를 붙이는 프로그래머가 많다.
+ 헝가리안 표기법
- 헝가리안 표기법은 마이크로소프트 윈도우 프로그래머 사이에서 변수와 데이터 멤버 이름을 짓는 데 널리 사용되던 명명 규칙이다.
- 헝가리안 표기법이라고 부르는 이유는 이 표기법을 만든 찰스 시모니가 헝가리 출신이기 때문이다.
+ 게터와 세터
- get---()와 같은 게터나 set---()와 같은 세터를 사용한다.
- 부울 타입의 데이터 멤버에 접근할 때는 get 대신 is란 접두어를 붙일 때가 많다.
+ 대소문자 활용
- 코드에 나온 이름에 대소문자를 표기하는 방법은 여러 가지다.
- 변수나 데이터 멤버의 이름을 표기할 때는 소문자로 시작하고 단어 사이는 언더스코어(my_queue)나 대문자(myQueue)로 연결하는 방식을 주로 사용한다.
- C++에서는 전통적으로 함수나 메서드의 이름을 대문자로 표기했다.
+ 네임스페이스를 적용한 상수
- 중복 이름을 가진 상수를 서로 다른 네임스페이스에 속하게 만들면 된다.
- 이보다 더 좋은 방법은 열거 타입을 사용하는 것이다.
3.5 언어의 기능에 스타일 적용하기
3.5.1 상수 사용법
- 나쁘 코드는 대부분 매직 넘버를 남발하는 경향이 있다
- C++에서 제공하는 상수 기능을 활용하면 변하지 않는 값에 대해 의미 있는 이름을 붙일 수 있다.
- C++20부터 표준 라이브러리에 수학 상수가 추가되었으며, 이는 <numbers>에 std::numbers라는 네임스페이스로 정의되어 있다.
- 예를 들면 std::numbers::e, pi, sqrt, phi 등이 있다.
3.5.2 포인터 대신 레퍼런스 사용하기
- C++에서는 반드시 포인터를 사용해야 하는 경우가 있지만 대부분 레퍼런스로 처리할 수 있다.
- 포인터 대신 레퍼런스를 사용하면 좋은 점이 많다.
- 1. 포인터보다 레퍼런스가 더 안전하다. 메모리 주소를 직접 다루지 않고, nullptr이 될 수 없기 때문이다.
- 2. 코딩 스타일 측면에서 포인터보다 레퍼런스를 사용하는 것이 더 낫다. 스택 변수와 문법이 같아서 *나 &와 같은 기호를 쓸 필요가 없기 때문이다.
- 포인터와 레퍼런스를 모두 전달하더라도 그 객체를 수정할 수도 있고 그렇지 않을 수도 있다. const T*, T*, const T&, T& 중 어느 것으로 지정하느냐에 따라 결정된다. 따라서 함수에서 객체를 수정하는지 알아내려면 어처피 함수 프로토타입을 봐야한다.
- 레퍼런스의 또 다른 장점은 메모리의 소유권을 명확히 표현할 수 있다는 것이다. 다른 프로그래머가 전달한 객체를 레퍼런스로 받도록 메서드를 작성하면 그 객체를 읽거나 수정하는 작업은 마음껏 할 수 있지만, 전달된 객체에 할당된 메모리를 해제하기는 쉽지 않다. 하지만 포인터로 전달하면 그렇지 않다.
3.5.3 사용자 정의 익셉션
- C++에서는 익셉션을 무시하기 쉽다. C++에는 익셉션을 반드시 처리하라는 규칙이 없을 뿐만 아니라 nullptr을 리턴하거나 에러 플래그를 설정하는 기존 방식으로도 얼마든지 에러를 대처할 수 있기 때문이다.
- 익셉션은 에러 처리에 관련된 기능을 풍부하게 제공하는 메커니즘으로서, 자신의 용도에 맞게 사용할 수 있도록 익셉션을 직접 정의하는 기능도 제공한다.
3.6 코드 서식
- 코드 서식에 대한 규정이 없다면 반드시 정하는 것이 좋다. 코드의 통일성과 가독성을 높일 수 있다.
- 코드 서식을 자동으로 맞춰주는 툴도 있다. 소스 코드 관리 시스템에 커밋하기 전에 미리 정해둔 규칙에 맞는지 검사해준다. 어떤 IDE는 이런 기능을 기본으로 제공하기도 한다.
3.6.1 중괄호 정렬 문제
- 가장 흔한 논쟁거리 중 하나는 코드 불록을 표시하는 중골호에 대한 것이다.
- 한 문장짜리 블록에서 중괄호를 사용함으로서 잘못된 방식으로 작성된 C스타일 매크로로 부터 보호할 수도 있고 나중에 문장을 더 추가할 때도 안전하기 때문이다.
3.6.2 스페이스와 소괄호에 대한 논쟁
- 문장 단위에 적용되는 코드 서식도 흔한 논쟁거리다.
3.6.3 스페이스, 탭, 줄바꿈
- 스페이스와 탭에 대한 서식은 단순히 스타일에 대한 취향 문제로 보기 힘들다.
- 대부분의 에디터(코드 편집기)는 스페이스와 탭을 설정하는 기능을 제공한다.
- 탭과 스페이스는 서로 다르다는 것이다. 탭은 길이에 제한이 없지만 스페이스는 언제나 한 칸이기 때문이다.
- 줄바꿈도 신경써야한다. 플랫폼마다 줄바꿈을 표현하는 방식이 다를 수 있기 때문이다.
- IDE에서 제공하는 스타일 지정 기능을 활용할 수 있다. 또한 소스 코드 관리 시스템에서 코드를 커밋하기 전에 줄바꿈 서식을 자동으로 바꿔주는 경우도 있다.
3.7 스타일과 관련하여 해결할 문제
- 스타일에 대한 일관성을 이 정도 수준으로 유지하기란 쉽지 않은데, 그 이유는 다양하다.
- 개발자간의 const의 이해여부 차이 -> const 작성을 제거해버리는 경우
- 프로그래머의 취향과 기준에 맞지 않은 경우 -> 반드시 표준화할 요소와 아닌 요소를 나누는 것이 좋다.
3.8 정리
3.9 연습 문제
'Programming II > C++' 카테고리의 다른 글
| [전문가를 위한 C++] CHAPTER5 객체지향 설계 (1) | 2025.04.02 |
|---|---|
| [전문가를 위한 C++] CHAPTER4 전문가답게 C++프로그램 설계하기 (0) | 2025.04.02 |
| [전문가를 위한 C++] CHAPTER2 스트링과 스트링 뷰 다루기 (0) | 2025.03.30 |
| [전문가를 위한 C++] CHAPTER1 C++와 표준 라이브러리 초단기 속성 코스 (0) | 2025.03.30 |
| 전문가를 위한 C++ (0) | 2025.03.30 |
3.1 코딩 스타일의 중요성
3.1.1 가늠해보기
3.1.2 바람직한 스타일의 기준
- 바람직한 코드 작성 스타일의 정확히 제시하기는 쉽지 않다. 시간이 갈수록 자신만의 선호하는 스타일이 생기고, 다른 사람이 작성한 코드를 보다가 좋은 스타일을 발견할 때도 있기 때문이다.
- 잘 작성된 코드에서 볼 수 있는 공통적인 속성을 다음과 같이 골라낼 수 있다.
- 문서화
- 코드 분해
- 명명 규칙
- 언어 사용
- 코드 서식(포매팅)
3.2 코드 문서화
- 프로그래밍에서 말하는 문서화란 주로 소스 파일에 주석을 다는 것을 의미한다.
3.2.1 주석을 작성하는 이유
- 주석을 작성해야 하는 여러가지 이유를 알아보자.
+ 사용법을 알려주는 주석
- 함수가 던지는 익셉션, 매개변수, 리턴 타입 등에 대한 설명을 명시해줄 수 있다.
- 회사의 코딩 가이드라인에 함수 주석 방식을 따로 정해두지 않았다면 상식적으로 판단해서 작성한다. 이때 함수의 이름, 리턴값의 타입, 매개변수의 이름 및 타입으로 분명히 드러나지 않는 정보만 주석으로 남긴다.
+ 복잡한 코드를 설명하는 주석
- 코드 중간에 주석을 잘 다는 것도 중요하다. 실전에서 개발하는 코드는 알고리즘 자체가 복잡하거나 너무 난해해서 코드만 봐서는 이해하기 힘들 때가 많다.
+ 메타 정보를 제공하는 주석
- 코드 내용과는 다른 차원의 정보를 제공하기 위한 목적으로도 주석을 단다. 이러한 메타 정보는 코드의 구체적인 동작에 대해서는 표현하지 않고, 코드 생성에 대한 세부사항만 표현한다.
- 예를 들어 코드 작성자, 저작권 문구 등 정보를 담을 수 있다.
3.2.2 주석 스타일
- 코드에 주석을 다는 방식은 조직마다 다르다.
- 코드에 주석을 다는 다양한 방식을 살펴보자.
+ 문장 단위 주석
- 문서화에 소홀하지 않는 한 가지 방법은 모든 문장에 주석을 작성하는 것이다.
- 코드 전체를 주석으로 도배하면 복잡하고 지저분해보일 뿐만 아니라 프로그래밍이 단순 노동으로 전락해버릴 수도 있다.
- 한 눈에 들어오지 않는 표현식을 그대로 적지 말고 이해하기 쉬운 이름으로 된 함수로 바꾸면 좋다. 그러면 코드 자체가 문서의 역할을 하기 때문에 그 함수에 대한 주석을 따로 달 필요가 없고, 코드 재사용성도 높아진다.
- 코드가 난해하다면 장황하더라도 주석을 많이 다는 것이 코드를 이해하지 못하는 것보다는 낫다.
- 모든 문장마다 주석을 다는 방식이 바람직하지 않을 때가 많지만, 코드가 복잡하고 난해해서 굳이 이 방식을 적용해야 한다면 코드를 그대로 번역하지 말고 앞선 예제처럼 코드의 작성 의도를 설명한다.
+ 머리말 주석
- 소스 파일의 첫머리를 항상 표준 주석으로 시작하도록 정하는 방법도 있다.
- 소스 파일의 첫머리에 남기면 좋은 정보는 다음과 같다.
- 저작권 정보
- 파일과 클래스에 대한 간략한 설명
- 최종 수정 일자*
- 최초 작성자*
- 변경 내역*
- 파일에서 구현한 기능의 ID*
- 미완성 기능**
- 발견된 버그**
- 파일을 새로 생성할 때 자동으로 머리말 주석이 제일 먼저 나오는 템플릿을 작성하게 하는 개발 환경도 있다. 서브버전( SVN)을 비롯한 몇몇 소스 관리 시스템은 메타데이터를 추가하는 기능도 제공한다.
- 예를 들어 주석에 $Id$란 스트링을 적어두면 그 자리에 작성자, 파일명, 리비전 번호 그리고 작성 일자를 SVN이 넣어준다.
+ 고정 양식 주석
- 최근에는 주석을 외부 문서화 도구로 처리할 수 있도록 표준 양식에 따라 작성하는 사례가 늘고 있다.
- C++ 프로그래머는 HTML 기반 문서, 클래스 다이어그램, 유닉스 맨페이지를 비롯한 여러 가지 유용한 문서를 자동으로 생성해주는 Doxygen이란 무료 툴을 많이 사용한다.
- Doxygen은 C++ 문법을 인식할 수 있을 뿐만 아니라 @param, @return 그리고 @throws와 같은 특수한 주석 지시자를 이용하여 출력 형태를 원하는 형태로 꾸밀 수 있다.
- 자동으로 문서를 생성하는 도구를 사용하더라도 의미 없는 주석이 담기지 않도록 주의한다.
+ 임의 주석
- 정해진 형식과 관계없이 필요할 때마다 주석을 달 때가 있다. 이런 주석을 작성할 때는 다음과 같은 가이드라인을 따른다.
+ 코드가 곧 문서인 코드
- 잘 작성된 코드는 대체로 주석이 적고 쉽게 이해할 수 있다. 모든 문장마다 주석을 달아야 한다면 코드를 주석 내용과 최대한 가깝게 수정할 수 없는지 검토한다.
- 이름 수정, const 활용, 순서 변경 등
- 코드가 문서 역할을 하도록 작성하는 또 다른 방법은 코드를 더 작은 단위로 코드 분해하는 것이다.
3.3 코드 분해
- 코드 분해란 코드를 더 작은 단위로 나눠서 작성하는 방식이다.
- 가장 바람직한 형태는 함수나 메서드마다 한 가지 작업만 하는 것이다. 한 가지 작업을 처리하는 데 필요한 일도 복잡하다면 별도의 함수나 메서드로 분해한다.
3.3.1 리팩터링을 통한 코드 분해
- 자잘한 코드가 누적되면서 원래 세련되었던 코드가 패치나 특수한 경우를 처리하는 코드로 뒤덮이게 되는 것을 흔히 누더기(크러프트)가 되었다고 표현한다.
- 리팩터링이란 코드의 구조를 재조정하는 작업이다.
- 리팩터링할 때는 테스팅 프레임워크를 활용하는 것이 좋다.
3.3.2 설계 기준으로 코드 분해하기
- 프로그램을 구현할 때 모든 기능을 빠짐없이 코드로 작성하지 말고, 코드 분해 기법을 적용해서 나중에 모듈, 메서드, 함수에서 구현할 부분을 따로 빼놓는 방식으로 작성하면 코드의 복잡도를 낮추고 구조를 좀 더 체계적으로 만들 수 있다.
- 먼저 프로그램 설계부터 하고 나서 코드 작성에 들어가야 한다.
3.3.3 이 책에 나온 코드 분해 사례
3.4 명명 규칙
- C++ 컴파일러는 다음과 같은 명명 규칙을 따른다.
- 이름의 첫 글자로 숫자가 나올 수 없다. 9to5
- 더블 언더스코어는 특정한 용도로 사용되기 때문에 이름에 넣을 수 없다. my__name
- 언더스코어가 나온 다음 대문자로 시작하는 것도 특수한 용도로 정해져 있기 때문에 사용하면 안 된다. _Name
- 글로벌 네임스페이스에서 언더스코어로 시작하는 이름은 용도가 따로 있기 때문에 사용할 수 없다. _name
- 이름의 목적은 본인뿐만 아니라 동료 프로그래머가 프로그램의 구성 요소를 쉽게 다루는 데 있다는 점을 명심한다.
3.4.1 좋은 이름과 나쁜 이름
- 변수, 메서드, 함수, 매개변수, 클래스, 네임스페이스 등에 대한 가장 좋은 이름은 그 용도가 명확히 드러나는 것이다.
또한 타입이나 구체적인 용도와 같은 부가 정보도 이름에 담을 수 있다.
- 명명 규칙에 대해 확실히 정해진 것은 없으나 적절하다고 보기 힘든 이름은 분명 존재한다.
3.4.2 명명 규칙
- 흔히 사용하는 명명 규칙을 따르는 것만으로도 좋은 이름을 쉽게 지을 수 있다. 이름을 잘 짓는 데 흔히 적용하는 몇 가지 관례를 소개한다.
+ 카운터
- 프로그래밍을 처음 배울 때 카운터로 사용할 변수를 i로 표현한 코드를 본 적이 있을 것이다. 중첩된 반복문에서 최상위 카운터를 i로 쓰고 그 안에 있는 반복문의 카운터를 j로 표기하는 것이 거의 관행으로 굳어졌다. 하지만 이런 식으로 중첩된 반복문을 작성할 때는 표기하는 실수를 저지르기가 쉽다.
- 따라서 i와 j보다는 row와 column, outerLoopIndex와 innerLoopIndex로 써야한다는 의견도 있다.
+ 접두어
- 변수 이름 앞에 그 변수의 타입이나 용도를 암시하는 문자를 붙이는 프로그래머가 많다.
+ 헝가리안 표기법
- 헝가리안 표기법은 마이크로소프트 윈도우 프로그래머 사이에서 변수와 데이터 멤버 이름을 짓는 데 널리 사용되던 명명 규칙이다.
- 헝가리안 표기법이라고 부르는 이유는 이 표기법을 만든 찰스 시모니가 헝가리 출신이기 때문이다.
+ 게터와 세터
- get---()와 같은 게터나 set---()와 같은 세터를 사용한다.
- 부울 타입의 데이터 멤버에 접근할 때는 get 대신 is란 접두어를 붙일 때가 많다.
+ 대소문자 활용
- 코드에 나온 이름에 대소문자를 표기하는 방법은 여러 가지다.
- 변수나 데이터 멤버의 이름을 표기할 때는 소문자로 시작하고 단어 사이는 언더스코어(my_queue)나 대문자(myQueue)로 연결하는 방식을 주로 사용한다.
- C++에서는 전통적으로 함수나 메서드의 이름을 대문자로 표기했다.
+ 네임스페이스를 적용한 상수
- 중복 이름을 가진 상수를 서로 다른 네임스페이스에 속하게 만들면 된다.
- 이보다 더 좋은 방법은 열거 타입을 사용하는 것이다.
3.5 언어의 기능에 스타일 적용하기
3.5.1 상수 사용법
- 나쁘 코드는 대부분 매직 넘버를 남발하는 경향이 있다
- C++에서 제공하는 상수 기능을 활용하면 변하지 않는 값에 대해 의미 있는 이름을 붙일 수 있다.
- C++20부터 표준 라이브러리에 수학 상수가 추가되었으며, 이는 <numbers>에 std::numbers라는 네임스페이스로 정의되어 있다.
- 예를 들면 std::numbers::e, pi, sqrt, phi 등이 있다.
3.5.2 포인터 대신 레퍼런스 사용하기
- C++에서는 반드시 포인터를 사용해야 하는 경우가 있지만 대부분 레퍼런스로 처리할 수 있다.
- 포인터 대신 레퍼런스를 사용하면 좋은 점이 많다.
- 1. 포인터보다 레퍼런스가 더 안전하다. 메모리 주소를 직접 다루지 않고, nullptr이 될 수 없기 때문이다.
- 2. 코딩 스타일 측면에서 포인터보다 레퍼런스를 사용하는 것이 더 낫다. 스택 변수와 문법이 같아서 *나 &와 같은 기호를 쓸 필요가 없기 때문이다.
- 포인터와 레퍼런스를 모두 전달하더라도 그 객체를 수정할 수도 있고 그렇지 않을 수도 있다. const T*, T*, const T&, T& 중 어느 것으로 지정하느냐에 따라 결정된다. 따라서 함수에서 객체를 수정하는지 알아내려면 어처피 함수 프로토타입을 봐야한다.
- 레퍼런스의 또 다른 장점은 메모리의 소유권을 명확히 표현할 수 있다는 것이다. 다른 프로그래머가 전달한 객체를 레퍼런스로 받도록 메서드를 작성하면 그 객체를 읽거나 수정하는 작업은 마음껏 할 수 있지만, 전달된 객체에 할당된 메모리를 해제하기는 쉽지 않다. 하지만 포인터로 전달하면 그렇지 않다.
3.5.3 사용자 정의 익셉션
- C++에서는 익셉션을 무시하기 쉽다. C++에는 익셉션을 반드시 처리하라는 규칙이 없을 뿐만 아니라 nullptr을 리턴하거나 에러 플래그를 설정하는 기존 방식으로도 얼마든지 에러를 대처할 수 있기 때문이다.
- 익셉션은 에러 처리에 관련된 기능을 풍부하게 제공하는 메커니즘으로서, 자신의 용도에 맞게 사용할 수 있도록 익셉션을 직접 정의하는 기능도 제공한다.
3.6 코드 서식
- 코드 서식에 대한 규정이 없다면 반드시 정하는 것이 좋다. 코드의 통일성과 가독성을 높일 수 있다.
- 코드 서식을 자동으로 맞춰주는 툴도 있다. 소스 코드 관리 시스템에 커밋하기 전에 미리 정해둔 규칙에 맞는지 검사해준다. 어떤 IDE는 이런 기능을 기본으로 제공하기도 한다.
3.6.1 중괄호 정렬 문제
- 가장 흔한 논쟁거리 중 하나는 코드 불록을 표시하는 중골호에 대한 것이다.
- 한 문장짜리 블록에서 중괄호를 사용함으로서 잘못된 방식으로 작성된 C스타일 매크로로 부터 보호할 수도 있고 나중에 문장을 더 추가할 때도 안전하기 때문이다.
3.6.2 스페이스와 소괄호에 대한 논쟁
- 문장 단위에 적용되는 코드 서식도 흔한 논쟁거리다.
3.6.3 스페이스, 탭, 줄바꿈
- 스페이스와 탭에 대한 서식은 단순히 스타일에 대한 취향 문제로 보기 힘들다.
- 대부분의 에디터(코드 편집기)는 스페이스와 탭을 설정하는 기능을 제공한다.
- 탭과 스페이스는 서로 다르다는 것이다. 탭은 길이에 제한이 없지만 스페이스는 언제나 한 칸이기 때문이다.
- 줄바꿈도 신경써야한다. 플랫폼마다 줄바꿈을 표현하는 방식이 다를 수 있기 때문이다.
- IDE에서 제공하는 스타일 지정 기능을 활용할 수 있다. 또한 소스 코드 관리 시스템에서 코드를 커밋하기 전에 줄바꿈 서식을 자동으로 바꿔주는 경우도 있다.
3.7 스타일과 관련하여 해결할 문제
- 스타일에 대한 일관성을 이 정도 수준으로 유지하기란 쉽지 않은데, 그 이유는 다양하다.
- 개발자간의 const의 이해여부 차이 -> const 작성을 제거해버리는 경우
- 프로그래머의 취향과 기준에 맞지 않은 경우 -> 반드시 표준화할 요소와 아닌 요소를 나누는 것이 좋다.
3.8 정리
3.9 연습 문제
'Programming II > C++' 카테고리의 다른 글
| [전문가를 위한 C++] CHAPTER5 객체지향 설계 (1) | 2025.04.02 |
|---|---|
| [전문가를 위한 C++] CHAPTER4 전문가답게 C++프로그램 설계하기 (0) | 2025.04.02 |
| [전문가를 위한 C++] CHAPTER2 스트링과 스트링 뷰 다루기 (0) | 2025.03.30 |
| [전문가를 위한 C++] CHAPTER1 C++와 표준 라이브러리 초단기 속성 코스 (0) | 2025.03.30 |
| 전문가를 위한 C++ (0) | 2025.03.30 |
