Allman 식 이클립스 Java 코딩 스타일 프로파일

어떤 자바 코딩 스타일을 쓰시고 계신가요?

특별히 선호하는 스타일이 없으시다면 아마도 자바 코딩 규약을 따르시겠죠?

코딩 스타일이라고 하면 여러 가지가 고려할 것들이 있습니다. 들여쓰기를 어떻게 하는지, 블럭 지정은 어떻게 하는지, 언제 줄을 나눌 것인지, 띄어쓰기, 코멘트, 배열 초기화, 심지어 이름 정하는 규칙까지......

이런 여러 요소가 있지만 보통 코딩 스타일을 분류할 때에는 들여쓰기와 블럭 표현 방법을 주로 봅니다. 아마도 이 두 가지가 코딩 스타일의 외형에 가장 큰 영향을 주기 때문인 듯합니다. 몇몇 대표적인 블럭 표현 방법에는 따로 부르는 이름까지 붙어 있지요.

제가 프로그래밍을 배우기 시작할 때에는 베이식, 어셈블리, 포트란, 코볼 같은 언어들을 주로 사용했기 때문에 요즘과는 다른 코딩 스타일을 썼었습니다. 언어 구조가 좀 다르니까요. 제가 배운 베이식은 서브루틴 같은 것도 없었거든요. ^^

처음으로 배운 구조적 언어는 Pascal입니다. Apple II에서 돌아가는 UCSD Pascal이 있었는데 p-System이라는 가상 머쉰 위에서 p Code라는 중간 코드로 컴파일 되는 언어입니다. 지금 우리가 쓰는 자바 가상 머쉰과 비슷한 놈이었죠. 좀 다른 것은 JVM은 OS 위에서 돌아갔지만 p-System은 OS까지 포함하고 있습니다. 그다음에는 CP/M이라는 OS에서 Turbo Pascal로 프로그래밍을 했었고요.

좌우간 이런 이유로 Pascal처럼 블럭의 시작과 끝이 명시적인 Allman 스타일의 블럭 표현 방법을 선호하게 되었나 봅니다. K&R 스타일은 블럭의 시작 기호와 끝 기호를 신경 써서 주목하지 않으면 찾기가 힘들더라고요. 물론 요즘은 IDE를 쓰기 때문에 자동으로 찾아주기는 하지만 최근까지 VI로 개발했었기 때문에 이 스타일이 아니면 코드를 전혀 보지 못하는 지경입니다.

대표 Indent Style

말을 시작했으니 대표적인 코딩 스타일을 몇 가지 적어볼까요? 마침 위키 백과에 잘 정리가 되어 있군요.

K&R 방식

