[C++ 스타일 5편] 주석과 문서화: Doxygen, Javadoc, 단문 주석 스타일

코드 주석과 문서화는 C++ 스타일에서 종종 간과되지만, 협업이나 유지보수 측면에서 매우 중요한 요소입니다. 주석 스타일과 문서화 형식을 일관성 있게 유지하면, 새로운 팀원이 코드를 빠르게 이해하고, 변경 사항 추적이 쉬워지는 장점이 있습니다. 이번 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등 다양한 가이드에서 제안하는 주석과 문서화 스타일을 살펴봅니다. 또한 Doxygen, Javadoc 스타일 주석, 단문 주석 위치 및 형식에 대한 고려사항과 상황별 선택 방법을 논해봅니다.다양한 스타일 가이드의 예구글 C++ 스타일 가이드:함수와 클래스의 공개 인터페이스에 대해 Doxygen 스타일(///나 /**구현 세부사항에 대한 단문 주석은 소스 코드 내 라인 끝 또는..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 4편] 클래스와 함수 인터페이스: 멤버 순서, 접근성(접근제어) 배치, 함수 본문 스타일

C++ 클래스와 함수 선언부의 스타일은 코드 가독성과 유지보수성에 큰 영향을 줍니다. 클래스 내 멤버 변수를 어떤 순서로 배치할지, 접근제어 지정자(public, protected, private)를 어디에 놓을지, 함수 정의를 헤더 안에 둘 것인지 cpp 파일로 분리할 것인지, 그리고 함수 본문에서 중괄호 배치나 파라미터 정렬 방식을 어떻게 할지 등 다양한 결정 사항이 있습니다.이번 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등 다양한 스타일 가이드가 클래스 및 함수 인터페이스 디자인과 관련해서 어떤 규칙을 제안하는지 살펴봅니다. 또한 각 접근법의 장단점을 논하고, 상황에 따른 최선의 선택을 고민해봅니다.다양한 스타일 가이드의 예구글 C++ 스타일 가이드:클래스..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 3편] 헤더 파일 구조: #include 순서, 전방 선언, 헤더 가드 vs. #pragma once

C++ 프로젝트에서 헤더 파일은 코드 구조와 의존성을 정의하는 중요한 요소입니다. 어떤 헤더를 먼저 포함할지, 전방 선언을 활용할지, 헤더 가드는 어떤 식으로 정의할지, 혹은 #pragma once를 쓸지 등 여러 스타일의 선택지가 있습니다. 이런 결정은 빌드 시간, 의존성 관리, 모듈화, 가독성에까지 영향을 미칩니다.이번 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등 다양한 가이드에서 제안하는 헤더 파일 구성 방식에 대해 살펴봅니다. 또한 각 방식의 장단점을 분석하고, 상황에 따라 어떤 선택이 더 적합한지 생각해봅니다.다양한 스타일 가이드의 예구글 C++ 스타일 가이드:#include 순서: 표준 라이브러리, 서드파티 라이브러리, 프로젝트 헤더 순으로 정렬 권장..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 2편] 네이밍 컨벤션: 변수명, 함수명, 클래스명, 그리고 언더스코어 vs. 카멜케이스

C++ 코드에서 이름 짓기는 매우 중요한 요소입니다. 변수, 함수, 클래스, 네임스페이스, 매크로, 열거형 등 다양한 요소에 이름을 부여할 때, 일정한 규칙을 따르면 코드를 읽는 이가 의도를 더 쉽게 파악할 수 있습니다. 하지만 네이밍 컨벤션에 대한 스타일 가이드들은 저마다 다른 권장사항을 내놓습니다. 어떤 곳은 함수명을 CamelCase로, 어떤 곳은 snake_case로 쓰라고 하고, 또 다른 곳은 클래스 앞에 C를 붙이는 구시대적 관례를 아직도 유지하기도 합니다.이 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등 다양한 스타일 가이드에서 권장하는 네이밍 컨벤션을 비교하고, 각 스타일의 장단점을 분석합니다. 또한 팀이나 프로젝트 상황에 따라 어떤 네이밍 컨벤션을..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[C++ 스타일 1편] 들여쓰기와 공백 규칙: 스페이스 vs. 탭, 그리고 라인 길이

