Blog | Tag | Local | Guest | Login | Write |  RSS
Code Convention에 해당되는 글 7건
2008.11.14 :: Naming Conventions
2008.10.24 :: 소개


1. if
 
- if-else statement 에서 else, else if 부분은 독립적인 줄에 기술한다. 

- 정상적인 경우를 먼저 처리한다.

- 판단문은 단순화 한다

- if-else statement 와 function macro 가 함께 사용될 경우 

# if-else 안이 한문장이더라도 brace를 해준다.

if (x == 3)
{
m_SP3();
}
else
{
m_BORK();
}

# macro 내에서 brace를 한다.

#define m_STMT(stuff)    { do {stuff} while(0) }
#define m_SP3()             m_STMT ( if (b) {int x; ab = f(&x); bv += x; } )

if (x == 3)
m_SP3();
else
m_BORK();

 
2. switch

- case는 switch와 같은 indent 를 가지며, 독립적인 줄에 기술한다.

- default를 제외한 모든 case에는 break statement를 사용한다. 

   만약, 이를 의도적으로 사용하지 않을 경우 comment 를 붙여준다.

- default 문은 에러를 찾는 목적으로 사용한다.


switch (expr)
{
case ABC:
case DEF:
statement
break;
case UVW:
statement
/* FALL THROUGH */
case XYZ:
statement
break;
}


3. for /
while

- null body를 가지는 경우 null statement 를 독립된 줄에 기술하고 comment 를 작성한다.

- do-while 문의 경우 항상 {}를 사용한다.

while (*dest++ = src++)
; /* NULL */




1. Indentation (들여쓰기)
 
- Indentation 은 Tab 키를 사용한다.

- Tab size 는 4나 8로 정한다.

- 복합문이 중첩된 경우 포함될 내용은 복합문장의 Tab위치보다 한 Tab만큼 오른쪽으로 띄워 기록한다.

- ‘ { ‘ 기호와 ‘ } ’ 기호는 같은 indentation을 가지며, 그 줄에는 어떠한 code도 위치할 수 없다.(Comment제외)
     단, { } 사이에 들어갈 내용이 한줄에 적힐 정도로 충분히 적을 경우에는 동일한 줄에 위치할 수 있다.

 Good  Bad
 struct boat
{
    int wllength;
    BoatType type;
    long sailArea;
};
 struct boat {
int wllength;
BoatType type;
long sailArea;
};



2. Blank space

-  Keyword (if, while, return, switch, for등) 와 ‘(‘사이에 한 칸을 띄운다.
    그러나 functio, sizeof, macro 의 경우에는 붙여준다.
ex) if ( ((a + b) / (c + d)) == 0 )

- paranthesis '('과 ')' 안에 들어가는 문자, 숫자의 길이가 짧을 경우 paranthesis와 붙여쓰고, 그렇지 않을 경우 한칸띄어준다. 

-  ‘,’ 뒤에 새로운 줄이 시작되지 않는 경우, 다음 항목과 한 칸을 띄운다.

- Binary operator의 경우 operator의 양쪽에 한 칸을 띄운다. (주의: ->, ., [] operator는칸을 띄우지 않는다.)

- Unary operator의 경우 operator와 operand 사이를 붙인다.

- ( )가 nesting되어 나타나는 경우, 최대한 readability를 고려하여, 빈 칸을 띄운다.








1. 헝가리식 표기법이란?

변수의 이름을 정할 때 이름만으로도 변수의 타입을 알 수 있도록 접두사(Prefix)를 붙이는 방법이다.
마이크로 소프트에 다니던 헝가리 사람인 찰스 시모니(Charles Simonyi)가 개발한 것으로 마이크로소프트에서 작성된 모든 코드는 이 규약을 따른다.



2. 헝가리식 표기법 예


 접두사  자료형
 c  char
 by  BYTE(unsigned char)
 n  숫자 (short or int)
 i  int
 x, y  short(x좌표, y좌표로 사용)
 cx, cy  short(x, y 로 사용, c = count)
 b  BOOL(int)
 w  unsigned int or unsigned word
 l  long
 dw  unsigned long (Dword)
 fn  function
 s  string
 sz, str  0으로 끝나는 문자열
 lp  32-bit long pointer
 h  handle
 msg  message




3. 헝가리식 표기법의 사용 논란

헝가리식 표기법은 코딩 작업을 할 때 버그가 될 수 있는 에러를 방지해 주는 이점을 가지고 있지만 C++ 과 같은 객체지향 언어에서는 사용하지 않는 편이 낫다는 의견들도 있다.  



