게임 서버 프로그래밍 입문 (3) - 소스 작성 규칙

 

제가 작성한 책의 코드들을 보시기 전에 아래의 규칙에 의해 책의 소스가 작성되어 있으니 미리 읽어 두셔서 코드 보시는 데 도움이 되셨으면 합니다.
비단 이 책뿐만 아니라 현업에서도 많이 통용되는 규칙이니 소개해 드리려고 합니다.

 

1	SVN에 소스를 커밋(업 로딩)은 반드시 컴파일 성공한 결과만 넣어야 합니다. 현업에서는 자신의 작업을 올릴 때 다른 팀원의 방해를 주면 안되므로 당연히 컴파일에 문제없는 파일을 올려야 합니다.
2	소스 커밋 시 최대한 로그를 자세히 달아놓아야 합니다. 무엇을 수정했는지, 버그는 이랬고, 이런 문제로 이렇게 수정했다 등, 이후 새로운 버그 발생시 해결할 실마리를 줍니다.
3	코드 주석 주석은 될 수 있으면 쓰지 않습니다. 코드 수정 시, 매번 주석도 갱신해야 하는데 이런 관리문제도 있으므로 나중에는 부작용이 더 커집니다. 오히려 코드 자체만으로 주석을 쓰듯 나타내는 코드가 좋은 코드라고 생각합니다. 단 꼭 필요한 경우에는 사용해야 하며, 여기서는 “읽기 좋은 코드가 좋은 코드다.” 책에서 소개된 내용과 같이 주석을 작성할 것입니다. //TODO: 추가로 코드 작업을 해야 할 때 작성 //FIXME: 뭔지 모르겠지만, 이 코드에 문제가 있다. 고쳐야 한다. //HACK: 문제 해결로 작성하다 보니 코드가 엉켜 있음 (아름답지 않은 해결) //XXX: 주의! 여기 건드리면 큰일 남!
4	이 소스에는 컨벤션이 있습니다. 컨벤션을 맞춰서 작성되었으니 참고 바랍니다.    1. If 띄고 (를 쓰고 {는 그 행에 사용한다.  If ( a = b) {         printf(“…”);     }   2. switch case에서 case 는 switch 와 들여쓰기를 맞춰야 합니다.  switch (temp) {     case AAA:         printf(“…”);   3. 클래스 맴버 변수는 마지막에 _를 사용합니다. class TestClass {      int index_; };   4. 문장은 낙타(camelCasing)을 주로 사용하며, 컴퓨터에 의해 생성되는 소스는 스네이크(snake_value)표기 법을 사용합니다. 익숙하신 헝가리안 표기법(pValue)은 사용하지 않습니다.   5. 카멜 캐스팅이므로 변수 중간에 _를 붙이지 않습니다. 단 맴버 변수만 뒤에 _를 붙입니다.  bool active_;      //클래스 맴버변수 active_  bool active;       //함수 안에서만 쓰는 변수 active   6. 클래스는 반드시 대문자로 시작하고, 변수는 반드시 소문자로 시작합니다. Enum, define등은 모두 대문자로 표기합니다.    7. enum 값은 앞에 E를 붙입니다.    8. 클래스 내부 함수를 같은 클래스 안에서 쓸 때는 this->를 반드시 명시합니다.  Class A {     Int index_;     void func();     Void too() {        Index_ = x;        this->func(); }

 

여기서 보이는 소스의 “if (a = b) {“ 와 같이 {를 내리지 않고 쓰는 스타일을 Egyptian Brackets이라고 불립니다. K&R 스타일인데, 제가 거쳐 왔던 회사가 모두 저런 스타일로 코드를 작성해서 제가 익숙하다 보니 그렇게 작성하였습니다.

 (책 분량 조절도 해야 하고요)

 

또 많이들 클래스 맴버 변수에 m_ 나, 포인터라는걸 알리는 p 같은 헝가리안 표기법을 사용하시겠지만, 요즘 IDE에서는 변수의 타입을 바로 다른 창이나 툴 팁에 띄울 수 있고, 이러한 표기법은 가끔 코드 리더빌리티(code readability)를 떨어트릴 수 있어서 사용하지 않는 곳도 많습니다.

아래는 이와 관련 토론한 게시글인데, 한 번은 읽어 보시길 추천합니다.
 https://kldp.org/node/46915

 

표기법은 다른 책들에서 자주 나오는 헝가리안 표기법(pValue)이 대세를 이루기도 하지만,
여기서는 카멜 표기법(valuePointer), 생성된 코드는 스네이크 표기법(value_pointer)을 사용합니다.
익숙하지 않을 것 같다고 생각은 듭니다만, 회사에서는 회사 코드 스타일로 소스를 작성해야 다른 작업 하는 사람들도 헷갈리지 않으므로 미리 연습한다고 생각하시면 좋을 것 같습니다.

 

회사에서 이렇게 규칙을 정하는 이유는 코드 유지 보수 차원상 팀의 개개인의 제각각의 스타일을 통일하여 비상시 누구라도 다른 사람 feedback을 해주는 시스템을 갖추기 위함입니다.
뉴스에서 표준어를 사용하는 것과 같은 거로 생각해 주시면 좋을 것 같습니다.

 

위 내용은 제가 집필한 "게임 서버 프로그래밍 입문" 책의 내용중 일부 부분에 대한 내용입니다.

전체 소스 코드와 책 구입에 대해서는 http://rosagigantea.tistory.com/589 에 링크 시켰습니다.