본문 바로가기

(비정기) Dlbo's Post

코드 컨벤션. 코드를 구성해 나가는 자신만의 방식.

1. - 언어별 코딩 타입.

각자 프로그래머 마다 자신만의 코딩방식을 가지고 있습니다.

그리고 그 방식은 언어에 따라 차이가 나기도 하지요.



자바 특유의 코딩 스타일입니다.

이클립스에서도 코드 컨벤션을 이런 타입으로 지원하고 있고,

자바의 특징점인 "내부 무명 클래스(Inner Anonymous Class)"에도 적합한 코딩 스타일입니다.



으흠...

이 방식은 C와 C++의 고유 코딩 스타일입니다.

아 참... 두 방식의 차이점이 뭐냐구요?

바로 대괄호 {와 }의 위치 차이입니다.

보이시죠?

Java의 경우 {가 줄의 끝에 달려있고,

C/C++의 경우 {가 다음 줄의 첫 부분에 달려 있습니다.

Java의 경우는 아까 말씀드렸듯, "내부 무명 클래스(Inner Anonymous Class)"를 효과적으로

표현하기 위해 이런식으로 변형되었지요.

C/C++은 Java 이전의 언어로, 내부 무명 클래스가 없기도 하거니와,

좀 더 명확한 함수와 블록의 구분을 위해 이런 컨벤션을 취하고 있었지요.

Java의 경우는 저 방식을 이용해야 내부 무명 클래스를 효과적으로 보기 편하게 구현합니다만,

이 때문에 코드가 상당히 보기 난잡해지곤 합니다. 그래도 Java의 대표 IDE인 이클립스는

메서드나 의미블록 단위로 묶을 수 있도록 해 주기 때문에 훨씬 수월하지요.

그렇다고 C/C++의 고유 방식이 유리한것만은 아닙니다.

만약, 함수로 만들기도 애매할 정도로 빈도가 적으나, 코드로 구현하기 엽기적인게 있다 칩시다.

가령 예를 들자면 아래 같은 경우?



.....

이런 경우 코드의 길이 수와 깊이에 따른 굴곡이 심해져서 보기 힘들어집니다.

물론 Java도 이 경우 깊이가 지나치게 깊어지겠지만,

Java 프로그래머들의 코딩방식대로 대괄호를 배치할 경우 보기가 약간 나아집니다.

아, 물론 가독성은 낮아집니다. -_-;

요즈음은 프로그래머들이 Java, C#, C/C++을 마구잡이로 왔다갔다 하느라 각 언어별의 컨벤션은

거의 무시되다시피 하더군요. C++코더가 Java타입의 코딩 컨벤션을 보이고,

Java 코딩에서 익숙치 못한 C 코더가 C방식으로 코딩을 하구요.


2. - 함수에 두는 길이 제한.

제 경우 일반적으로 한 함수에 두는 길이 제한은 10줄정도로 두고, 10줄이 넘을 경우 일부 기능을 다른 함수로

떼어내는 방식을 취하고 있습니다.

아. 물론 PKU나 UVa를 풀때는 제외하구요. 어플리케이션을 개발 할 때 말이지요.

이 경우 함수의 갯수가 지나치게 많아 질 수도 있으나, 각 함수간의 모듈화가 이루어져 함수를 잘만

만든다면 같은 어플리케이션 내의 어디서든 사용할 수 있습니다. 그리고 다른 어플리케이션에서도

쓸 생각이라면 DLL로 띄워서 사용할 수 있지요.

이런 차이점 때문인지 문제를 풀 때는 대부분 루프문을 이용해 처리하지만, 개발에 들어갈땐

거의 재귀함수나 다단계 함수호출이 등장하게 되더군요.

사람마다의 차이점이기도 하지만, 어느 정도 공감가리라 봅니다.


3. - 덧셈, 뺄셈, 곱셈, 나눗셈 등의 연산과 루프문 표현.



제 경우 연산자는 모두 한칸 띄워서 처리합니다.

그리고 ,나 ;를 써야 하는 경우, 앞 글자에는 붙이되, 뒷 글자와는 한칸 띄워 기록합니다.

숏코딩의 경우라면 불리하겠지만, 가독성을 높일 경우는 상당히 유리합니다.

코드가 길어지면 길어질수록 눈을 덜 피곤하게 해 주는 효과가 있기 때문이지요.

어느 정도의 규칙성을 지켜주면서 코드를 보기 편하게 해 준다면 그 코드는 상당히 매력적이겠지요?

또한, for문의 경우 저는 단 한줄만 포함되 있더라도 가독성을 위해 {}블록으로 처리해 줍니다.

물론 아무일도 안할 때 빼구요. while문 처리에서 보이지요?

그리고 초기화, 증감 및 조건을 담당하는 소괄호 파트는 명령문에서 한칸 띄워서 처리해주곤 하지요.

4. - 이런 짓거리를 왜 하남요?

으흠...

첫번째 이유를 말씀드리자면 "코드 가독성" 때문입니다.

남들과 공유해야 하거나, 팀단위로 일할 경우 코드 가독성은 매우 중요합니다.

내가 만든 코드를 파트너가 읽지 못한다면 작업이 진전될 수 없겠지요?

두번째 이유를 말씀드리자면, 역시 "팀워크" 때문입니다.

팀 내부에서 누구는 어떤 타입의 코딩을 하는데, 누구는 어떤 타입의 코딩을 한다.

이 경우 코드 컨벤션에 기인한 알고리즘의 구조가 약간씩 변형되는 사태가 일어나서,

팀원들이 서로 만든 코드들이 접합이 되지 않는 문제점이 발생합니다.

가운데서 코드 접합을 하는 우리의 팀장님이나 매니저님은 서류철을 똘똘 말고 팀원들 머리통을

한대씩 퍽~ 퍽~ 때려주시겠지요. -_-;

세번째 이유는, 일관성 있는 코드를 만들기 위함입니다.

초보 프로그래머들의 특성은 코드 컨벤션이 상당히 난해하고 거칠다는 것이며,

이는 독학으로 익힌 프로그래머들의 특성이기도 합니다.(제가 그랬어요 ㄱ-)

가독성 및 디버깅, 팀웍을 위해 한 줄에 한개의 명령 및 연산만 하고,

변수의 갯수가 늘어나더라도 읽기 좋고 이해하기 쉽게 처리함으로써

자신의 코드에 일관성을 부여할 수 있고, 이로 인해 알고리즘의 일관적인 형태도 만들어 낼 수 있습니다.

학교 동기중에 코드 구성능력은 상당히 대단한 동기가 하나 있습니다만...

코드 컨벤션이 영 엉망이라 그런지 알고리즘 구성은 좀 안되더군요.

그런데 작년 스터디그룹때 코드 컨벤션을 어느정도 맞춘 후로는

그룹 내에서 제가 주력으로 밀어붙이던 알고리즘 구성에서도 제가 밀리더라구요 -_-

프로그래머의 습관을 결정짓는 코드 컨벤션! 주의합시다~