HD 느슨한 형식의 언어로 되돌아가는 추세를 감안하여 헝가리식 표기법 사용을 다시 고려해야 하는 것일까요?
BS 그러한 추세가 있는지는 확실하지 않습니다만 전체 작업 중에서 느슨한 형식의 언어가 맞는 작업이 증가하고 있는 것 같습니다.다른 말로 하면 필자의 생각으로 정적인 형식의 언어 사용 역시 증가하고 있지만 느슨한 형식의 언어 사용이 더 빠른 속도로 증가하고 있는 것 같습니다.그리고 헝가리식 표기법은 사용하지 마십시오.헝가리식 표기법은 좋지 않은 아이디어입니다.소스 코드는 형식 시스템을 시뮬레이션하는 것이 아니라 프로그램의 의미를 반영해야 합니다.정말로 헝가리식 표기법이 필요하다고 느낀다면 응용 프로그램에 맞지 않는 언어를 사용하고 있는 것일 수 있습니다.

- MSDN 매거진 4월호에 C++을 만든 Bjarne Stroustrup의 인터뷰 中 - 




 



Naming Conventions
1. Naming conventions

1) Name은 의미를 쉽게 파악할 수 있도록 한다.
- Underscores를 이용해 단어를 구분한다.

2) 각 Name은 식별이 보장되도록 한다.

3) 혼동될 문자는 가급적 사용하지 않도록 한다.

4) 발음 상 혼동이 되는 Name의 사용을 피한다.

5) Global 변수는 등록한 후 임의 갱신을 피한다.

6) 약어(abbreviations)의 사용을 자제한다.
- 빈번한 사용시에는 의미를 설명한뒤 사용한다.
- 불분명한 약어는 사용하지 않는다. 
※ Naming convention은 project의 특성상 사용하는 tool, 다른 library와의 호환성, 표준 API등에 의해 영향을 받는다.



2. Underscore 와 Field naming convention

멤버 Field의 네이밍 가이드 라인에서 언더스코어(_, underscore)의 사용에 대한 의견이 분분하다.

언더스코어를 사용하는 개발자는 대/소문자로 구별하는 field/property가 익숙하지 못하다.
언더스코어를 싫어하는 개발자는 _가 사족 같다라는 느낌을 지울 수 없다.











가령

1. 언더스코어 사용 규칙

class Person{
private int _age;
public int Age
{
get{return _age;}
set{_age=value;}
}
}


2. 마이크로 소프트 프레임워크 규칙

class Person{
private int age;
public int Age
{
get{return this.age;}
set{this.age=value;}
}
}


1번과 2번의 규칙 어떤것이 좋냐에 대한 의견이다.

1번은 C, C++ 또는 MFC에서 헝가리안 표기법의 멤버를 나타내는 m_ 에서 m을 제거하고 표기하는 규칙으로,  옹호론자들은 명백하게 노출하지 않을 멤버 필드임을 코딩시에 알 수 있다 이다.

2번의 옹호란자들은 Visual Studio IDE를 사용할때 , 직관적으로 나열되므로 코딩에 편하다. 이다.

1번의 단점은 코딩시에 의미 없는 언더스코어의 나열을 봐야 하는 것이다. 2번의 단점을 멤버임을 대소문자로 구분하기가 약간 힘들다는데 있다. 또한 C#코드에서 대소문자를 구별하지 않는 VB등으로 변환시에 문제가 발생할 수 있다는 점이다.

1번 2번 모두 장단점에 대해 분명하게 말하기는 힘들지만,  2번 스타일을 권하고 싶다.

Field의 이용시에는 명확하게 this 키워드를 이용하며, 인텔리센스의 도움을 더 잘 받기 때문이다.



1. File Layout

 앞서 설명한 File heading 에 이어 다음의 내용을 적어준다.

/** ***************************************************************************** **
 ** includes                                                                                                         **
 **  ***************************************************************************** **/
include 되는 헤더파일을 작성.
파일 위치 경로는 makefile 에 작성.



/** ***************************************************************************** **
 ** defines                                                                                                           **
 **  ***************************************************************************** **/
#define 이용한 constant, function macro 의 순서로 작성.


/** ***************************************************************************** **
 ** typedef                                                                                                           **
 **  ***************************************************************************** **/
스트럭쳐.


/** ***************************************************************************** **
 ** globals                                                                                                           **
 **  ***************************************************************************** **/
2개 이상의 파일에서 공유되는 전역변수.


/** ***************************************************************************** **
 ** locals                                                                                                             **
 **  ***************************************************************************** **/
이 파일에서만 사용되는 변수.


/** ***************************************************************************** **
 ** forward declarations                                                                                        **
 **  ***************************************************************************** **/
함수 프로토 타입정의



2. Function Comments

- 각 function definition 에 관한 정보 작성.
- 각 function definition 의 앞부분에 위치.

-  형 태

   /** ************************************************** **
    ** Functions : Function name                                    **
    ** Synopsis : Function 이 사용하는 알고리즘 등을 기술  **
    ** External Effects : 참조되는 전역변수                       **
    ** Parameters : 파라미터의 의미                                 **
    ** Return : 리턴값 및 의미                                            **
    ** Error : 에러 발생시 리턴되는 값과 의미                       **
    ** *************************************************** **/



3. Layout