for (int i = 0; i < 10; i++) {
    s = s + i;
    if (s > 10) {
         ......
    } else {
         ......
}

자바 코딩 규약에서 사용하는 방식입니다. 우리나라에서는 이것이 가장 일반적인 듯합니다. C를 만든 커닝핸과 리치씨의 "The C Programming language"라는 책에 사용된 코딩 스타일이지요. 이 책 한 권씩 안 사본 사람이 없을 듯한데 요즘은 모르겠군요. 제가 처음으로 산 원서 같기도 하고...... 들여쓰기는 원래 8칸이지만 요즘은 4칸을 주로 씁니다.

이것의 변형으로 BSD KNF Style이 있다네요. 보통 kernel style이라고 부르는 놈입니다. 저는 이것과 K&R이 같은 것인 줄 알았는테 텝이 조금 다르군요. 하드 탭(탭문자)는 8칸으로 보이게 설정하고 소프트 탭(어이지는 공백 여러개로 탭을 표현)은 공백 4개로 설정합니다. 밑에 제 스크린샷 중 첫번째에서 Tab Policy를 Mixed로 하고 Use tabs only for leading indentations를 체크한 후에 블럭 들여쓰기 할 때에 tab을 두번 치면 비슷해질 듯 하네요.

이렇게 탭을 설정하고는 블럭을 들여쓸 때에는 하드탭으로 이어지는 줄을 들여쓸 때에는 소프트탭으로 처리한다고 합니다.

Allman 방식

for (int i = 0; i < 10; i++)
{
    s = s + i;
    if (s > 10)
    {
         ......
    }
    else
    {
         ......
    }
}

Sendmail과 많은 BSD 유틸리티들을 만든 Eric Allman의 코딩 스타일입니다. BSD Style이라고도 불렀었습니다. 원래는 들여쓰기를 공백 8칸으로 하는데 요즘은 4칸으로 합니다.

보시면 알겠지만 블럭의 시작과 끝이 명확합니다. 가독성이 높지요. 코드 한 줄씩 정확히 볼 수 있습니다. 단 한 화면에 보이는 코드 양이 많지 않아서 스크롤을 더 해야 하는 단점도 있습니다. 그래서 Cut & Paste 방식의 프로그래밍을 방해해서 저는 좋은데 다른 분들은 모르겠군요.

C에서는 가장 많이 사용하는 방식이라고 합니다.

Whitesmith 방식

for (int i = 0; i < 10; i++)
    {
    s = s + i;
    if (s > 10)
        {
         ......
        }
    else
        {
         ......
        }
    }


Whitesmith C라고 한참 잘 팔리던 C 컴파일러의 코딩 방식입니다. 저는 이 방식으로 코딩하는 사람을 한 번도 못 봤지만 Whitesmith C로 장난질을할 때에 잠깐 접해 보기는 했습니다. 어떻게 보이시나요? Allman 방식에 눈이 익어서 처음에는 적응하기 어렵지만 금방 적응이 되더군요.
이 방식 역시 원래 8칸이었지만 요즘은 4칸을 씁니다.
Allman 방식과 거의 비슷한 수준으로 많이 쓴다고 합니다.

GNU 방식

for (int i = 0; i < 10; i++)
  {
    s = s + i;
    if (s > 10)
      {
         ......
      }
    else
      {
         ......
      }
 }

GNU에서 사용하는 방식입니다. 아마도 리처드 스톨만의 방식이겠죠? Allman과 Whitesmith의 중간형으로 보입니다. 나름의 이유가 분명히 있겠지만 솔직히 전 이 방식을 별로 좋아하지 않습니다.  이렇게 작은 들여쓰기가 반복되면 가독성이 떨어지더군요. 눈이 어지럽습니다. 보통 2칸씩 두 번 들여씁니다.

위키 백과에는 pico 방식과 banner 방식도 설명하고 있는데 이것들은 그렇게 많이 쓰이지 않으므로 넘어가겠습니다.

이클립스 자바 코드 스타일 프로파일

좌우간 제가 이 글을 쓴 이유는 이런 방식 중에 제가 쓰는 allman 방식의 이클립스용 코딩 스타일 프로파일을 공개(?)하려는 것입니다.
혹시 allman 방식을 좋아하시는 분이 있다면 받아서 쓰세요. 제가 쓰던 것을 약간 손 봐서 올립니다.

allman.zip

이 파일을 내려 받아 압축을 푼 후에 이클립스의 자바 코드 스타일 프로파일로 등록 하십시오.

Window > Preferences > Java > Code Style > Formatter 에서 Import 하시면 됩니다.

설정 내용


간단히 설정 화면 갈무리한 것을 올려보겠습니다.

들여쓰기

들여쓰기는 공백 4칸입니다. 탭을 4칸으로 표시되도록 하는 방식은 다른 에디터에서 보면 다르게 보이기 때문에 탭은 8칸으로 보이게 했습니다.
저는 에디터를 고를 때에 들여쓰기를 탭 문자가 아닌 공백으로 처리할 수 있는지를 꼭 확인합니다.

대괄호

이 부분에서 Allman 방식의 대표 특징을 부여합니다.

빈 줄 삽입

널찍널찍한 코드가 가독성이 좋지요. ^^
가독성이 떨어지면 코드를 통제하기 힘들어지고 버그도 많이 생깁니다. cut & paste 해 놓고 "잘 돌아가던 코드인데 왜 안 돌아가지?" 하는 사람 많이 봤지요. 프로그래머는 코드 한 줄에 책임을 져야 하는 거라고 생각합니다. "네가 만들어 놓은 코드를 가져다 썼는데 작동 안 되니 네가 책임져"라고 말하는 프로그래머 보면 참 답답합니다. 자기가 제다이인 줄 알고 감으로 프로그래밍하죠.

줄 나누기

자바 코딩 규약과 비슷합니다. (아마도... ㅡ.ㅡ);


제어 코드

이 부분도 기본은 널찍널찍...


긴 줄 나누기

80칸에 맞춰서 긴 줄을 나누게 설정했습니다. 요즘은 화면이 넓으니 화면 가득한 크기로 에디터를 키우고 프로그래밍하는 사람들이 많습니다. 요즘 같은 시대에 누가 터미널을 쓴다고 80칸에 맞추느냐고 말하는 분들 많지요. 자바 코딩 규약에 쓰여 있는 것처럼 다양한 환경에서도 같은 모습을 유지하려면 80 칸에 맞추는 관례를 지키는 것이 좋기는 하지요.
저는 조금 다른 이유로 여전히 80칸에 맞춰서 코딩합니다. 가로로 길게 늘여 놓으면 눈에 잘 안 들어오기 때문입니다. 눈알을 이리저리 계속 굴려야 하거든요. 제가 노안이라서 그런가요? :-)
한번 해보세요. 진짜 코드에 대한 장악력이 높아집니다. 제 생각에 80칸 규칙을 에디터가 제한하도록 설정하는 것은 별로 좋은 것 같지는 않습니다. 어떤 줄은 이름이 너무 길다거나 해서 80칸을 넘는 것이 오히려 나을 수도 있으니까요. 그냥 기준선만 표시하고 프로그래머가 그런 습관을 지키도록 하는 것이 좋다고 생각되는데 일단 이 프로파일에서는 강제로 줄 나누기 하도록 했습니다.


