.. 시작부터가 오캄의 면도날 부터 들이 댄다. 개인 취향일 뿐인 습관들에 연연하지 않아도 되는데. 그래도 일관성을 유지 할수 있다면, 유지 하라고 한다. 이 중에서도, 1. 코드의 들여쓰기 스타일이 사람마다 다른데, 구조를 보기 위해서 한가지 일관성을 유지하는게 좋다. 2. 라인의 길이에 제한은 없지만, 읽기 쉬울 정도로만 유지하는게 좋다. 3. 이름짓기 규칙을 너무 빡빡하게 정할 필요는 없지만, 가능하다면, 이름 짓기 규칙을 만들어 유지하는게 좋다, 3 중에서 몇가지 더 할 말이 있는데, 절대, 앞에 _ 를 붙이지 말것, 왜냐하면 표준 라이브러리 제작자와 컴파일러 독점이다. 또한, __ 이렇게 두개를 붙이지도 말 것 #define 이름은 항상 대문자로 하고, 평범한 단어는 사용 하지 말것, 만약 두세..
책 정리 검색 결과
bookoa 에 있길래, 직거래로 거래해서 구입을 했다. C++ In-Depth seriese 중에 한 권이며, 허브셔터의 저서 4권(Exceptional C++이 총 3권) 중 한권이다. 이 사진에서 가장 눈에 띄우는 것은 "포스트 잇" 그리고 책의 중앙에 있는 "나무 길" 이다. 포스트 잇은 이 사진의 주인이신 분이 이해가 되지 않는 문장을 나중에 다시 보기 위해서 표시해 둔것이라고 한다. 나도 이렇게 봐야 하는데.. : ) 나무 길을 보고 있으면, 마음이 편안해 지면서, 그래도 갈 수 있는 길이라고 느껴진다. 이 책은, 허브셔터와 안드레이 알렉산드레스쿠(Mordern C++ 의 저자 .. )가 같이 만든 책으로, 코딩을 할 때, 겪게 되는 코딩 스타일을 좋은 방향으로 바꾸는 방법을 제시해 주는 책이..
이번 항목은 std::string 의 스타일을 알아보고, 한가지 설계 지침을 통하여, 이 스타일을 간략하게 비평해 본다. 1 ) 일체적(monolithic) 클래스란 무엇이며, 왜 나쁜지 설명하라. 일체적(monolithic) 클래스란? 클래스가 매우 크고 무거워 더 이상 나눌 수 없는 클래스를 뜻한다. 매우 크다고 무겁다는 뜻은, 코드가 매우 방대하다는 뜻이다. 이게 왜 나쁜가? 코드의 량이 방대하면, 우선, 사용하기 힘들고, 수정하기 힘들며, 추가하기 힘들다. 이는 유지 보수가 무척이나 까다롭다는 것을 뜻한다. 예를 들자면, 1. 잠재적으로 개별적인 가능성을 한 클래스 안에서 집어 넣는다. 이는 다른 형식들과 함께 사용 할 가능성을 막아 버리는 것이므로, 사용 범위가 무척이나 좁아 진다. 2. 새로운..
일반화 프로그래밍의 가장 큰 매력은 코드의 재사용이다. 이번 항목은 "어떻게 좀 더 일반화 시킬 수 있지?"를 생각해 보는 항목이다. 1 ) 일반적 클래스나 함수를 설계하고 작성할 때 추구해야 할 사항들로는 무엇이 있는지 설명하라. 내 경우는 간단함과 직관적인 함수명, 마지막으로 재사용 이다. 책에서는 필요 이상의 형식 제한을 피하고, 필요 이상의 기능성을 제하고, 필요 이상의 일체적 설계를 피하는 것을 추구해야 한다고 한다. 2 ) 다음 코드는 콜백 함수를 감싸는 흥미롭고도 유용한 관용구를 보여준다. 좀 더 자세한 설명은 원래의 글[Kalev01]을 참고하기 바란다. 다음 코드를 비평하고 다음을 지적해라. #include template class ca..
서문, 필자가 자신의 경험담을 들려주면서 시작한다. 자신은 컨설턴트였고, 어떤 프로젝트에 참여한다. 필자는 그 프로젝트의 소스코드를 보던 중 소스코드가 너무 지저분하여, 정리할 것은 프로젝트 매니저에게 말했지만, 프로젝트 매니저는 이 말을 듣지 않았다고 한다. 필자는 그 소스 코드에 작업하고 있는 프로그래머에게 문제점을 보여 주었고, 다른 프로그래머들은 소스 코드를 정리하게 되었다고 한다. 소스 코드는 많이 정리하게 되었고, 이 작업에 2틀이나 소요되었지만 소스 코드는 더 깔끔해 졌고, 새로운 기능을 추가하기 편해지게 되었다. 6개월이 흐른 뒤에 이 프로젝트는 실패되었다고 필자는 말해준다. 그 이뉴는 상당 부분은 너무 복잡해서 디버그나 퍼포먼스 튜닝을 할 수 없었기 때문이라고 한다. 이 이야기가 바로 "..
최근댓글