3.1 Source File

 - 한줄에 하나의 명령문 사용.
 - 한 line 은 80 column 을 넘지 않는다.
 - 한 function 내의 실행문은 300 ~ 500 라인을 넘기지 않는다.(주석포함시 600 ~ 1000)

 


1. Comments의 분류

Comment는 Block Comments와 End-line Comment로 분류.

1.1 Block comments 사용 경우
   - File의 시작
   - Function definition의 시작
   - Statement 앞
   - Declaration등이 grouping이 가능한 경우
   - Pseudo-code로 algorithm을 기술하는 경우 등

1.2 End-line comments 사용 경우
   - Data declaration & definition
   - Block의 끝 (예: for, while, if등의 compound statement의 길이가 길 때)
   - #endif

2. Prologue

소스파일, 헤더파일, makefile 등의 파일 맨 앞부분에 붙여준다
2.1 Prologue 내용
- Project name (Project 일 경우)
- Copyright or Copyleft 에 대한 내용
- File name
- 작성자에 대한 정보
- revision (수정 정보)
- 그외의 정보

2.2 Prologue 예시 
/*
* Project Name : _______
*
* Copyright _year 저작권자__
* ___저작권에 관한 내용_____
*
* author : 작성자
* File Name : 파일이름
* Revision History : 수정된 정보
(Date, ver, Name, Description)
Description : 파일 관련정보
*/


 

소개
 

안녕하세요 ^^
18-2기 유광현입니다.
다른분들 포스팅을 보니 여느 강좌들 못지 않은 유익한 정보들이 많더라구요 !!

저도 그런 유익한 정보 제공을 목적으로 했어야 하는데,
시그의 성격을 잘못 이해한것인지 ;;
저의 목표달성을 위한 무언가 철저하게 이기적인 느낌이 나는 주제로 정해버렸네요 ;

제 포스팅 주제는 Code Convention(코딩 규약) 이구요
지극히 개인적인 주제 선정이유를 말하자면,,,
제가 코드를 예쁘게 짜는 편이 아닙니다 ㅠ ..
나름 신경쓴다고 해보지만 .. 
이리저리 에러고치고 추가하다보면 제가 원하는 모양새가 나오지 않더군요.
해서, 간지코드(?)를 구현해 보고자 Code Convention 문서를 몇개 다운 받아놨었는데요.
게으름병이 돋는 바람에 자꾸 읽는 것을 미루게 되더라구요 ^^;
마침 좋은 시그도 생겼기에 이참에 읽어보고 코딩 습관을 고쳐보고자 하는 마음에서 정하게 되었습니다. 

저처럼 코딩습관을 고쳐보고자 하시는 분들에게 이포스팅이 도움 되었으면 하네요.

첫 포스팅이라 사설이 좀 길었네요 ^^;
오늘은 간단하게 코딩규약이 필요한 이유와 앞으로 포스팅에 활용될 문서들에 대한 정보를 알아보도록 하겠습니다.

포스팅시 사용되는 문서 정보
-  GNU Coding Standard
-  Coding Style Guideline by 삼성전자 주식회사
-  Recommended C Style and Coding Standards version 3.0 by 유창모
- 위의 문서는 모두 C를 기반으로 작성된 문서임.

1. Code Convention 을 꼭 지켜야 하는가?

아니다. Code Convention 은 여러 단체에서 각자 규정하고 있다. 따라서 일정하게 통합된 것은 없으며 어느것이 우수하다는 판단 기준도 없다. 따라서, 꼭 지켜야 하는 강제성은 없지만 일반적으로 지켜주는 것이 좋다.
(이 포스팅에서는 몇개의 문서의 내용을 통합하여 작성할 예정.)


2. 왜 Code Convention 이 필요한가?

Code Convention 은 소프트웨어 개발 단계 중 구현단계에서의 가장 중요한 산출물인 source code를 위한 coding style을 표준화하는 것을 목표로 한다. 이러한 목표를 이루는 것과 동시에 다음과 같은 효과를 얻을 수 있다.

1) 소프트 웨어의 유지보수 비용 절약
-  실제로 소프트웨어의 lifetime 의 80%는 유지보수에 소요되고 있고, 이에따른 비용도 만만치 않다.

2) 코드가독성 및 이해도 향상
-  Code Convention 을 이용하여 코드 작성시 규격에 맞는 코드를 얻을 수 있고 이에 따라 새로운 코드를 빠르고 완벽하게 이해할 있다.

3) 소프트웨어 유지보수의 편리성
본래의 개발자에 의해서 소프트웨어 개발 전체가 유지되는 소프트웨어는 거의 존재하지 않는다. Code Convention 을 이용하여 코드 작성시 개발 이후에 다른 개발자에 의해 유지보수를 하는데 편리하다.

4) 다른 소스와의 호환성
-   소스 코드를 제품으로 팔려고 한다면, 판매되는 소스는 어떤 다른 소스 코드들과 어울리고 패키지 필요성이 있다.

위의 이로운 효과들로 인해 생산성향상과 소프트웨어의 품질향상을 도모할 수 있다.