You are viewing an old version of this page. View the current version.
Compare with Current ·
View Page History
코딩 관례(convention)
Convention의 뜻은 관습, 관례이다. 코딩 컨벤션이란 프로그램의 소스 코드 작성 시 코딩 방식과 규칙을 정하고 그것을 따름을 의미한다.
무조건 따라야 할 절대적인 이유는 없지만, 몇 가지 장점이 있기에 대체로 프로젝트를 시작할 때 미리 규약을 정의하고 개발자들이 따르도록 하는 경우가 많다.
코딩 방식(style)
인간은 저마다 개성을 가진 고귀한 존재이므로, 소스 코드 작성 시에도 그 개성을 나타낸다. 같은 로직을 표현하는데도 다른 외관이 나타날 수 있는데, 사실 컴파일러가 코드를 해석하는데는 아무 상관이 없다.
프로그래밍 언어마다 전통적이고 유명한 코딩 방식이 존재하고, 개발자는 보통 그 중 하나를 택하여 그대로 사용하거나, 개인화(customizing)하여 사용하기도 한다.
가끔 코딩 방식 없이 일관되지 못하게 짜놓은 코드를 보는 경우가 있는데, 아무리 좋은 로직이라 하더라도 소스 코드의 질이 굉장히 떨어져 보인다.
관례를 따랐을 때의 장점
소스 코드의 가독성 향상
소스 코드를 최초에 작성하는 사람이 존재한다면, 추후에 그 소스 코드를 수정해야 하는 사람 또한 존재할 것이고 그 둘이 같은 사람이라고 보장할 수 없다. 그렇기 때문에 최초 작성자는 본인이 아닌 다른 사람이 자신의 소스 코드를 볼 수 있다는 점과 이해하기 쉽도록 만들어야 한다는 점을 간과해서는 안 된다.
그리고 프로그램은 여러 사람이 함께 만드는 일이 많기 때문에, 각자의 방식으로 소스 코드를 작성하면 전체적인 소스 코드가 일관되지 못하게 된다.
결국 유지보수에 있어서 관례를 따르는 것은 충분한 장점이 있다.
소스 코드의 품질 향상
소스 코드를 깔끔하게 작성하게 되면 그 소스 코드를 잘 이해할 수 있게 되고 구조를 파악하기 용이해진다. 흐름을 잘 이해하게 되면 코딩 실수를 방지할 수 있고 잠재적인 버그 발생을 억제할 수 있다.
소스 코드의 품질 향상은 프로그램의 품질 향상으로 이어진다.
관례의 종류
들여쓰기 방식 관례
들여쓰기 방식은 코드 블록의 들여쓰기를 통해 프로그램의 구조를 나타내는 관례이다.
탭, 공백, 들여쓰기 크기
들여쓰기의 크기는 보통 들여쓰기 방식에 독립적이다.
많은 초기 프로그램들은 들여쓰기를 Tab 문자로 사용했다. 간편하고 소스 파일 크기를 절약할 수 있기 때문이다. (Tab 문자 하나가 4칸의 들여쓰기를 한다고 치면 Space 문자는 4개가 필요함.)
일반적으로 유닉스 편집기는 탭을 8개의 문자로, 매킨토시와 MS 윈도우즈는 4개의 문자로 본다. 그래서 코드를 옮길 때 혼란을 가중시킨다.
현대의 프로그래밍 편집기는 종종 임의의 들여쓰기 크기를 사용하곤 한다. 많은 쉘 프로그래밍 언어, 루비, HTML 등에서 들여쓰기 단계마다 공백 두개를 사용한다.
hard tab = 키보드의 탭 키의 원래 기능을 의미한다. (0x9)
soft tab = 소스 코드 편집기에서 지원하는 기능으로 탭 키를 임의의 개수의 공백(space, 0x20)로 실시간 치환해준다.
도구
자동으로 들여쓰기 방식을 변경해주는 도구도 존재한다.
들여쓰기 방식
모든 방식을 다 살펴볼 필요는 없을 것 같고, 대표적인 방식 몇 가지를 분석해보겠다.
K&R 방식
자바 코딩 관례에서 사용하는 방식이다. 한국에서 가장 많이 쓰이고 있다고 한다?
Dennis Ritchie(C 창시자)와 Brian Kernighan이 쓴 저서 'The C Programming Language'라는 책에서 사용한 방식으로 C와 C++에서 많이 사용된다.
C++의 창시자인 Bjarne Stroustrup도 이 방식을 사용한다.
public static void main(String[] args)
{
while (x == y) {
something();
if (some_error) {
do_correct();
} else {
continue_as_usual();
}
}
}
각 함수는 선언부와 같은 들여쓰기 수준(level)의 다음 줄에 여는 중괄호(brace)를 가진다.
중괄호 내의 문장은 들여쓰고 닫는 중괄호는 선언부의 들여쓰기 수준에 맞춘다.
하지만 함수 내부의 블록(제어문 등)은 선언부의 오른쪽 끝에 여는 중괄호를 가진다.
장점
함수 내부 블록의 여는 괄호가 따로 한 줄을 차지하지 않아 수직으로 더 많은 코드를 볼 수 있다.
단점
선언부를 주석 처리할 때 조금 불편하다.
GNU 방식
자주 사용되지 않음.
Indented 또는 Whitesmith 방식
자주 사용되지 않음.
Exdented 또는 Allman 또는 BSD 방식
많은 BSD Unix를 위한 유틸리티를 만든 Eric Allman에 의해 이름 붙여졌다.
GNU 방식과 K&R 방식의 장점만을 취한다.
함수 선언문 뿐만 아니라 함수 내부의 블록 또한 여는 중괄호가 선언부 다음줄에 위치한다.
public static void main(String[] args)
{
while (x == y)
{
something();
if (some_error)
{
do_correct();
}
else
{
continue_as_usual();
}
}
}
장점
블록의 시작과 끝이 명확하게 보이기 때문에 가독성이 높다.
단점
여는 중괄호가 항상 따로 한줄을 차지하기 때문에 수직으로 보는 코드양이 적어진다. 아래 위로 스크롤해가며 봐야 함. 인쇄 시 종이의 낭비가 심하다는 경제적인 문제도 있다. 이런 이유들로 예전에는 K&R 방식이 많이 사용되었지만, 고해상도 모니터의 보급화로 인해 점점 Allman 방식을 사용하는 추세이다.
그외
Kernel, 1TBS, Stroustrup, BSD KNF, Whitesmiths, GNU, Horstmann, Pico, Banner, Lisp, Ratliff 방식 등이 존재
주석 관례
추후 작성
명명 관례
추후 작성
잘 알려진 코딩 방식 종류
K&R 방식
자바 코딩 관례에서 사용하는 방식으로 한국에서 가장 많이 쓰이고 있다.
예시
public static void main(String[] args) {
}
장점
단점
Allman 방식
Whitesmith 방식
GNU 방식
이클립스로 소스 코드 작성시 코딩 관례 적용
자바 소스 코드 편집기로는 이클립스 IDE가 독보적으로 사용되고 있다. 따라서 이클립스 상에서 소스 코딩 시 코딩 관례를 적용하는 방법을 살펴보겠다.
Preferences - Java - Code Style
추후 작성
> Clean Up
추후 작성
> Code Template
추후 작성
> Formatter
일요일에 작성
> Organize Imports
추후 작성
코딩 방식을 구분 짓는 요소
코딩 방식은 다음과 같은 요소의 조합으로 결정된다.
들여 쓰기(indent)
블록 지정
(가독성을 위해) 빈줄을 넣는 시기
띄어 쓰기
주석
배열 초기화
식별자 명명 규칙
프로파일 배포
참고
Allman 식 이클립스 Java 코딩 스타일 프로파일
Code Conventions for the Java TM Programming Language
Coding conventions - Wikipedia
Labels