반응형

프로그래머가 자기만의

프로그램 소스코드를 작성한다는 것은

매우 나쁜 습관이다.


물론 혼자서 개발하는 프로그램이라면

이렇게 만들던 저렇게 만들던

만드는 사람 마음이지만

 

현실에서는 여러 명이 협업해서

만드는 프로그램이 대부분이다.

프로그램 개발을 한다는 것은

10명 이하의 프로그래머가

참여해서 진행하는 프로젝트부터

많게는 수십 명 내지 수백 명이 달라붙어

해내는 프로젝트도 있다.

그럴 때 결코 무시할 수 없는 것이

코딩룰(Coding Rule) 내지

코딩 스타일(Coding Style)이다.

코딩룰이 잘 된 팀에서 일을 해보면

다른 사람이 짠 소스코드도

비교적 쉽게 이해할 수 있다.


반면 코딩룰이라곤 듣도 보도 못한 팀에서

일을 하면 차라리 처음부터

내가 소스코드를 다시 짜는 게 낫지란

소리가 나올 정도로

소스코드가 거의 암호문 수준이다.

코딩룰이라고 거창 할 건 없다.

 

하나의 규칙을 가지고

프로그램 소스코드를 짜면 되는 것이다.


좋든 싫든 팀 내에서 정해진 규칙이라면

지켜야겠지만 코딩 룰에도 대부분의 사람들이

좋다고 말하는 규칙이 어느 정도는 정해져 있다.

 

함수명과 변수명 작명법

내가 경험한 바에 의하면 규칙이 크게

오픈소스 계열 스타일과

MS계열의 윈도우즈 스타일로 나뉘는 것 같다.


보통 오픈소스 계열의

리눅스 쪽 소스코드를 보면

변수명이나 함수명을 작명할 때

언더바(_)를 많이 쓴다.

 

반면 MS쪽에서는 Camel표기법이라고 해서

언더바 대신 각 단어의 사이를 대문자로 구분한다.

<오픈소스 계열 예시>
함수명: get_my_name()

변수명: my_name

 

<MS 계열 예시>
함수명: GetMyName()

변수명: myName

나는 MS 계열에서 쓰는 스타일을 선호한다.

 

함수명은 첫 글자가 대문자,

변수명은 첫 글자가 소문자라는데 유의하기 바란다.

 

접두어를 붙이자

접두어를 붙이는 것도

가독성을 높이는데 매우 중요하다.

 

static 변수는 s_ 를 붙인다.

member 변수는 m_ 를 붙인다.

global 변수는 g_ 를 붙인다.

 

<예시>
s_myName

m_myName

g_myName

이렇게 하면 변수를 딱 보는 순간 어떤 변수인지

명확히 구분이 되기 때문에 매우 유용하다.

 

공백을 주자

함수를 호출할 때 인자를 넣는다.

 

그 인자들 사이는 쉼표로 구분하는데,

공백도 없이 사용하는 사람들이 있다.

 

매우 답답해 보인다.

GetMyName(param1,param2,param3)

보다는

GetMyName(param1, param2, param3)


이렇게 쉼표 뒤에 공백을 하나 주면 훨씬 보기 좋다.

연산자의 경우도 마찬가지로 공백을 주는 게 좋다.

 

c=a+b;

보다는

c = a + b;

 

중괄호는 통일성 있게 사용하자.

중괄호를 쓰는 스타일은 보통 2가지 스타일이 있다.

<첫 번째 스타일>
main(){

}        

<두 번째 스타일>
main()
{       
}       

어느 스타일을 사용하느냐는 팀에서 정하기 나름이지만

보통 두 번째 스타일을 많이 선호한다고 한다.

 

중괄호의 열고 닫음이 명확하기 때문이다.

 

굳이 라인수를 줄이려고

첫 번째 스타일을 쓸 필요는 없을 듯하다.

이 외에도 인터넷에서

코딩룰 내지 코딩스타일이라고 검색해보면

기술적으로 많은 문서들이 있다.

 

보통 처음 프로그램을 짜는 사람은

코딩룰이라는 것에 대해 잘 모르거나

별로 중요하지 않게 생각한다.

하지만 코딩룰은

팀 단위의 프로젝트에서는

반드시 필요하고

 

프로그램 소스코드의 가독성을 높여

생산성 향상에 크게 기여한다.

반응형