본 문서는 소프트웨어 개발 시 준수해야 하는 코딩 스타일을 정의하고 가이드한다. 본 문서의 가이드는 C 언어를 대상으로 하고 있으며 C99 표준이 적용된다(추후 C11 등 최신 표준으로 변경 적용 가능하며, 이에 따라 본 문서의 내용이 일부 변경될 수 있다). 본 문서의 가이드는 구글 C++ 코딩 스타일 가이드(https://google.github.io/styleguide/cppguide.html)를 기반으로 내부적인 필요에 따라 일부 내용을 수정, 변경하여 적용한 것이다. 헤더파일 헤더파일을 바르게 사용하는 것으로 코드의 가독성과 크기, 성능에 큰 차이를 만들 수 있다. #define 가드 H-1. 헤더파일이 중복 포함되는 것을 방지하기 위해, 모든 헤더파일 내에 #define 가드를 사용한다. #d..
Git 사용 규칙 - Git commit 메시지 본 글에서는 더 나은 커밋 로그 가독성, 협업 및 리뷰, 코드 유지보수를 지원하기 위한 깃 커밋 메시지 규칙을 정리한다. 공통 규칙 1. 커밋 메시지는 최대한 한글로 작성한다. 2. 메시지 본문에 모든 변경 사항을 상세히 작성한다. 축약하여 쓰지 않고 제3자가 쉽게 이해할 수 있도록 최대한 풀어서 작성한다. 커밋 메시지 구성 1. 모든 커밋 메시지는 다음과 같이 세 영역으로 구성되며, 각 영역은 빈 줄로 분리된다. 제목 줄 본문 (제목 만으로 표현이 가능할 때에는 생략 가능) 꼬리말 (관련 이슈가 없으면 생략 가능) 유형: 제목 본문 꼬리말 제목 작성 1. 제목 줄은 72자 내로 작성한다. (Git UI 툴인 GitKraken 기준이며, 툴 또는 편의에 따..
소프트웨어 버전 규칙 본 글에서는 개발 중인 또는 개발 완료된 소프트웨어의 버전 할당에 관련된 규칙을 정의한다. 소프트웨어에 할당하는 버전은 기본적으로 유의적 버전 2.0.0-ko2에 소개된 버전 규칙을 따른다. 본 글은 유의적 버전 2.0.0-ko2에 기술된 내용을 그대로 옮겼으며, 해당 내용에서 삭제된 부분은 취소선, 새롭게 추가된 부분은 녹색 글씨로 표시하였다. 유의적 버전 2.0.0 요약 버전을 주.부.수 숫자로 하고: 1. 기존 버전과 호환되지 않게 API가 바뀌면 “주(主, Major) 버전”을 올리고, 2. 기존 버전과 호환되면서 새로운 기능을 추가할 때는 “부(部, Minor) 버전”을 올리고, 3. 기존 버전과 호환되면서 버그를 수정한 것이라면 “수(修, Patch) 버전”을 올린다. 주..
Git을 이용하여 소프트웨어 개발을 시작한지도 몇 년이 되었다. 그 동안 Git을 사용해 오면서 Git 커밋 이나 브랜치 규칙(여기서 브랜치 규칙이란 개인적으로 Git-flow, Github-flow 등과 같은 개념을 의미한다)은 이것저것 도입해 사용해 보았으나, 명시적으로(문서 상으로) 규칙을 정해 놓지 않은 관계로, 상황이나 시간의 변화에 따라 때로는 일관된 규칙을 적용하지 못하였다. 곧 시작할 새로운 중요 개발 프로젝트를 본격적으로 시작하기 전에 Git을 어떻게 잘 사용할지에 대해 다시 한번 정리해 보고자 한다. 그 중에서도 본 글에서는 브랜치를 어떻게 관리할 것인지에 대한 브랜치 규칙에 대해 정리한다. 개발 환경회사의 특성 상, 내 개발 환경은 다음과 같은 특징을 가진다.대부분의 프로젝트를 혼자서..