주석 처리

이 부분은 그냥 제가 좋은 쪽으로 했는데 뭘 고쳤는지 모르겠네요.  ㅡ.ㅡ;


따~라 라~라 랄랄랄라 랄랄랄라~
따라라 라~라~ 라~



감사합니다. 혹시 문제가 있으면 리플 달아주세요.


by 박성철 | 2008/01/18 16:04 | 프로그래밍 이야기 | 트랙백(19) | 핑백(1) | 덧글(17)

트랙백 주소 : http://gyumee.egloos.com/tb/1306012
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 최익필의 이름없는 블로그 at 2008/09/07 15:45

제목 : 항목 47 : 쓰기 전용(write-only) 코드..
내가 STL에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve STL 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다. - 최익필 처음 나는 쓰기전용 코드라 하길래, 무슨 말인고 했더니, 코드를 쓰기가 편한데로 쓴 코드를 쓰기 전용(write-only) 코드라고 한다. 즉 이런 코드... vector v; int x,.....more

Tracked from Confluence: .. at 2014/08/01 00:58

제목 : 7012. 프로젝트 코딩 컨벤션
    코딩 컨벤션 Convention의 뜻은 관습, 관례이다. 코딩 컨벤션이란 옛날부터 ...more

Tracked from Confluence: .. at 2014/08/02 23:10

제목 : 7012. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/02 23:13

제목 : 7012. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/03 15:16

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/03 22:02

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/04 00:39

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 09:43

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 09:46

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 10:33

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 10:36

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 10:44

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 11:00

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 11:11

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 11:20

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 15:37

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/06 15:42

제목 : 7015. 프로젝트 코딩 관례
BaroBoard.xml   코딩 관례(convention) Convention의 뜻은 관...more

Tracked from Confluence: .. at 2014/08/06 15:47

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Tracked from Confluence: .. at 2014/08/07 10:30

제목 : 7015. 프로젝트 코딩 관례
    코딩 관례(convention) Convention의 뜻은 관습, 관례이다. 코딩 ...more

Linked at 프렐루드의 잡담방 : 이클립스.. at 2011/07/25 11:43

... http://gyumee.egloos.com/1306012 ... more

Commented by 코난도일 at 2008/01/19 03:51
저도 모르고 있었는데, 저의 코딩 스타일은 allman 방식이었네요. 좋은 글 잘 읽고 갑니다.^^
Commented by 래퍼백곰 at 2008/01/19 18:39
잘 정리된 글 흥미있게 읽었습니다.

