형식을 맞추는 목적 코드 형식의 목적은 의소소통의 일환이다. 오랜 시간이 지난 코드는 (요구사항 변화등으로)수정이 될지라도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 요이성과 확장성에 영향을 미친다. 경험상 형식이 안좋은 코드는 다른 개발자가 코드를 수정해야 할 때 안좋은 형식을 그대로 따라가게 된다. 따라서 눈에 읽기 좋은 코드를 만들기 위해 형식을 맞추도록 노력해야한다. 적절한 행 길이를 유지하라 개발 언어마다 차이는 있겠지만 하나의 파일 안에 몇천,몇만줄의 코드가 들어있으면 굉장히 피곤하다. 따라서 최대한 작은 파일로 코드의 길이를 유지하면 좋다. 책에서는 한 파일당 200줄 내외가 적당하다고 말한다. 물론 하나의 파일에 몇 줄의 코드가 정답이다 라는것은 없지만 최대한 파일을 작게 만든..
내가 주석을 추가할 때 코드로 설명하기 어려움이 있어서 추가하는 경우가 대부분이었다. 그러나 프로그래밍 언어를 통해 의도를 표현할 능력이 있다면, 주석은 전혀 필요하지 않다고 저자는 말한다. 하지만 아주 특별한 경우 좋은 주석도 존재한다고 설명한다. Q. 주석이 있으면 왜 안좋은가? A. 코드는 변화하고 진화한다. 이러한 과정에서 주석은 코드를 정확히 따라가기(업데이트되기) 힘들다. 따라서 부정확한 정보를 제공하는 주석으로 남을 가능성이 있다. 주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 일번적인 이유는 코드 품질이 나쁘기 때문이다. 위에서도 말했듯이 코드 작성자가 코드로 설명하기 힘든경우 코드외에 주석을 추가하여 의도를 설명한다. 즉, 클린코드 관점에서 서술적인 코드가 되지 못한것이다. ..
작게 만들어라 함수에 대한 클린코드의 메세지는 2장의 의미있는 이름을 만드는 방법과 연장선에 있는 내용이다. 더 편하고 이해하기 쉽게 코드를 작성하는 것을 목표로한다. 모든 프로그램의 가장 기본적인 단위는 함수이다. 기존의 코드를 읽을 때 함수부터 시작하게 되는데 함수가 조금이라도 긴 경우 읽고싶은 마음은 없어지고 스트레스만 밀려오게 된다. 함수는 짧을 수록 좋다는게 클린코드의 철학이다. 한 가지만 해라 대부분 길이가 긴 함수는 두가지 이상의 일을 하는 경우가 많다. 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서이다. 길이가 긴 A함수 안에서 의미 있는 이름의 다른 함수를 추출할 수 있다면 ..
의도를 분명히 밝혀라 변수, 함수, 클래스 이름을 정할 때 아래의 세가지 질문에 대답이 가능 하도록 이름을 짓는다. 1) 존재 이유 2) 수행 기능 3) 사용 방법 예) 1 2 int d; //경과 시간 int elaspedTimeInDays; cs 단순히 변수 명을 d라고 쓰는 경우보다 아래와 같이 구체적으로 사용하는게 좋다. 또한 함수가 어떤 일을 하는지 이해하기 쉽게 기술하도록 노력한다 예) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Member* getThem() { for(vector::size_type i = 0; iisLeader()) return (*iter); } }//앞의 함수보다 이해하기 Colored by Color Scripter cs 로직은 동일하지만 이름을..
코드 존재의 이유 저자는 "요구사항을 표현하는 언어"라고 한문장으로 정의한다. 간혹 목적이 희미한채로 코드를 작성하게 될 때도 있는것 같다. 그럴때면 어떤 요구사항을 위해 코드를 작성하는지 다시한번 생각해보고 요구사항을 함께 검토해봐야 한다. 나쁜 코드 나쁜코드란 유지보수가 안되는 코드라고 말한다. main부터 본인이 직접 작성하는 경우보다 기존에 존재하는 코드(legacy code)에 요구사항을 추가하는 경우가 대부분이다. 남들이 작성한 코드는 언제나 부담스럽다. 그러나 어떤 사람이 짠 코드는 며칠을 봐도 이해가 안가는 반면 어떤 사람이 짠 코드는 몇 시간이면 이해가 간다. 남의 코드를 보는 것은 항상 어려운 일이지만 그 난이도의 차이는 분명이 존재한다. 나쁜 코드가 쌓일 수록 생산성은 아래의 그래프 ..
나의 경우 주로 for문에서 후위증가를 사용했었고 타인의 코드를 볼 때 전위증가를 사용하는 사람이 있으면 그냥 스타일 차이인가 보다 하고 넘겼었는데 갑자기 궁금해져서 찾아보게 되었다. 전위증가와 후위증가의 차이는 결론적으로 전위증가가 더 효율적이다. for문내에서는 컴파일러가 전위증가를 사용하던 후위증가를 사용하던 별차이가 없다고는 하지만 실제로 list의 전위,후위 증가 연산자 오버라이딩 된 코드를 보면 전위연산자가 조금더 효율적인것 같다. _Self& operator++() _GLIBCXX_NOEXCEPT //전위증가 { _M_node = _M_node->_M_next; return *this; } _Self operator++(int) _GLIBCXX_NOEXCEPT //후위증가 { _Self __..
vector를 사용한 뒤 메모리를 해제해주기위해 보통 clear함수를 많이 호출한다. 그러나 clear함수는 vector에 저장된 값들은 제거되지만 vector에 할당 된 메모리는 삭제되지 않는다. 아래의 예를 보면 clear 함수 호출 후에도 capacity값이 남아 있음을 볼 수 있다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #include #include using namespace std; int main(void) { vector vt; vt.push_back(10); vt.push_back(10); vt.push_back(10); vt.push_back(10); vt.push_back(10); vt.push_back(10); vt.clear(..
대부분의 경우 vector를 for문에 사용할 때 iterator를 사용하거나 초기화식을 int를 사용한다. iterator로 사용할 경우 문제없지만 초기화식 타입에 int를 사용할 경우 오버플로우를 발생할 수 있다. 왜냐하면 vector의 size는 정확히 말하면 signed int가 아니라 unsigned int 타입이기 때문이다. 따라서 이러한 버그가 발생하면 찾기도 힘드니 정확한 방법으로 vector를 사용하도록 한다. 예제 1234567891011121314151617181920#include #include using namespace std; int main(void) { vector vt; vt.push_back(10); vt.push_back(10); vt.push_back(10); vt..
C언어를 이용하여 라이브러리를 만들거나 프로그램 시작/종료시 메모리를 관리하고 싶을 때 아래의 코드에서처럼 __attribute__((constructor)) 와 __attribute__((destructor)) 사용하면 유용할 것 같다. 단점으로는 gcc컴파일에서만 활용할 수 있다는 점이다. 아래의 코드는 실행결과 처럼 constructor -> main -> AAA() - > BBB() -> CCC() -> main -> destructor 순으로 실행된다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 #include void __attribute__((constructor)) constructo..
외부에 제공하는 API의 함수 정의 부분에 아래와 같이 EXPORT_API라는 부분이 있어서 메크로를 타고타고 들어가보니 아래와 같이 선언되어 있었고 실제로는 __attribute__ ((visibility("default"))) 라는 키워드가 있었다. #define EXPORT_API __attribute__ ((visibility("default"))) /*Tizen wifi-manager중 일부*/ EXPORT_API int wifi_manager_initialize(wifi_manager_h *wifi) 115 { 116 int rv; 117 118 CHECK_FEATURE_SUPPORTED(WIFI_FEATURE); 119 120 if (wifi == NULL) { 121 WIFI_LOG(WIF..