C++ 코드 스타일에서 가장 먼저 부딪히는 문제 중 하나가 바로 들여쓰기(Indentation)입니다. 개발자는 최소한의 수평 정렬을 통해 코드 계층 구조를 표현하는데, 이때 스페이스(space)와 탭(tab) 중 무엇을 사용할지, 기본 들여쓰기 폭은 얼마로 할지, 그리고 라인 길이는 어느 정도로 제한할지를 결정해야 합니다.본 글에서는 대표적인 스타일 가이드(구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등)가 들여쓰기 관련 규칙을 어떻게 정의하는지 살펴봅니다. 또한 스페이스 대비 탭 사용의 장단점, 긴 라인을 어떻게 줄여나갈지에 대한 조언, 팀 내에서 일관성을 강제하는 방법 등을 다룰 것입니다.다양한 스타일 가이드의 예구글 C++ 스타일 가이드: 스페이스 사용 권장(2칸 들..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 15.
• textsms

[모던 C++ #11] 모던 C++으로 가는 여정의 마침표: 이제 어떤 길을 갈까?

지금까지 이 시리즈를 통해 C++ 표준이 어떻게 발전해 왔는지, 그리고 그 과정에서 왜 오래된 구현이나 관용구를 버려야 하는지를 살펴보았습니다. auto_ptr부터 시작해, C-Style 배열, 매크로 상수, 전통적 for 루프, C-Style 문자열, printf, SFINAE 트릭, 구식 함수 객체와 std::bind, 직접 스레드 관리, 직접 구현한 알고리즘까지 — 이 모든 레거시 패턴들이 모던 C++에서는 훨씬 더 나은 대안으로 대체되고 있습니다.C++20 이후로 언어와 라이브러리는 더욱 풍부해졌습니다. std::unique_ptr로 명확한 메모리 소유권을 관리하고, std::array와 std::vector, std::span으로 컨테이너를 안전하게 다루며, constexpr와 enum clas..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 14.
• textsms

[모던 C++ #10] 직접 구현한 알고리즘 대신 C++20 Ranges와 병렬 알고리즘으로!

과거 C++98/03 시절에는 표준 라이브러리가 제공하는 알고리즘도 제한적이었고, 특정 요구사항을 만족하기 위해 개발자가 직접 알고리즘을 구현하거나, 반복자 기반 STL 알고리즘을 복잡하게 조합해야 하는 경우가 많았습니다. 또한 병렬 처리나 고성능 연산을 위해서는 플랫폼별 스레드 관리나 OpenMP, TBB 같은 서드파티 라이브러리에 의존해야 했습니다.모던 C++20에서는 Ranges 라이브러리를 통해 알고리즘 파이프라인을 선언적으로 구성할 수 있으며, 병렬 알고리즘 지원을 통해 표준 라이브러리 레벨에서 병렬화를 쉽게 도입할 수 있습니다. 이렇게 하면 코드 가독성과 유지보수성이 대폭 개선되며, 성능 향상을 위한 병렬화도 간단히 적용할 수 있습니다.관련 참고 자료:C++20 RangesParallel al..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 14.
• textsms

[모던 C++ #9] 직접 스레드 관리에서 std::jthread와 코루틴으로!

과거 C++98/03 시절, 멀티스레딩을 구현하기 위해서는 운영체제별 API(pthread, Win32 threads 등)를 직접 호출하거나, Boost Threads와 같은 서드파티 라이브러리에 의존해야 했습니다. 이는 코드 이식성을 저하시켰고, 스레드 생성, 종료, 동기화 관리가 번거롭게 이루어지는 경우가 많았습니다.C++11 이후 표준 라이브러리에 std::thread, std::mutex, std::lock_guard, std::async 등 기본적인 멀티스레딩 기능이 도입되었고, C++20에서는 std::jthread와 중단 요청(stop token) 메커니즘이 추가되어 스레드 관리가 더 단순해졌습니다. 또한 C++20 코루틴(coroutine)을 활용하면 비동기 처리를 더 간결하고 직관적으로 ..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 14.
• textsms

[모던 C++ #8] 구식 function object와 std::bind를 버리고 람다와 std::function로!

과거 C++98/03 시절에는 함수 객체(function object) 클래스를 직접 정의하거나, std::bind를 통해 함수 호출을 커스터마이징하는 패턴이 흔했습니다. 하지만 이러한 방법은 코드가 장황해지고 의도를 분명히 드러내지 못하는 경우가 많았습니다. 호출 대상이 어디에 있는지, 어떤 인자를 바인딩했는지 일일이 추적해야 했으며, 이는 코드 가독성과 유지보수성에 악영향을 끼쳤습니다.모던 C++에서 이 문제를 해결하기 위해 람다(lambda) 표현식과 std::function을 사용할 수 있습니다. 람다는 익명 함수 객체를 간결한 문법으로 정의할 수 있고, 캡처를 통해 외부 변수를 자연스럽게 접근할 수 있습니다. 또한 std::function은 범용 함수 포인터 래퍼로, 다양한 호출 대상(람다, 함..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 14.
• textsms

[모던 C++ #7] SFINAE 트릭을 떠나 Concepts로!

과거 C++ 템플릿 프로그래밍에서 타입 제약을 표현하기 위해 사용되던 기법 중 하나가 바로 SFINAE(Substitution Failure Is Not An Error)였습니다. 이는 템플릿 인자의 대입 과정에서 타입이 맞지 않을 경우 에러 대신 다른 오버로드를 시도하는 기법으로, 조건부로 템플릿을 선택하는 메타프로그래밍 트릭이었습니다.그러나 SFINAE는 코드가 복잡해지고, 컴파일 에러 메시지가 난해해진다는 단점이 있었습니다. 모던 C++20에서는 Concepts를 통해 이 문제를 해결했습니다. Concepts는 템플릿 인자에 대한 명확한 제약 조건을 선언적으로 표현할 수 있어 코드 가독성과 유지보수성, 그리고 에러 진단을 크게 개선합니다.관련 참고 자료:SFINAEConcepts (C++20)과거:..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 14.
• textsms