저는 Sun의 스타일을 선호합니다.
allman은 너무 길어져서 코드 볼 때 부담스럽더군요..
제가 눈이 안좋아서 폰트를 크게 해놓고 쓰기 때문에 더욱 그런듯.. ^^;

메소드를 최대한 짧게 유지하면 K&R 방식(Sun 스타일)이 가장 편합니다.

아무튼 코딩스타일은 프로젝트 성격, 사용 언어, 팀원의 선호도 등에 따라
최적화해야 된다고 생각해요.. ^_^
Commented by 박성철 at 2008/01/19 23:13
코난도일님// 감사합니다. ^^
레퍼백곰님// 안녕하세요. 블로그 잘 보고 있습니다. K&R을 좋아하신다니 집중력이 좋으신가봐요. 어디까지나 개인의 취향이나 성격의 문제이나 정답은 없는 것이죠. ^^
Commented by 소내기 at 2008/01/22 10:39
얼마전까지 코딩스타일을 적용해서 정리를 했는데, 어노테이션과, StringBuffer에서의 append드를 뒤죽박죽해놓는걸 보고서는 그만두었습니다--;
Commented by 박성철 at 2008/01/22 11:40
소내기// append는 이해가 가는데 애노테이션은 왜? 문제가 되는 코드를 함 보내줘봐요. 그리고 솔직히 자동 포맷 기능 보다는 좋은 습관을 갖는게 좋죠. 자동 포맷은 아무래도 제한이 있으니까.
Commented by 소내기 at 2008/01/22 12:52
@RequestParameter("id") Integer id,
@RequestParameter("test") String test,
Controller에서 메소드 args에 넣게 되면.
@Request....
Integer id, @RequestParameter("test")
String test,
이런식으로 엇갈리게 되더군요.
Commented by 박성철 at 2008/01/22 14:10
그건 이클립스의 한계라고 봐야 할듯 하네요. 미처 패러미터에 애노테이션을 넣을 것은 생각하지 못한듯... 나도 자동 포맷은 거의 안써요. 자동 포맷을 하더라도 다시 손을 보죠.
Commented by aya5 at 2009/01/03 01:25
좋은 글 잘 읽었습니다.

저도 이클립스에서 사용하는 저만의 코드 스타일이 있는데
(K&R 베이스에 커스터마이징되었습니다.)
정의하고 저장한 템플릿 xml을 도대체 어디서 찾을 수 있는지요?;;
그걸 도무지 못찾아서 프로젝트가 시작할때마다 매번 애먹네용...
Commented by 박성철 at 2009/01/05 16:52
aya5님
이클립스의 Preferences>Java>Code Style>Formatter>Edit 에서 Export를 하시면 됩니다. ^^
Commented by 정세훈 at 2009/03/25 09:22
감사합니다.
allman 방식을 찾고있었습니다!!
아직 이클립스 초보입니다. ^^
Commented by 박재훈 at 2009/12/11 11:39
정말 감사합니다.
필요하던 자료를 찾게되서 정말 기쁩니다.
Commented by 자바초보 at 2010/10/18 23:22
위키백과에 아무리 찾아도 없던데 검색어를 뭘로해야 하나요??
Commented by 박성철 at 2010/11/04 17:44
글세요. 여기에 있는 단어들 조합하면 나오지 않을까요?
그냥 coding style은 어떤가요?
Commented by brjunny at 2013/02/05 11:28
감사합니다! 코딩스타일을 딱 정해서 연습하고 싶었는데 많은 도움이 되었네요.
괜찮으시다면 인용해서 글 게시해도될까요?
Commented by 박성철 at 2013/02/16 03:39
아! 물론입니다.
방치하는 블로그에 방문해 주셔서 고맙습니다.
Commented by 벤지 at 2013/07/08 05:00
감사합니다....(ㅡㅡ)(__)
Commented by 담아가요 at 2014/06/17 14:30
출처밝히고 담아갑니다. 좋은 정보감사합니다.

:         :

:

비공개 덧글

◀ 이전 페이지다음 페이지 ▶