자바 코딩 스타일...

이한길의 이미지

다들 어떻게 하시는지 궁금하네요...

저는 보통....

void test()
{
}

이런식인데... 일반적으로는...

void test() {
}

이렇더군요. 책들도 그렇고 자바 튜토리얼의 소스들도 그렇구요...
혹시 줄을 아낄려구 그랬나 했더니... 템플릿들도 그렇더군요...

다들 어떻게 하시는지 궁금합니다.

댓글

랜덤여신의 이미지

저도 한길님처럼 합니다. :)

뭐... 정해진 표준은 당연히 없겠지만...
예전에 어떤 유명한 책에서, 중괄호를 줄 뒤에 바로 이어쓰는 방식으로 썼기 때문에, 많은 사람들이 저렇게 쓰게 되었다고 알고 있습니다...

뭐, 각자 편한대로 쓰면 되겠죠... 8)

jachin의 이미지

저도 한길님 스타일입니다. ^^;;;

전 공백 넣는것을 무척 좋아해서, 괄호에는 꼭 빈칸 하나씩은 들어가죠. ^^;;

neocoin의 이미지

bluenux의 이미지

저는 C언어를 코딩할때에는 한길님처럼 합니다,

그런데 자바를 코딩할때는 아래예문처럼 코딩하게 되더라구요...ㅡㅡ;;;;;

어떻게 배웠냐의 차이겠지요...

chadr의 이미지

저도 한길님처럼 합니다..

두번째 스타일은 왠지 여러 문장이 겹쳐있을때
들여쓰기가 제대로 안되어있으면 영 보기가 껄끄러워서리..

소스 볼일이 있어도 두번째 같이 되어있으면 모조리 한길님 스타일같이 고쳐서 보곤합니다..

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

warpdory의 이미지

제가 좀 특이한지는 몰라도...

void test()
        {
        }

이런 식으로 했었습니다. 이제는 더이상 저렇게 짤 일은 없겠죠.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

cppig1995의 이미지

의 스타일과 같군요. 네. 저 책 보면서 고생했습니다.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

Vadis의 이미지

저는 간혹 가다...

Quote:
test(){.......}

기분 내키는대로 합니다. 혼자서 연습할 때만요...

좋은 날 즐거운 날....

해밝의 이미지

public class FooClass
{
  private String foo;

  public FooClass()
  {
  }

  private void init()
  {
  }

  public String getFoo()
  {
    String result;

    if(foo != null)
    {
      result = this.foo;   
    }
    else
    {
      result = "blah~~";
    }
    
    return result;
  }
  
}

이렇게 씁니다. 주로 오픈소스 코딩 가이드에 맞춰서 작성합니다.
자바의 경우 이 규칙을 지키지 않은 코드는 Eclipse에서
Ctrl + Alt + F 키를 사용하면 알아서 맞춰주더군요.

그렇게 해서 씁니다. ^^

sDH8988L의 이미지

저도 한길님 처럼 중괄호를 내려 쓰는 스타일 입니다...

중괄호를 뒤에 두면, 함수의 범위를 아는데 좀 불편하더군요...

끝 중괄호는 알겠는데, 시작 중괄호가 잘 안보인다고나 할까요...

뭐... vi에서는 %로 바로 찾을 수 있다고 하지만, 일단, 눈에 확연히 보이는 것이

더 좋겠죠...

저는 C, C++, Java 등등 모든 Lang에서 그렇게 씁니다...

fender의 이미지

poopu wrote:
자바의 경우 이 규칙을 지키지 않은 코드는 Eclipse에서
Ctrl + Alt + F 키를 사용하면 알아서 맞춰주더군요.

이클립스에서는 기본 컨벤션과 자바 컨벤션 중 선택 가능합니다. 원하면 매우 세세하게 자신만의 컨벤션을 설정해서 사용할 수도 있습니다. xml로 export해서 팀원들끼리 공유하면 편하더군요 :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

불량청년의 이미지

이렇게는 안쓰시나요?

int
main(void)
{
}

스티븐슨의 책을보면 이렇게 되어 있던데...

H/W가 컴퓨터의 심장이라면 S/W는 컴퓨터의 영혼이다!

youngminny의 이미지

저 역시 tacstar 님의 형식으로 사용합니다.
위 방법이 좋던데... *^^*

bookworm의 이미지

int main(void)
{
    return 0;
}

B/o/o/k/w/o/r/m/

atie의 이미지

Sun의 code convention에 따라, 저는 후자의 formatting rule을 씁니다 (eclipse의 기본 설정도 Java Convention해서 이걸로 되어있죠). 위에 링크도 되었는데... { } 에 대해서만 발췌하면...

Open brace "{" appears at the end of the same line as the declaration statement
Closing brace "}" starts a line by itself indented to match its corresponding opening statement, except when it is a null statement the "}" should appear immediately after the "{"

----
I paint objects as I think them, not as I see them.
atie's minipage

ㅡ,.ㅡ;;의 이미지

void test() {
}

사실 이런건 .... 이게 좋다고하는사람 거의 없더군요..
책에 보면 종종 이렇게 해놨는데.. 책들이 코딩스타일이 엉망입니다.
예제보면 코딩스타일의 일관성도없죠

다떠나서 자신의코딩 스타일을 남에게 강요하는사람 짜증납니다.
소스에 이름 넣기가 싫어진다는...
코딩스타일이 받아들일만한것이면 좋겠는데 문제가 있어 버린스타일을 따라하면 실수의반복이고 미세한부분까지 정해주는것도 아니기때문에 정해지지않은부분에서 충돌(?)이 일어나며..프로그램구조화스타일이나 작성툴에까지도 영향을 받죠..

흔히들 남이 자신이 보기쉬운 스타일로 맞추어 작성하기를 바라는경향도 있는데
자신은 남의것을 제대로 볼줄도 모르면서 남한테 자기의스타일을 강요하는 어리석은행동을 흔히 하는사람이 있죠.
자기가하는것이 다 인양 남에게 강요하지 맙시다..스타일이란 자신만의 스타일인것을..(다같다면 무슨재미가 있고 무슨발전이 있겠는가..)


----------------------------------------------------------------------------

fender의 이미지

ㅡ,.ㅡ;; wrote:
void test() {
}

사실 이런건 .... 이게 좋다고하는사람 거의 없더군요..
책에 보면 종종 이렇게 해놨는데.. 책들이 코딩스타일이 엉망입니다.
예제보면 코딩스타일의 일관성도없죠

다떠나서 자신의코딩 스타일을 남에게 강요하는사람 짜증납니다.
소스에 이름 넣기가 싫어진다는...
코딩스타일이 받아들일만한것이면 좋겠는데 문제가 있어 버린스타일을 따라하면 실수의반복이고 미세한부분까지 정해주는것도 아니기때문에 정해지지않은부분에서 충돌(?)이 일어나며..프로그램구조화스타일이나 작성툴에까지도 영향을 받죠.


전 좋은데요? :) 그리고 ㅡ,.ㅡ;;님께서 그런 스타일을 싫어하신다고 그 스타일이 '문제가 있어 버린스타일'이나 '엉망'이 되는 건 아닙니다. 내가 빨간색을 좋아한다고 파란색이 빨간색 보다 부족한 색깔이 되는게 아니지요...

그리고 자바 쪽에서는 그런 스타일이 가장 일반적이고 물론 나름의 일관성이 있습니다. 코딩 스타일은 전적으로 취향입니다.

다만, 한 가지 이야기 하고 싶은 건 프로젝트 규모가 커질 수록 코딩 스타일을 강제하는 것이 필수적이라는 점입니다. XP에서 흔히 말하는 코드의 공동 소유 개념도 확연히 다른 코딩 컨벤션이나 사용하는 라이브러리 등이 달라서는 적용하기 불가능합니다.

무엇보다 경험상 코딩 컨벤션을 강제했을 때 프로젝트가 진행되어 갈 수록 다른 사람이 짠 코드가 자신이 짠 것 같이 느껴질 정도로 별 거부감이 없어 가독성을 높일 수 있고 유지보수가 쉬워 지더군요.

GNU에서도 코딩 컨벤션은 물론 문서 작성, CVS 주석 다는 요령까지 자세히 매뉴얼화 하고 있습니다. 그 만큼 어느 정도 표준화가 되면 유리한 점이 있다는 뜻입니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

elflord의 이미지

저도 한길님 스타일입니다만... 취업초기에 선배님들 스타일이 전부

void test() {
}

라서...고생많이 했습니다. 사실 스타일 통일은 필요하니까요.

지금은 제가 짠밥좀 되서 위에 설득하고 밑에 강제해서 제스타일로
통일시킵니다.


===== ===== ===== ===== =====
그럼 이만 총총...[竹]
http://elflord.egloos.com

atie의 이미지

Code Conventions을 규정해서 coding style을 표준화하는 것은 팀 단위 개발에서는 기본적인 것이라 생각합니다. 프로그램 생명주기에 유지보수가 차지하는 비중이 높고 원저자가 유지보수를 끝까지 책임지는 것이 아닌 마당에 누구나 봐서 가독성이 높겠다 쉽게 기존의 것을 사용하거나 또는 새로운 coding standard를 정하는 것은 타인에게 강요하는 것이 아니라 오히려 타인을 배려하는 것이겠죠. 예를 들어,
http://db.apache.org/ojb/code-standards.html에서 보듯이 이 프로젝트를 위해서 이렇게 표준을 정했으니 이대로 따르고 여기 정의되지 않은 것은 Sun의 관례를 따르라... 이렇게 하면 누가 짜더라도 모양새는 동일한 코드가 나올거라 쉽게 생각이 되지 않나요 그래서 나름대로의 표준을 정하는 것일테고...

또 한가지 생각해 볼 것은, 요즘은 roundtrip이 되는 툴을 이용해서 code를 작성하는데 툴이 작성한 코드가 마음에 안든다고 나는 나대로 고치고 다른 팀원은 다르게 고치고 그러지는 않겠죠.

----
I paint objects as I think them, not as I see them.
atie's minipage

creativeidler의 이미지

if (expr) {
    statement;
} else if (expr) {
    statement;
} else if (expr) {
    statement;
}

if (expr)
{
    statement;
}
else
{
    statement;
}
else
{
    statement;
}

try {
    statement;
    ...
    ...
} catch (Exception ex) {
    log.debug(ex);
} finally {
    close resources;
}

try
{
    statement;
    ...
    ...
}
catch (Exception ex)
{
    log.debug(ex);
}
finally
{
    close resources;
}

전 아무리봐도 썬의 코딩 스타일이 좋네요. 이미 대부분의 오픈 소스 자바 프로젝트가 썬의 컨벤션을 따르고 있는 마당에 굳이 GNU 스타일을 고집하는 이유를 잘 모르겠습니다. 개인 취향이라는 말은 자기 스타일을 바꾸지 않으려는 핑계인 것 같다는 생각도 드는군요. 저도 GNU 스타일로 5년 넘게 코딩했었지만 지금 썬의 스타일이 훨씬 편합니다. 거부하려하지 말고 한 번 적응해보세요. 많은 사람들이 쓰는 게 다 이유가 있습니다.

ㅡ,.ㅡ;;의 이미지

fender wrote:
ㅡ,.ㅡ;; wrote:
void test() {
}

사실 이런건 .... 이게 좋다고하는사람 거의 없더군요..
책에 보면 종종 이렇게 해놨는데.. 책들이 코딩스타일이 엉망입니다.
예제보면 코딩스타일의 일관성도없죠

다떠나서 자신의코딩 스타일을 남에게 강요하는사람 짜증납니다.
소스에 이름 넣기가 싫어진다는...
코딩스타일이 받아들일만한것이면 좋겠는데 문제가 있어 버린스타일을 따라하면 실수의반복이고 미세한부분까지 정해주는것도 아니기때문에 정해지지않은부분에서 충돌(?)이 일어나며..프로그램구조화스타일이나 작성툴에까지도 영향을 받죠.


전 좋은데요? :) 그리고 ㅡ,.ㅡ;;님께서 그런 스타일을 싫어하신다고 그 스타일이 '문제가 있어 버린스타일'이나 '엉망'이 되는 건 아닙니다. 내가 빨간색을 좋아한다고 파란색이 빨간색 보다 부족한 색깔이 되는게 아니지요...

그리고 자바 쪽에서는 그런 스타일이 가장 일반적이고 물론 나름의 일관성이 있습니다. 코딩 스타일은 전적으로 취향입니다.

다만, 한 가지 이야기 하고 싶은 건 프로젝트 규모가 커질 수록 코딩 스타일을 강제하는 것이 필수적이라는 점입니다. XP에서 흔히 말하는 코드의 공동 소유 개념도 확연히 다른 코딩 컨벤션이나 사용하는 라이브러리 등이 달라서는 적용하기 불가능합니다.

무엇보다 경험상 코딩 컨벤션을 강제했을 때 프로젝트가 진행되어 갈 수록 다른 사람이 짠 코드가 자신이 짠 것 같이 느껴질 정도로 별 거부감이 없어 가독성을 높일 수 있고 유지보수가 쉬워 지더군요.

GNU에서도 코딩 컨벤션은 물론 문서 작성, CVS 주석 다는 요령까지 자세히 매뉴얼화 하고 있습니다. 그 만큼 어느 정도 표준화가 되면 유리한 점이 있다는 뜻입니다.


----------------------------------------------------------------------------

ㅡ,.ㅡ;;의 이미지

fender wrote:

전 좋은데요? :) 그리고 ㅡ,.ㅡ;;님께서 그런 스타일을 싫어하신다고 그 스타일이 '문제가 있어 버린스타일'이나 '엉망'이 되는 건 아닙니다.

엉망이 되는경우 많습니다 자세히보면 자기스타일과 지시받은스타일에서 뒤죽박죽되어 혼동되게 해놓은경우 많이 봅니다.

Quote:

내가 빨간색을 좋아한다고 파란색이 빨간색 보다 부족한 색깔이 되는게 아니지요...

강요하는사람은 안부족하겠지만 반대입장의 사람에게는 부족한색깔이지요..

Quote:

그리고 자바 쪽에서는 그런 스타일이 가장 일반적이고 물론 나름의 일관성이 있습니다. 코딩 스타일은 전적으로 취향입니다.


보통보면 자기는 일반적이라하는데 일반적이 아닌경우가 많더군요. 나이가 많은사람일수록 과거의 자기스타일을 강조하다보니 요즘은 잘안쓰는 구스타일도 많이 고집하더군요. 이쓰레드의 예도 그러한경우중하나죠..
Quote:

다만, 한 가지 이야기 하고 싶은 건 프로젝트 규모가 커질 수록 코딩 스타일을 강제하는 것이 필수적이라는 점입니다. XP에서 흔히 말하는 코드의 공동 소유 개념도 확연히 다른 코딩 컨벤션이나 사용하는 라이브러리 등이 달라서는 적용하기 불가능합니다.

필수는 아닙니다. 필수라는 의미는 그렇게 하지않으면 프로젝트를 완료할수 없다는의미인가요? 그렇지는 않죠..따라서 필수는 아니죠.
적용이 불가능할정도라면 무언가 잘못된것이죠.

Quote:

무엇보다 경험상 코딩 컨벤션을 강제했을 때 프로젝트가 진행되어 갈 수록 다른 사람이 짠 코드가 자신이 짠 것 같이 느껴질 정도로 별 거부감이 없어 가독성을 높일 수 있고 유지보수가 쉬워 지더군요.

자기 스타일을 강요한사람은 조금 좋겠죠.. 하지만 그스타일대로 짜야하는 사람은 10배는 더어렵운 투자를 해야하겠죠..더구나 프로젝트마다 매번스타일을 바꾸어야하는 불편함마저 발생하고 종종엉터리를 만날위험도 있죠..

더구나 유지보수할때도 그리 쉬워지지는 않습니다. 후임자또한 그스타일에 맞추어야할 시간과 노력이 투자되기때문이죠..

강요한사람은 1만큼의 편안함을 느낄수 있어도 그에따라 작성해야할사람은 10만큼의 노력이 필요하며 그때문에 들어가는 기회비용으로인하여 프로그램의 안정성은 그만큼 떨어지거나 시간적으로 많이 걸리게 되죠..

Quote:

GNU에서도 코딩 컨벤션은 물론 문서 작성, CVS 주석 다는 요령까지 자세히 매뉴얼화 하고 있습니다. 그 만큼 어느 정도 표준화가 되면 유리한 점이 있다는 뜻입니다.

유리한점도 있지만 불리하점도 있죠. 표준화를 잘하면 장점이 클것이고 못하면 단점이 크겠죠..

하지만 궂이 강요가아니라 교육을통한 권장차원이 더유리하다고 봅니다.
좋다고 생각되면 당연히 따라하겠죠..
그것을 꼭 자신이 최고인양 못박아두고 강요해야할까요..

서로의 장점을 배워가며 조금씩 수정되어나가는게 못박아두는것보다 훨씬 발전적이라고 생각됩니다.


----------------------------------------------------------------------------

유겸애비의 이미지

딴 사람들이랑 같이 프로젝트를 하다보면
저하고 다르거나 전혀 규칙이 없는 코딩스타일을 보면
자꾸 바꾸고 싶더라구요.

차라리 파이쏭 처럼 강제시키는게 나을거 같다는 생각도 듭니다.
나이먹을수록 규제가 좋아지네요.. 8)

ㅡ,.ㅡ;;의 이미지

게시판이 오류를 일으키네요..
오류때문에 이상한게 한번삽입되고 같은게 두개들어가버렸는데 지울수가 없군요..


----------------------------------------------------------------------------

feanor의 이미지

저는 무조건 괄호는 함수 이름과 같은 줄에 씁니다.

--feanor

fender의 이미지

ㅡ,.ㅡ;; wrote:
엉망이 되는경우 많습니다 자세히보면 자기스타일과 지시받은스타일에서 뒤죽박죽되어 혼동되게 해놓은경우 많이 봅니다.

ㅡ,.ㅡ;;님께서 Sun스타일을 싫어하신다는 건 이해가 가는데, 특별한 이유를 밝히지 않고 Sun 스타일로 하면 "자기스타일과 지시받은스타일에서 뒤죽박죽되어 혼동되게 해놓은경우"가 생기고 GNU 스타일로 하면 그렇지 않다고 말씀하시는 부분은 잘 이해가 가지 않습니다.

ㅡ,.ㅡ;; wrote:
보통보면 자기는 일반적이라하는데 일반적이 아닌경우가 많더군요. 나이가 많은사람일수록 과거의 자기스타일을 강조하다보니 요즘은 잘안쓰는 구스타일도 많이 고집하더군요. 이쓰레드의 예도 그러한경우중하나죠..

그런 경우도 많이 있습니다만 자바 코딩 스타일에 대해선 분명 표준 문서가 정해져 있습니다.

http://java.sun.com/docs/codeconv

ㅡ,.ㅡ;; wrote:
필수는 아닙니다. 필수라는 의미는 그렇게 하지않으면 프로젝트를 완료할수 없다는의미인가요? 그렇지는 않죠..따라서 필수는 아니죠.
적용이 불가능할정도라면 무언가 잘못된것이죠.

........
자기 스타일을 강요한사람은 조금 좋겠죠.. 하지만 그스타일대로 짜야하는 사람은 10배는 더어렵운 투자를 해야하겠죠..더구나 프로젝트마다 매번스타일을 바꾸어야하는 불편함마저 발생하고 종종엉터리를 만날위험도 있죠..

더구나 유지보수할때도 그리 쉬워지지는 않습니다. 후임자또한 그스타일에 맞추어야할 시간과 노력이 투자되기때문이죠..

강요한사람은 1만큼의 편안함을 느낄수 있어도 그에따라 작성해야할사람은 10만큼의 노력이 필요하며 그때문에 들어가는 기회비용으로인하여 프로그램의 안정성은 그만큼 떨어지거나 시간적으로 많이 걸리게 되죠..


굳이 말을 정확히 하자면 '필수'는 아닙니다. 하지만 그렇게 따지면 IDE를 사용하는 것도 필수가 아니고 자동화된 빌드나 CVS, 유닛테스트도 안쓴다고 프로젝트를 못하는 것은 아닙니다. 중요한 건 이런 검증된 best practice들 없이 프로젝트 진행이 불가능한지 아닌지 따지는게 아니라 얼마나 효율적으로 운영할 수 있는지를 묻는 질문이 아닐까 싶습니다.

일반적인 경우 개발자 1-2명이 처음부터 끝까지 책임지는 경우가 아니면 표준화된 코딩 컨벤션이 유지보수에 미치는 영향은 막대합니다. ㅡ,.ㅡ;;님께서는 개발자가 적응하는데 드는 시간이 이런 이득을 상쇄할 것이라고 생각하시지만 대부분 IDE에서 컨벤션에 맞게 자동으로 포맷을 해주고 심지어 빌드 프로세스에서 jtidy등으로 컨벤션을 강제하는 경우도 있기 때문에 최소한 개발자가 익숙하지 않은 컨벤션으로 코드를 '작성' 하는데 드는 시간은 무시할 수 있을 정도입니다.

그리고 표준적 컨벤션을 정해두면 각각의 개발자는 약간의 시간만 지나도 가독성 측면에서 쉽게 적응을 할 수 있지만, 예를들어 4-5명의 개발자가 서로 다른 컨벤션을 사용한다면 한 명의 개발자는 3-4개의 자신과 다른 컨벤션에 익숙해져야 하는 문제가 있습니다.

그리고 표준화된 컨벤션이 없는 경우 가장 큰 문제는 다른 사람의 코드를 수정하는 경우입니다. 이 때 부분적으로 자신의 컨벤션으로 코딩을 하면 같은 소스에 서로 다른 컨벤션이 얽혀 버리고 - 제일 짜증나는 경우가 일부는 탭을 쓰고 일부는 공백을 써서 들여쓰기 하는 경우입니다. 리눅스와 윈도우즈 환경이 혼재해 있으면 CR/LF 문제도 만만치 않습니다 - 그렇지 않으면 해당 개발자의 컨벤션에 억지로 맞추어 코딩을 할 수밖에 없습니다.

ㅡ,.ㅡ;; wrote:
하지만 궂이 강요가아니라 교육을통한 권장차원이 더유리하다고 봅니다.
좋다고 생각되면 당연히 따라하겠죠..
그것을 꼭 자신이 최고인양 못박아두고 강요해야할까요..

물론 Sun 스타일이 GNU보다 '우월'하기 때문에 강제하는 건 아닙니다. 그리고 "내가 팀장이니 무조건 내말 들어!"하고 강요하는 경우는 별로 없는 것 같군요 :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

ㅡ,.ㅡ;;의 이미지

fender wrote:
ㅡ,.ㅡ;;님께서 Sun스타일을 싫어하신다는 건 이해가 가는데, 특별한 이유를 밝히지 않고 Sun 스타일로 하면 "자기스타일과 지시받은스타일에서 뒤죽박죽되어 혼동되게 해놓은경우"가 생기고 GNU 스타일로 하면 그렇지 않다고 말씀하시는 부분은 잘 이해가 가지 않습니다.

어떤코딩스타일을 정해두고 기존사람이나 다른사람이 작성한코드들을 봤을때 그규칙자체도 잘맞지 않더라는 말입니다. 예를들면 텝을4칸으로 정했는데
사람들은 4칸으로 썼다가 자기의 습관데로 텝으로도 썼다가 어떤때는 3칸을 4칸으로 잘못봤는지 3칸넣었다가 나중에는 화가났는지 1칸도 했더라고요..이렇게 뒤죽박죽이 되어 있더라는거죠..

실제로 여기(^^) 코딩이 텝을 스페이스4로 정해두었는데 완전엉망이며 그것을 재대로 잡기란 여간골치아픈게 아니군요..수천개되는소스 다바꿀수도 없고.
기존 코딩한사람도 마찬가지이유로 이렇게 되었으리라 생각합니다.

Quote:

물론 Sun 스타일이 GNU보다 '우월'하기 때문에 강제하는 건 아닙니다. 그리고 "내가 팀장이니 무조건 내말 들어!"하고 강요하는 경우는 별로 없는 것 같군요 :)

그렇다면 다행이지만 종종 그런경우를 보기도 합니다.
심한경우는 기존소스 새로온 윗분(ㅡㅡ) 스타일에 맞게 고치는작업을 하기도 합니다. 그러다 다시 윗분바뀌면 미x짓을 또하게 될수도 있지요....
실제 비슷한경우가 있어 하는 이야기입니다.

좋은코딩스타일을 강의하여 그장점을 알려주어 권장차원이면 되지 그것을 강요할필요 까지있나 하는겁니다.
당연 좋으면 상요하겠지요..이런생각이 가끔듭니다.
"나는 고생해가며 내나름대로 정립했다 너희들도 써봐라 이유는묻지마라 내가한것처럼 고생해서 이유를찾아라 해보면 내가한것처럼 좋아하게 될것이다"
해주고 싶은답변"니가강요하는것은 내가 옛날에 해봤다 사소한문제가 있더라. 니가정한규칙을보아하니 세밀한부분은 고려도 되지 않았다 최소한 니가 정한룰데로 실제프로젝트에서 아주 엄격하게 코딩을 한번이라도 해보고 말하면 다행이다. 귀로얇팍하게 듣고 사람머리에 호랑이 발톱과 이빨에 고릴라몸에 말다리를 붙였다하여 완벽한 동물이 탄생하리라 착각하지마라."


----------------------------------------------------------------------------

ed.netdiver의 이미지

전 사실 indent는 거의 포기하고 삽니다.
cvs에 commit할때 convention script를 돌려서 룰에 맞게 올리고
내리게끔 한다는 얘기도 들었지만, 실제 코딩하다보면
if 1,0도 (다른 사람이 그렇게 해놓은거 보면 끔찍해하면서도) 다반사로
쓰게 되더라 이겁니다.
거기다 indent같은 툴을 써도 정말 입맛에 맞게 맞춰지지는 않기 마련이고
말이죠. nesting된 struct, class의 member를 다음 라인으로
내려버리거나 한달지...

그보다는 macro나 괄호의 scope만이라도 잘좀 생각해서 맞춰주길
바란다고나 할까요.
이건 어딘가 중복되어있는(대개 macro안밖에 동일하게 정의된 괄호나
주석처리된 괄호들이지만) 그런넘들땜에 %가 유명무실해질땐 일일이
코드 따라가면서 이게 어디가 끝이야... 하는수밖엔 없으니...
것도 1~200줄 얘기면 귀엽지만,
7000라인 넘는 함수( 정말 이걸 함수로 봐야 하는지...ㅡ.ㅡ; )같은것들
따라갈때면 정말이지 미치고 팔짝 뛰고 맙니다. while의 switch의 case의
switch의 case의 while...의 switch의 if else if 의 for...(우욱)
수만라인짜리 파일을 읽어들이는데, source insight같은 툴로도
그런 오류때문에 파싱을 못하는 경우까지 있고 말이죠.
심미적인 취향이야 어쩔수 없대도 그런 논리적인, 그리고 순전히
코드레벨에서의 오류는 조심해야 할텐데...(아 찔린다...ㅋㅋ)

그런데 함수 정의 부분도 정말 고정시키기 어렵지 않나요?
인자 없는 함수야 한라인에 다 쓸수 있지만,
한 대여섯개정도 되어버리면 인자라인도 그 아래로 내리는 수밖에
달리 방법이 없잖습니까. 그래서 전 위에 열거하신 방법 다 쓰게 되더군요.

그리고, 함수명 옆의 중괄호 시작은 정말이지 코드 라인수를 아끼기 위한
방편 아니었나요? 옛날 책들은 거진 그랬던 것 같고.
요즘은 오히려 양 많아보이려고 빈라인 무쟈게 두던데 말이죠.

대체 책 예제 코드에 가독성을 최대한 고려한다는 건...

아 뭐 이또한 사람마다 취향문제니까 뭐라고 할 수는 없겠네요.

이상 손가락 뻐근해서 들렀다 갑니당.
그럼 좋은하루하루 되세요.

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

fender의 이미지

이클립스의 경우 코드 포맷팅 옵션이 매우 자세히 되어 있고 설정 내용을 xml로 export/import가 가능합니다. 이를 CVS에 올려서 팀원들 간에 공유하는 것도 좋은 방법입니다. 이클립스 등의 최신 IDE는 새로 생성하는 코드는 물론 기존 코드도 키 하나로 지정한 컨벤션에 맞게 다시 포맷해 주니 컨벤션을 맞추기가 크게 어렵지 않습니다.

그 밖의 경우 checkstyle을 쓰면 거의 프로그래머가 히스테리에 걸릴 정도로 꼼꼼하게 코딩상의 문제점을 체크해 줍니다. 탭/스페이스 문제, 지나치게 긴 메소드, 불필요한 공백 등등 컨벤션 상의 문제는 물론 일반적인 코딩이나 설계시 자주 범하는 잘못들에 대해서도 검사 가능합니다.

참고로 아래 링크는 maven에서 checkstyle과 pmd를 이용해 자동 생성된 리포트입니다 :
http://maven.apache.org/checkstyle-report.html
http://maven.apache.org/pmd-report.html

checkstyle은 이클립스에 플러그인으로 쓰거나 maven 등 빌드 프로세스에서 리포트를 작성하게 하면 상당히 유용하게 쓸 수 있습니다. 참고로 빌드시에 강제로 포맷을 설정하는 건 CVS 와 같은 버전 관리 시스템에서 문제를 일으킬 소지가 많아서 별로 권장하지 않습니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

ㅡ,.ㅡ;;의 이미지

코딩스타일은 단지 스타일로 끝나지 않습니다.

코딩스타일이 달라지면 사용하는 변수타입이나 함수, 표현법 그리고 구조조차도 달라집니다.
스타일만 바꾸는데 머가 문제냐라고 할지모르나 스타일에 맞게 변해가며 그렇게 될수 밖에 없습니다.
간단한예로 저는 네이밍이 길고 텝을 스페이스8로주고 +-=변수 사이에 공백이 없으며 이러한스타일에서는 for( point=addr; *point; point++ ) 이런것보다
차라리 while 문을 쓸것입니다. 변수명이 긴데비해서 for 문하나에 넣기보다는
차라리 루프들어오기전에 한라인을 할당하여 초기화하는것이 더좋아보이며
어차피 가독력을 중시하는 프로그램으로 간주하여 포인터변수사용보다는 i 를할당하여 배열로 사용합니다...
또한 전반적으로 함축적인 문법보다는 풀어쓰는형태의 문법을 많이 쓰게 되겠지요
네이밍룰이 길고 띄어쓰기등도 길어지는 이러한스타일에서는 궂이
변수%=함수((함수())? 함수(함수(변수/변수) ,변수) : 함수()) ; 이런식은 생각조차 하지 않겠죠...
따라서 내부에서 사용하는 함수들의 리턴타입이나 인자들도 조금다르게 생각할수 있으며 기능도 다르게 생각할수있겠죠..


----------------------------------------------------------------------------

westin의 이미지

저는 C 소스도 자바 코딩 가이드라인에 맞춰 바꿨습니다만.. ^^

int main() {
    printf("Hello, world.\n");

    return 0;
}

사례를 따져보면..
자바를 왠지 모를 이유로 싫어하는 사람은 자바 코딩 가이드라인을 따르지 않는 경우가 많고..
자바를 적극적으로 받아들이는 사람은 자바 코딩 가이드라인을 잘 따르는 것 같습니다..

voider의 이미지

제 코딩스타일은 ... 자바나 c++ 이나 c 나 다 비슷합니다


class Class : public Base
{
	public:
	Class() { // 왠만큼 길지 않으면 구현파일에 따로 함수를 구현하지 않습니다
		어쩌구 저쩌구;
	}
	Class(int n)
		:int_(n)
	{}
	int GetInt() const { //멤버함수는 대문자로 단어사이 구분합니다
		if(int_ != 0) { //코드라인수를 아끼기 위해 노력합니다
			return int_;
		}
	}
	int IncInt();
	protected:
	void LongArgFunc(LongFirstArg<int> first,
		LongSecondArg<int> second,
		LongLastArg<char> last) {
		if(int_ == 0) {
		}
		else if(int_ == 1) {
		}
		else {
		}
	}
	int int_;
};

// 구현파일
int Class::IncInt()
{
	return (++int_);
}

이런식입니다.
들여쓰기는 4 를 사용하구요

제 코딩스타일은 최대한 간편하면서도 짧게 쓰려고 노력합니다
물론 너무 짧게 쓸려다가 나중에 해석이 안되는 코드는 피하려고 하죠
저도 이렇게도 써보고 저렇게도 써봤는데
이게 가장 편한것 같네요...

-- 아쉬운 하루 되세요 --

kwon37xi의 이미지

코드 규약을 왜 따라야 하는지는, 아무런 코드 규약없이 진행된 프로젝트의 소스를 유지보수 한번만 해보면 알 수 있을껍니다.

자신에게 익숙치 않더라도 어떤 규칙에 따라 작성된 코드를 유지보수하는 것과 만든 사람마다 심지어는 한 사람이 만들더라도 한 소스 파일에서조차도 뒤죽박죽인 소스와....

코드 규약을 잘 지켰다면, 실상, 그 프로젝트는 다른 면에서도 뛰어나지 않을까 하는 생각이 드네요..

흑... 어제 17000줄짜리 클래스 하나 첨부터 끝까지 읽어보고 속 뒤집어지는 줄 았았습니다.. 그걸 다 훑어본 제가 자랑스럽습니다... ㅜㅜ

첨에는 인덴트도 안맞고, 도대체 while 문의 시작과 끝이 어딘지 도무지 알수도 없었는데.. jalopy 로 정리해서 보니 그나마 뒤집히던 속이 가라앉았습니다.

jalopy가 정리해준건 포맷뿐이지 변수명이나 이런게 아니기 때문에, 사실 도대체가 규칙이 없는 변수명과 메소드 이름 심지어는 wdkdjee.java 와 같은 해괴 망칙한 클래스 이름들까지...(대부분의 클래스가 저런 이름에다가 숫자만 붙여 놨습니다...)

우엉...

이건 좀 심한 경우고요..

암튼.. 익스트림 프로그래밍 인스톨드였나...
어느 책에서 본 말이 생각나는군요.

Quote:

프로그래머라면 개성은 코드가 아니라 옷이나 머리에나 발휘해라!

아.. 그냥 넋두리 쓴거네...

GjtRoql의 이미지


main(){

}
이렇게 사용합니다.
라인도 줄어 들고 코드도 깔끔하고...

이렇게 쓰다보니 다름사람들 소스도 이렇게 해야 가독성이 높아지는 슬픈현실까지 와버렸습니다.

--------------
Burning Blue!
--------------

musik의 이미지

저는 자바로 프로그래밍 할때는 SUN 컨벤션에 맞추어서...
C/C++ 을 사용할때는 GNU 컨벤션에 맞게 사용합니다.

처음에 배울때의 습관이 끝까지 굳어지는 것 같습니다.
자바같은 경우 사용한지 8년 정도 되었는데, 그간 보아왔던 인터넷이나 책에
널린 리소스들이 거의 다 SUN 의 룰을 따르다보니.. 저도 거기 맞춰서 가는 것이 신경이 덜 써지더라구요.. 하물며 JDK 소스 자체도 그렇게 되어있으니까요..

C/C++ 이야 뭐 자바 쓰기 훨씬 전부터 써왔지만, 이들의 경우 워낙 스타일이
다양해서 뭘 쓰던 자바만큼 신경전을 벌이던 적은 없는 것 같습니다.

대개 많이 사용하는 쪽에 따라주는 것이 자신에게도 좋은 것 같습니다.
남의 소스를 보면서 '뭐야 이게 시박' 하고 투덜대는 일이 '그만큼' 줄어들테니까요
8)

외국어 잘하시는 분들 보면 해당 외국어로 생각을 하시잖습니까.. 각각 언어를
오가며 코딩할때도 그때그때 변신하는 유연성을 보이는 것도 괜찮을듯..
프로젝트에서 코딩컨벤션은 무척 중요한 사항이지요.. 어차피 사람마다 특색이
다 다르기 마련인데... 최대한 '관례'를 따르는 것이 좋지 않겠습니까.

뭐 '나는 남과 달라'라고 생각하시거나, '내가 곧 관례이며 표준이다' 라고 생각하
시는 분들이라면 그냥 편한대로 쓰시라고 하고 싶습니다. :lol: 하하..

감사합니다.

liongo의 이미지

전 좀 섞어쓰는데 이상한건가 ㅡㅡ;

Emacs 가 해주는데로 그냥하다보니..

Class ExampleClass
{
    void funcName()
    {
        int varFlag = 0;

        if( !varFlag ) {
          ............
        }

    }
}

어쩌다보니 이런 묘한 스타일로 :)

조건문과 반복문들은 { 한줄에 씁니다.. 묘한것같기도 하고..

모 코딩스타일은 팀프로젝할땐 맞춰야한다고 생각합니다만..

두뇌도 구조도 다틀리고 취향이 다틀린데..

무조건 자신의 취향을 버리라곤 하고싶진 않습니다.

솔직히 이런 기본문법보다 내용이 더욱 가독성이 쉬운게 중요한거 아닌가요..

전 VC쓰시는분들 m_var 스타일의 변수지정이 맘에 들진않습니다만

효율성이 있는것같다는 생각도합니다..

' 형식이 내용을 규정한다. '

익명 사용자의 이미지

^^ 저도 이런 스타일 인데... 반갑습니다. ㅎㅎ

정재윤의 이미지

이맥스의 java coding style은 변경이 가능합니다.

liongo의 이미지

네 가능하지요 근데 귀차니즘땜시 ㅡㅡa

근데 나름대로 괜찬은것같아서 그냥 적응해버렸어요. :)

' 형식이 내용을 규정한다. '

zinga815의 이미지

제목은 그렇게 했어도
프로젝트 한 10명 아니 5명정도가 팀으로 모였을때 가이드의 중요성을 인식할거 같습니다.
규모가 작다면 그 효과를 잘 모르겠지만 일단 어느정도 규모가 있다면 확실히 느낄수 있겠지요...

뭐 말이 필요없이 한번 경험을 해본다면 ...

blade763의 이미지

원론적인 면에서 코딩이론으로 올라가서 보면 코딩의 원칙은 무엇보다 명확성이죠 신호가 정확하게 가지 않으면 수신측에서 정확하게 해독을 할수 없겠죠. 프로그램언어의 기본도 마찬가지라 생각합니다. 우선은 명확하여야 하고 그 다음 중요한 것은 가독성이라고 생각합니다. 예전의 경우 단독으로 코딩을 하여 프로그램을 만들고, 그 프로그램을 실행하고 하는 상황에서 어떤 코딩 규칙으로 하던 중요한건 아니었지만 지금은 프로젝트 단위로 코딩을 하기때문에 최소 구성원끼리라도 규칙을 만들어서 유지를 하고 개발해 나가는것은 당연한 얘기입니다. 그러나 매 프로젝트마다 규칙이 다르면 이런 규칙도 의미가 없어진다고 생각합니다. 그리고 동일한 수업을 받지 않은 사람끼리 모여서 코딩을 하다 보면 각자의 스타일대로 코딩해가는 것은 어쩔수 없다고 생각합니다. 제가 생각하는 코딩 규칙이라는 함은 보다 일반화된 코딩 규칙대로 만들어주는데, 각자의 스타일을 고려해서 코드를 관리를 하는 사람이 코드를 수집해서 바뀌어 주는게 더 낫지 않을까합니다. 그럼 그 시간을 낭비하는게 아니냐 하지만 코딩 규칙에 맞게끔 만들어주는 툴들은 많다고 생각합니다. 퇴근하기 전이나 점심 식사전에 돌리고 나간다면 시간 낭비에 대한 문제는 논의꺼리가 아니라 생각이 듭니다. 걍 지나가다가 보게 되어서 서투른 답글 한번 달아보았습니다.

익명 사용자의 이미지

저는 개인적으로 후자쪽을 사용합니다.
Artistic Style의 매뉴얼에는 그게 K&R이라고 나와있더라고요.
친구가 그게 뭔지 이야기 해줬었는데 잊었네요.

wonny의 이미지

ㅡ,.ㅡ;; wrote:

좋은코딩스타일을 강의하여 그장점을 알려주어 권장차원이면 되지 그것을 강요할필요 까지있나 하는겁니다.
당연 좋으면 상요하겠지요..이런생각이 가끔듭니다.
"나는 고생해가며 내나름대로 정립했다 너희들도 써봐라 이유는묻지마라 내가한것처럼 고생해서 이유를찾아라 해보면 내가한것처럼 좋아하게 될것이다"
해주고 싶은답변"니가강요하는것은 내가 옛날에 해봤다 사소한문제가 있더라. 니가정한규칙을보아하니 세밀한부분은 고려도 되지 않았다 최소한 니가 정한룰데로 실제프로젝트에서 아주 엄격하게 코딩을 한번이라도 해보고 말하면 다행이다. 귀로얇팍하게 듣고 사람머리에 호랑이 발톱과 이빨에 고릴라몸에 말다리를 붙였다하여 완벽한 동물이 탄생하리라 착각하지마라."

indentation이나 naming rule 등의 convention은 가장 효율적이고 유용하기 때문에 하나를 정해놓는 것이 아니라 수많은 사람이 공동작업을 원할하게 하기 위해 그냥 약속하는 것이라고 생각합니다.
indentation은 아주 사소하게 보일지는 모르겠지만, 의외로 남의 소스를 면밀히 살펴보는데 거슬리게 됩니다. 이 때 모두가 조금씩 자기에게 맞지 않더라도 convention을 정하고 준수하려고 조금씩 노력하게 되면 모두에게 득이 된다고 생각합니다.
mendatory가 없으면 자신의 rule을 고집하듯이 남도 자신의 rule을 고집하게 되고 결국 프로젝트에서 자신이 하나의 규칙에 맞춰가는 시간보다 더 많은 시간을 남의 소스를 보며 짜증내는데 소모하게 될 지 모릅니다.
작문할 때 한 paragraph가 끝나면 line feed하는 것이 효율을 위한 것보다는 약속이듯 이러한 규칙은 필요하다고 생각합니다.

케케케~

notexist의 이미지

wonny님 의견에 동의합니다.
혼자 작업을 할때는 자기가 편한 코딩 스타일로 하면 됩니다.
하지만 팀작업을 할때는 사전에 코딩 스타일을 정하고 그것에 따라서 하는 것이 필요합니다.
여기서 코딩 스타일을 강요하는 것은 좋은 코딩 스타일을 강의하거나 장점을 알려줄려고 하는 것이 아닙니다. 팀작업을 위하여 형식을 통일하는 것이 목적인 것이죠.

그리고 코딩 스타일은 사람에 따라 더 좋다고 생각하는 것이 있을 수는 있지만...절대적으로 어느 하나가 좋은 것은 없습니다. 그러니 자기 좋은대로 하다보면 다 다르죠...

wonny wrote:
ㅡ,.ㅡ;; wrote:

좋은코딩스타일을 강의하여 그장점을 알려주어 권장차원이면 되지 그것을 강요할필요 까지있나 하는겁니다.
당연 좋으면 상요하겠지요..이런생각이 가끔듭니다.
"나는 고생해가며 내나름대로 정립했다 너희들도 써봐라 이유는묻지마라 내가한것처럼 고생해서 이유를찾아라 해보면 내가한것처럼 좋아하게 될것이다"
해주고 싶은답변"니가강요하는것은 내가 옛날에 해봤다 사소한문제가 있더라. 니가정한규칙을보아하니 세밀한부분은 고려도 되지 않았다 최소한 니가 정한룰데로 실제프로젝트에서 아주 엄격하게 코딩을 한번이라도 해보고 말하면 다행이다. 귀로얇팍하게 듣고 사람머리에 호랑이 발톱과 이빨에 고릴라몸에 말다리를 붙였다하여 완벽한 동물이 탄생하리라 착각하지마라."

indentation이나 naming rule 등의 convention은 가장 효율적이고 유용하기 때문에 하나를 정해놓는 것이 아니라 수많은 사람이 공동작업을 원할하게 하기 위해 그냥 약속하는 것이라고 생각합니다.
indentation은 아주 사소하게 보일지는 모르겠지만, 의외로 남의 소스를 면밀히 살펴보는데 거슬리게 됩니다. 이 때 모두가 조금씩 자기에게 맞지 않더라도 convention을 정하고 준수하려고 조금씩 노력하게 되면 모두에게 득이 된다고 생각합니다.
mendatory가 없으면 자신의 rule을 고집하듯이 남도 자신의 rule을 고집하게 되고 결국 프로젝트에서 자신이 하나의 규칙에 맞춰가는 시간보다 더 많은 시간을 남의 소스를 보며 짜증내는데 소모하게 될 지 모릅니다.
작문할 때 한 paragraph가 끝나면 line feed하는 것이 효율을 위한 것보다는 약속이듯 이러한 규칙은 필요하다고 생각합니다.

There is more than one way to do it...

creativeidler의 이미지

코드 컨벤션이 물론 팀 전체의 통일된 스타일을 위해 정하는 의미도 있습니다. 그러나, 그렇다고 불편하고 귀찮은 컨벤션을 쓴다면 통일하더라도 그 의미가 반감되겠죠. 컨벤션 조항 하나하나에 모두 합당한 이유가 있어야 합니다. 불합리한 컨벤션처럼 코딩을 짜증나게하는 것도 많지 않죠. 제발 상대주의만큼은 지양하는 방향으로 논의가 진행되었으면 좋겠습니다.

그런 의미에서 {를 내려 쓰는 문제를 본다면 요즘 추세는 점점 {를 내려 쓰는 방향이 많아지고 있습니다. indent로 충분히 구분 가능하기 때문에 내려쓰는 것은 라인 낭비라고 보는 거죠. 파이썬 같은 언어는 아예 블럭을 indent로만 구분합니다.

그리고 자바에 관해서라면 썬에서 배포하는 코드 뿐 아니라 Jakarta Project, Open Symphony, codehaus 등 메이저 오픈소스 자바 커뮤니티들은 모두 썬의 자바 코드 컨벤션을 기준으로 약간씩 변형한 형태를 사용하고 있습니다. java.net의 오픈소스 프로젝트들 역시 마찬가지, javaworld, jdj 등의 article에서도 썬의 컨벤션이 많이 쓰입니다. IBM, Oracle 등의 기업들도 마찬가지죠. 꼭 널리 쓰인다고 좋다는 것은 아니지만 그만큼 많은 사람들에게 익숙하다는 이야기는 될 수 있겠죠.

임창진의 이미지

제경우는 C 를 배우던 시절엔 전자를 java 사용한이후 지금은
C 든 JAVA 든 후자쪽(line saver)을 사용합니다.

지금은 전자쪽의 스타일로 코딩된 소스는 보기가 매우 불편해서 툴을 이용하여 후자쪽으로 바꾸어서 보고 있습니다.
그런데 코딩 스타일은 어디까지나 개인취향이어서 전자쪽의 코딩스타일을 선호하는 분의 경우에도 후자쪽의 코딩스타일로작성된 소스를 보기가 마찬가지로 불편할것입니다.

소스의 의미를 해치지않는 범위내에서 개인의 취향은 존중되어야 한다고 생각하며 위에 말씀하신분들처럼 그렇다고 표준을 무시하면서 까지 개인 취향대로 공통의소스를 바꾸어야 한다고도 생각하지 안습니다.

가능하다면 이러한것은 도구가 해결해야할 문제라고 생각합니다.
요즘 사용되는 자바도구들은 indent(coding style)는 개개인의 입맛에맞게 수정할수 있기 때문에 남의 소스를 보는것은 문제되지 않을것이고 문제가 된다면 버전관라할때 diff 해볼경우 지금의 diff 도구로는
코드가 추가/변경/삭제된 것인지 단순히 코딩스타일이 변경된건지 모.를것이기 때문에 위에서 말슴하시 어떤분의 말처럼 chek in/out 할때 스타일을 통일하는 추가작업이 필요할겁니다.

이건 딴생각인데
대부분의 editor 가 신택스하일라이팅을 지원하고 추가로 단순한표기법으로 새로운 언어의 문법을 표기하여 사용할수 있는것처럼
diff 도구들이 간단한 설정으로 각 프로그래밍언어의 특성에 맞는 diff 를 해준다면 좋을거 같습니다.

얼마전에 어찌어찌하야 스타일이 다르게 되버린 두 소스파일군의 diff
를 할 일이 있었는데 스크립트로 소스ㅤㅅㅢㅤ 주석과 log 찍는 부분을 다 지워버리고 astyle 돌린후 jalopy 로 method 정렬해서 그후에 diff 를 했었는데 jalopy open source 버전이 sorting 에 버그가 있어서 잘 안됐던 기억이 있습니다.
method 정렬해주는 이런툴 혹시 어디 없나요?

creativeidler의 이미지

Quote:
그런데 코딩 스타일은 어디까지나 개인취향이어서 전자쪽의 코딩스타일을 선호하는 분의 경우에도 후자쪽의 코딩스타일로작성된 소스를 보기가 마찬가지로 불편할것입니다.

전 바로 그 생각에 딴지를 걸고 싶습니다. 그렇게 취향에 따라 달라질 수 있는 문제라면 처음부터 컨벤션을 정하지 말고 개인 자유에 맡겨야 할 일이죠. 취향 문제라면 하나의 컨벤션으로 통일하는 의미가 없어지는 거나 마찬가지입니다.

이를테면 이런 상황이 있을 수 있습니다. 팀에 10명이 있는데 6명은 Sun 스타일을 좋아하고 4명은 K&R을 좋아합니다. 여기서 다수결에 따라 Sun 스타일로 정하는 게 옳을까요? 그럼 4명은 다른 사람들이 작성한 코드를 볼 때, 심지어 자신이 코딩을 할 때도 불편함을 느낍니다. 취향 문제라면 말입니다. 서로의 코드에 간섭할 일이 적다면 차라리 자기 취향대로 하는 것이 전체적인 생산성에는 나을 수도 있습니다.

하지만 이게 취향 문제가 아니라 합리적인 이유가 있어서 Sun 스타일로 정했다면 K&R파는 그냥 불편해하면서 쓸 게 아니라 자신도 Sun 스타일에 적응해야하는 명분이 생긴 것입니다. 그리고 정말 그 이유가 합리적이라면 익숙해질수록 오히려 Sun 스타일을 좋아하게 되겠죠.

합리적인 이유를 제시할 수 없는 컨벤션이라면 아예 폐기하는 것이 바람직합니다. 정말 완전히 선악을 전혀 따질 수 없는 취향 문제에 속하는 컨벤션이라면 이런 걸 강제했을 경우 긍정적인 효과보다 부정적인 효과가 더 클 수 있습니다. 컨벤션은 꼭 필요한 것만 최소한으로 정하되 정한 것은 확실하게 지키는 것이 중요합니다.

p.s.
클래스의 멤버 정렬이라면 이클립스에도 있습니다.

wonny의 이미지

creativeidler wrote:
이를테면 이런 상황이 있을 수 있습니다. 팀에 10명이 있는데 6명은 Sun 스타일을 좋아하고 4명은 K&R을 좋아합니다. 여기서 다수결에 따라 Sun 스타일로 정하는 게 옳을까요? 그럼 4명은 다른 사람들이 작성한 코드를 볼 때, 심지어 자신이 코딩을 할 때도 불편함을 느낍니다. 취향 문제라면 말입니다. 서로의 코드에 간섭할 일이 적다면 차라리 자기 취향대로 하는 것이 전체적인 생산성에는 나을 수도 있습니다.

하지만 이게 취향 문제가 아니라 합리적인 이유가 있어서 Sun 스타일로 정했다면 K&R파는 그냥 불편해하면서 쓸 게 아니라 자신도 Sun 스타일에 적응해야하는 명분이 생긴 것입니다. 그리고 정말 그 이유가 합리적이라면 익숙해질수록 오히려 Sun 스타일을 좋아하게 되겠죠.

합리적인 이유를 제시할 수 없는 컨벤션이라면 아예 폐기하는 것이 바람직합니다. 정말 완전히 선악을 전혀 따질 수 없는 취향 문제에 속하는 컨벤션이라면 이런 걸 강제했을 경우 긍정적인 효과보다 부정적인 효과가 더 클 수 있습니다. 컨벤션은 꼭 필요한 것만 최소한으로 정하되 정한 것은 확실하게 지키는 것이 중요합니다.

저는 말씀하신 생산성이라는 것이 프로그래머가 얼마나의 진행을 이루어 내는가에 한정하시는 것 같아서 제 반론을 말씀드립니다.

직접 코딩을 하시는 분들에게는 모두 기호가 각각이므로 어떤 강제가 생기면 코딩을 해 나가는 동안 모두에게 마이너스 요소가 있을 것입니다. 모두 자기만의 편리한 방법을 추구하면 모든 프로그래머각자에게는 효율적이고 큰 진전이 있겠지요.
하지만 대부분의 공동작업은 결국 최종적으로는 통합이라는 산을 넘어야 하며, 소프트웨어의 경우 최종 산물들은 이후 누군가가 유지, 보수를 쉽게 할 수 있도록 정리되어야 합니다. 어떤 경우에는 계약자에게 보고될 수 있도록 정리까지 되어야 합니다. 어떤 standard A보다 못한 standard B를 사용했더라도 그것을 명시해 주는 것 만으로도 추후 관리에 상당한 도움이 될 것입니다.

리눅스 커널의 경우에도 개발에 참여하기 전에 convention을 지켜주기를 희망하는 것으로 알고 있습니다. 이것은 자유의 억제가 아니고 미래에 대한 대비라고 생각합니다.

어떠한 방식으로 소프트웨어를 작성하느냐에 따라 다를 수 있겠습니다만, 최근 대다수의 소프트웨어들이 공장에서 하나의 product를 생산하는 방식처럼 가고 있기 때문에, 이러한 경우에는 product line의 한 엔지니어가 자신의 방식으로 대처해서는 추후 최종 product가 완성될 때 그리고 그 후에는 문제가 발생할 수도 있다고 생각합니다.

케케케~

임창진의 이미지

Quote:

전 바로 그 생각에 딴지를 걸고 싶습니다. 그렇게 취향에 따라 달라질 수 있는 문제라면 처음부터 컨벤션을 정하지 말고 개인 자유에 맡겨야 할 일이죠. 취향 문제라면 하나의 컨벤션으로 통일하는 의미가 없어지는 거나 마찬가지입니다.

맞습니다. 제가 말하려던 바의 반은 이해하신거 같습니다.
코딩스타일은 개인자유에 맡겨야 합니다. 단 '도구'가 그것을 지원한다면 말이죠. 위에서 분명히 도구가 해결해야할문제라고 언급하였습니다.
여기서 '도구'란 eclipse ,intellij 같은 개발도구 뿐만 아니라 버전관리도구를 포함합니다.

예를들죠 전자의경우(C style)를 좋아하는 A 가 버전관리서버에 아래와 같은 형태로 저장된 Hello.java 를 checkout 해서 고치고 다시 checkin 한다고 합시다.

class Hello {
    private void hi() {
    }

    public void hello() {
        System.out.println("hello");
    }    
}

지금 이후로 A 라는 사람이 작업하는 환경은 도구가 다 해결해주는 이상적인 환경입니다.

A 는 checkout 을 합니다
eclipse 로 그 파일이 open 되는순간 A 가 설정해놓은 ctyle 로 코드가 바뀝니다. A 는 게다가 public method가 먼저 나오도록 설정해놓았습니다. 아래와 같이 코드가 보이겠죠.

class Hello 
{
    public void hello() 
   {
        System.out.println("hello");
    }

    private void hi() 
    {
    }    
}

A 는 수정을 합니다. 메쏘드를 하나 추가합니다.

class Hello 
{
    public void hello() 
   {
        System.out.println("hello");
    }

    private void hi() 
    {
    }    

    private void howAreYou()
    {
    }
}

그리고는 무엇을 바꾸었나 버전관리서버의소스와 diff 를 해봅니다.
diff 도구는 버전관리서버의 최신버전의 파일을 가져와서 A 가 선호하는 스타일로 변경한후 diff 를 합니다.
그러면 A 가 변경한 부분이 보여집니다.

A는 checkin을 합니다.
버전관리도구는 checkin 하기전에 버전관리도구의 스타일로 A 의 소스를 변경한후 chekin 합니다.

이후에 스타일이 다른 B 라는 개발자가 또 C 개발자가 이러한 환경에서 프로그래밍을 하는데 서로다른 스타일이 문제가 될까요?

제의도는 위와같이 도구가 check in/out diff 등등의 과정에 사용자가 설정한대로 동작해주면

어떤스타일이 좋으네 나쁘네 표준을 맹길었으면 따라야 하네 마네 하면서 얼굴 붉힐일은 말생하지 않을 것입니다.
프로그래머 각자가 자기가 원하는스타일대로 코딩하면 되는 일입니다.

아 그리고 eclipse 그 기능은 알고 있습니다 intellij 의 rearranger라는 플로그인으로도 해결됩니다만 젝 원하는것은 commandline 환경의 pipe 지원되는 도구입니다. 아무튼 감사합니다.

creativeidler의 이미지

Quote:
저는 말씀하신 생산성이라는 것이 프로그래머가 얼마나의 진행을 이루어 내는가에 한정하시는 것 같아서 제 반론을 말씀드립니다.

그렇진 않습니다. 당연히 통합 과정도 포함하는 것이죠. 그래서 "전체적"이라는 말을 붙였던 것입니다. 통합 역시 문제가 되는 것은 코드 가독성일 테고 통합하는 사람이 정해진 컨벤션과 "다른 취향"을 갖고 있다면? 이런 문제를 말하는 것입니다. "통일된 스타일"이 중요하다고해서 불합리한 컨벤션을 강요한다면 그로 인한 불이익이 "통일"의 장점을 훼손하게 될 것이라는 거죠.

Quote:
맞습니다. 제가 말하려던 바의 반은 이해하신거 같습니다.
코딩스타일은 개인자유에 맡겨야 합니다. 단 '도구'가 그것을 지원한다면 말이죠. 위에서 분명히 도구가 해결해야할문제라고 언급하였습니다.

제 얘기는 컨벤션이 개인 취향이라는 것이 아니고! 코드 컨벤션을 개인 취향이라고 간주한다면 위와 같은 문제가 생긴다는 것입니다. 전 코드 컨벤션은 결코 취향의 문제가 아니라고 보고 있습니다.

Quote:
제의도는 위와같이 도구가 check in/out diff 등등의 과정에 사용자가 설정한대로 동작해주면

어떤스타일이 좋으네 나쁘네 표준을 맹길었으면 따라야 하네 마네 하면서 얼굴 붉힐일은 말생하지 않을 것입니다.


도구에 의한 해결이 가능하냐 아니냐는 밑에 다시 얘기하겠습니다만 일단 제 얘기는 코드 컨벤션의 선택에 합당한 이유가 있다면 도구가 있든 없든 얼굴 붉힐 일은 생기지 않는다는 것입니다. 그래서 컨벤션은 주의 깊게 토론을 거쳐 정해야하는 것입니다.

도구에 의한 해결에는 한 가지 넘기 힘든 문제가 있습니다. 페어 프로그래밍을 할 수 없게 만드는 것이죠. 의식적으로 페어 프로그래밍을 하는 경우가 아니라도 두 사람 이상이 하나의 화면을 보면서 작업을 해야하는 경우는 종종 생깁니다. 이럴 때 자기가 늘상 보던 컨벤션과 다른 코드가 화면에 떠 있다면 상당한 비효율이 생기겠죠.

임창진의 이미지

그러네요 페어할때는 툴이 어떻게 해 줄 수가 없겠네요.

전에 c style 로 코딩하시는분 자리에서 같이 코딩을 잠깐 한적이 있었는데 제가 driver 할때는 스타일 바꿔놓고 하다가 그분이 할때는 또 스타일 바꿔놓고 하고 그랬습니다. 그때 eclipse 를 사용했는데, 아시다 시피
설정바꾸고 단축키 한번만 누르면 되는 일이죠.
navigator 할때는 스타일이 다른 코드를 보는건 참 불편했던 기억이 있습니다.

그래도 도구가 간단히 해결해주는 문제라면 구지 강제할필요는 없다라는게 여전히 제생각입니다.

ㅡ,.ㅡ;;의 이미지

wonny wrote:

indentation이나 naming rule 등의 convention은 가장 효율적이고 유용하기 때문에 하나를 정해놓는 것이 아니라 수많은 사람이 공동작업을 원할하게 하기 위해 그냥 약속하는 것이라고 생각합니다.
indentation은 아주 사소하게 보일지는 모르겠지만, 의외로 남의 소스를 면밀히 살펴보는데 거슬리게 됩니다. 이 때 모두가 조금씩 자기에게 맞지 않더라도 convention을 정하고 준수하려고 조금씩 노력하게 되면 모두에게 득이 된다고 생각합니다.
mendatory가 없으면 자신의 rule을 고집하듯이 남도 자신의 rule을 고집하게 되고 결국 프로젝트에서 자신이 하나의 규칙에 맞춰가는 시간보다 더 많은 시간을 남의 소스를 보며 짜증내는데 소모하게 될 지 모릅니다.
작문할 때 한 paragraph가 끝나면 line feed하는 것이 효율을 위한 것보다는 약속이듯 이러한 규칙은 필요하다고 생각합니다.

공동작업 대형프로젝트이기때문에 맞추어야한다고 하시는분들
정말 공동작업 많이 해보고 하시는말씀인지 궁금합니다.

제가알기론 대부분공동작업하면 남의소스볼일잘없습니다.
자기꺼 하기도 바쁜데 언제 남의꺼봅니까

그리고 볼일있어도 볼필요가 없습니다. 담당자가 있는데 왜봅니까.
어떻게 하라고 말만하면되지.

그리고 정말대형프로젝트 주로하시는분이면 코딩스타일 맞추는게 얼마나 불편한지 알겁니다. 코딩스타일이 한번맞추면그게 쭈욱가느냐.. 그렇지 않습니다. 코딩스타일 맞추다 볼장다봅니다.

저도 대형프로젝트 공동프로젝트 할만큼했다고 봅니다.
아니 그런것만 하고 있습니다.

그리고 프로젝트 보통 6개월~1년짜리 많습니다. 대형프로젝트는
그리장기간 진행되지 않습니다. 돈이 많이드니까요..따라서
그짧은기간동안에 코딩스타일트집잡으면 아주 골때립니다.
그것때문에 개발속도가 현저히 떨어집니다.
그리고 프로젝트 할때마다 완전 딴판입니다. 왜냐하면 당연히 다틀린맴버가 구성되기때문이죠..

그리고 다개발한후에 스타일맞추는건 쉽지만 개발도중에 강요하는건 무지 힘들다는거도 아시겠죠..
코딩스타일은 단지 스타일로만 끝나는것이 아니기때문이죠..

그리고 공동프로젝트 대형프로젝트 많이 해보면 남의소스 스타일이 다른소스보는건 별로 거리낌이 없습니다. 맨날보는거니까요..

위에 볼일이 없다고 했는데 여기선왜보는줄아시죠?
나중에 자신이 필요한부분 찾아서 써야하기때문이죠..
그래서 결국 남의소스보는데는 이력이납니다.

스타일이 다른프로그램보는데 뭐가 문젠가요..
다양한사람들과 몇번해보면 스타일이 다른소스 보는데는
아무렇지 도 않습니다.
단지 자기도 그렇게 따라작성하라고 했을때 문제가 생기죠..

프로그래머들에게서 코딩스타일이나 툴 은 상당히 중요한부분입니다.
말하자면 연장과 연장사용하는 방식인셈이죠..

그리고 프로그래머라면 남의 소스분석하고 읽는것은 의무 입니다.
그러나 남의 코딩스타일은 의무가 아니라 권장이면 충분합니다.

만일 당신이 어떤프로젝트에 갔더니 변수명은 3자리이하로 써야하며 소스코드 Line은 그라인에 사용된함수의 갯수만큼 다음줄을 띄워야하며
공백은 변수명의 길이만큼 중간에 공백을 삽입하되 최대 3이상띄우면 안되고 등등의 백여가지 규정을 정해두고 만일 하나라도 틀릴시에 반송된다고한다면 어떨까요..


----------------------------------------------------------------------------

iolo의 이미지

별로 불편하지 않습니다.

체크인할때 강제로 리포매팅해버립니다.

대형프로젝트할때 남의 코드를 볼일이 없다는 것은 말단 개발자의 입장입니다.
PL은 자기 파트의 개발자들의 코드를 모두 봐야합니다. 그렇게 하지 않는 PL은 직무유기입니다. 적어도 저는 그렇게 생각합니다.
그리고 소스코드도 산출물입니다. 산출물은 기록유지 차원에서 만드는 것입니다. 만들때는 다시 보지 않겠지만, 유지보수 단계에서 제 3자가 보게됩니다.
회사에서 만든 코드는 개인의 소유물이 아닐 뿐더러... 개인의 예술욕구의 발로가 아닙니다.

Quote:

만일 당신이 어떤프로젝트에 갔더니 변수명은 3자리이하로 써야하며 소스코드 Line은 그라인에 사용된함수의 갯수만큼 다음줄을 띄워야하며
공백은 변수명의 길이만큼 중간에 공백을 삽입하되 최대 3이상띄우면 안되고 등등의 백여가지 규정을 정해두고 만일 하나라도 틀릴시에 반송된다고한다면 어떨까요..

이건 자신의 주장을 관철시키기위한 부적절한 예입니다. 이런 코딩 컨벤션을 제시하는 회사가 있다면 그만 두는게 상책입니다.

그리고 특정 코딩 컨벤션을 강요하려면 도구를 사용해서 해야지(indent나 checkstyle이나... 등등) 타이핑을 그렇게 하라고 하는 건 곤란하죠.

코딩 컨벤션의 강제를 납득할수 없다는 분들이 의외로 많이 계시군요.
저로썬 그 사실이 더 납득이 안됩니다.

----
the smile has left your eyes...

ㅡ,.ㅡ;;의 이미지

iolo wrote:
별로 불편하지 않습니다.

체크인할때 강제로 리포매팅해버립니다.


두번다시 수정할일 없다면 불편하지 않겠죠..
다음에 리포멧된 프로그램을 수정해야 하면 어떨지 생각해보세요
Quote:

대형프로젝트할때 남의 코드를 볼일이 없다는 것은 말단 개발자의 입장입니다.


님이 생각하실때 개발자가 말단이라서 시키면 시키는데로 해야하는사람이라고 생각하십니까..
물론님은 진정한개발자입장이 아닌 관리적인 입장에 있으시군요..
물론 님은 개발자라고 하시겠지만 님스스로 개발자입장에서 약간벗어났다고 말하는거나 다름없습니다.

Quote:

PL은 자기 파트의 개발자들의 코드를 모두 봐야합니다. 그렇게 하지 않는 PL은 직무유기입니다. 적어도 저는 그렇게 생각합니다.
그리고 소스코드도 산출물입니다. 산출물은 기록유지 차원에서 만드는 것입니다. 만들때는 다시 보지 않겠지만, 유지보수 단계에서 제 3자가 보게됩니다.

개발자로서 소스코드 재대로 못보면서 무슨일을 할수 있을까요..
더구나 자기와 스타일이 좀틀리다하여 그게 불편하다고한다면
그게 이상하지요 PL 정도되면 스타일따져 편식해서볼단계는 아니지요..
그리고 개발단계에서는 확실히 스타일 강제할이유는 없다는뜻이군요.. 유지보수단계들어가기전에 툴에 의해 변환하면되겠네요..
그리고 유지보수하는사람이 들어와서 (제3자) 이사람역시 그것도볼줄모르면 무슨유지보수하겠다고 하는건지...

또한 유지보수하는사람이 앞에서 규제한 코딩스타일이 아니면 어쩌시려고요..이사람또한 상당히 짜증날껄요..
시간이 지나면 익숙해질꺼라고요? 개발단계에서부터 억지로 끼워맞추어진 스타일 그리 합리적으로 짜여지지도 않았고 따라서 그리 빨리 익숙해지지도 않습니다.
또한 규제가 없어도 역시 익숙해지는건 마찬가지입니다.

그리고 겨유 유지보수 제3자가 보기편하기 위해서 개발비용을 10%라도 더들일 필요가 있을까요?

Quote:

회사에서 만든 코드는 개인의 소유물이 아닐 뿐더러... 개인의 예술욕구의 발로가 아닙니다.

님이 뭔가 잘못생각하시고 계신것 같습니다만. 개인욕구의 발로 때문이 아니라 일을 합리적으로 하고자 말하는것입니다.
Quote:

Quote:

만일 당신이 어떤프로젝트에 갔더니 변수명은 3자리이하로 써야하며 소스코드 Line은 그라인에 사용된함수의 갯수만큼 다음줄을 띄워야하며
공백은 변수명의 길이만큼 중간에 공백을 삽입하되 최대 3이상띄우면 안되고 등등의 백여가지 규정을 정해두고 만일 하나라도 틀릴시에 반송된다고한다면 어떨까요..

이건 자신의 주장을 관철시키기위한 부적절한 예입니다. 이런 코딩 컨벤션을 제시하는 회사가 있다면 그만 두는게 상책입니다.

님은 이런코딩 컨벤션을 제시하는 회사가 없다는 건가요?
그렇다면 궂이 코딩컨벤션을 규제하지 않더라도 일반적으로
특이하게 이상하게 작성하는사람도 없다는걸 아시겠네요..
회사에서는 프로젝트 인원을 뽑을때 코딩스타일을 미리 물어봐서
맞는사람 뽑는게 더편하지 않을까요.. 개인도 좀더 자기와 맞는곳에
갈수 있는 구분도되고요..

Quote:

그리고 특정 코딩 컨벤션을 강요하려면 도구를 사용해서 해야지(indent나 checkstyle이나... 등등) 타이핑을 그렇게 하라고 하는 건 곤란하죠.

코딩 컨벤션의 강제를 납득할수 없다는 분들이 의외로 많이 계시군요.
저로썬 그 사실이 더 납득이 안됩니다.

전 개발자와 회사와 유지보수제3자가 통털어 더 불합리한방법인데
애써 자신의 무덤을 파는 이유가 더납득이 안갑니다.

사실 아무리 규제하더라도 결국 칼자루는 개발자가 쥐었습니다.
개발자도 사람인이상 규제로인한 스트레스,짜증 등이 결국
코딩에 녹아들어간다는 사실을 아셔야합니다.

간혹 도무지 이해할수 없는 아니 용납할수 없는 코드를 만나기도 합니다. 그러나 조만간 이해하게됩니다.
전자의(개발자가) 오죽 짜증났으면 이렇게 해놨을까..

제가 경험한 불합리한 규제들 몇가지만 예로들면 함수를 특정규칙값 이하로 쪼개 라는 규정도 있습니다.
분명히 하나로 되어 있어야할것인데 강제로 쪼개려니 굉장히 어색하죠..
또한 오류를 수정할수 없도록해놓은것도 있습니다.
원 규정이나 모듈에 오류가 포함되어 있는데 나중모듈이 정석적으로 코딩했을때 그것과 충돌을 일으켜 결과적으로 계속 오류코드를 만들어나가아햐는 경우도 있었습니다.
사실 말도 안되는그런건데 수백개의 모듈을 다그렇게 사용하고 있더군요..그러니 시스템이 좀 심기가 뒤틀리면 한번씩 삐딱하게 동작하고..
또한 컴파일등도 매우 불편한규정을 정해놓은곳도 있습니다.
컴파일한번하는데 매우 힘들도록 그래서야 어디 디버깅이나 재대로 할수 있을까요..
또한 로그등도 규제하고 있어 문제발생시 필수적으로 보아야할것을
볼수없는경우도 있고 말을하자면 한도끝도 없습니다.
사실 3주면 개발완료할일을 스타일규제과 엉터리로인하여 수개월이 지나도 안정화에 달하지 못하는경우를 종종봅니다.
그러나 그런규제를 정한 당사지는 그사실을 모른다는겁니다.
자기가 정한것이 최고 인줄안다는거죠..


----------------------------------------------------------------------------

creativeidler의 이미지

Quote:
코딩 컨벤션의 강제를 납득할수 없다는 분들이 의외로 많이 계시군요.
저로썬 그 사실이 더 납득이 안됩니다.

이건 아마도

Quote:

만일 당신이 어떤프로젝트에 갔더니 변수명은 3자리이하로 써야하며 소스코드 Line은 그라인에 사용된함수의 갯수만큼 다음줄을 띄워야하며
공백은 변수명의 길이만큼 중간에 공백을 삽입하되 최대 3이상띄우면 안되고 등등의 백여가지 규정을 정해두고 만일 하나라도 틀릴시에 반송된다고한다면 어떨까요..

이런 컨벤션을 강요당한 기억이 있기 때문이 아닐까요? ^^

kwon37xi의 이미지

ㅡ,.ㅡ;; 님...

코드 컨벤션의 범주를 어디까지 둬야 할지 모르겠습니다만,

어쨌든 저는 코드 컨벤션을 지키는 것이 몇 주짜리 일을 몇 달씩 걸리게 만드는 일이라고 전혀 생각지 않습니다만 대체 어쩌다가 그런 말도 안되는 코드 컨벤션을 만나서 이렇게 코드 컨벤션에 반감을 같게 되셨는지..

코드 컨벤션을 정하고(사실 거의 대부분이 SUN의 코드컨벤션에 이미 익숙해져 있죠, 정할것도 별로 없습니다), 그리고 그외에 변수명등에 대한 제약을 정하는데 제가 보기엔 하루면 충분합니다.

대체 얼마나 독특한 방식으로 코딩하시기에 그게 적응하는데 몇달이나 걸리는지 도무지 저로서는 이해가 안되는군요.

코드 컨벤션은 합리적이고 통일적으로 프로그램을 짜라는거지, 침대가 짧으니 다리를 짤라라는 식으로 정하는게 아닙니다.

SUN의 코드 컨벤션에서 전혀 그런것을 못느꼈는데 님은 느끼셨는지요? 그런 말도안되는 컨벤션을 정했다면 정한사람에게 항의하고 다시 정하도록 하고 전체 개발자들에게 공지하십시오.

코드 컨벤션의 힘은, 코드 컨벤션이 없는 공동 작업 프로젝트를 한번만 겪어봐도 알텐데 말이죠.

코드 컨벤션( 변수 명명규칙, 메소드 명명 규칙 등 포함)없이 운영한 프로젝트를 한 번만 해보고서, 그 상태에서 남의 코드를 유지보수 해보면 코드 컨벤션의 힘을 바로 느낄껍니다.

참고로 저는 경력이 일천합니다.(2년..) 근데, 한 프로젝트를 길게 하기 보다는 다른 사람이 이미 완성한 프로젝트 혹은, 만들고 있는 프로젝트에 가서 남들이 짠 코드를 보면서 수정할 사항들을 알려주는 등의 일을 합니다.
이짓 조금 하다보면 각 프로젝트 별로 코드 컨벤션이 다른 것이 문제가 아니라, 한 프로젝트내에서 코드 컨벤션이 정해져 있지 않을때, 코드 리딩이 얼마나 괴로운 일이 되는지 단박에 알 수 있습니다. 그리고 제 경험으로 볼때 코드 컨벤션이 없는 프로젝트의 경우 각 개발자들이 짠 코드의 품질도 코드 컨벤션이 있는 프로젝트에 비해 매우 떨어집니다.(코드 품질과 코드 컨벤션의 상관관계는 모릅니다. 그냥 경험적으로 그렇습니다.)

마지막으로 저뿐만 아니라 많은 소프트웨어 공학 관련 서적들에 나오는대로...

만약 제 밑에 코드 컨벤션 하나 적응하는데 일주일 이상(이거도 너무 깁니다) 걸리는 개발자가 있다면, 그 사람은 조용히 제 프로젝트에서 살짝쿵 빼주겠습니다.

영웅은 필요 없습니다.

iolo의 이미지

"코딩 컨벤션을 정하고 이것을 따르는 것보다
나름의 코딩 컨벤션을 허용하는 것이 더 합리적이다"라는 주장은 별로 설득력이 없어보입니다.

코딩 컨벤션을 코딩 단계부터 지켜서 입력하자는 얘기는 아닙니다. 다만 공유된 장소(CVS죠)로 커밋할 때는 맞춰야 한다고 봅니다. 물론 내려받아서(co/up) 코딩할때 자기만의 코딩 컨벤션으로 재 변환해서 작업하는 것은 자유입니다.

PL은 여러가지 코딩 컨벤션을 소화해낼 수 있어야 한다는 부분은 저도 동의합니다. 그러나 말단 개발자(죄송합니다. 다른 적당한 용어가 없어서...)들이 자기 코딩 스타일을 고집하는 같은 이유로 선임 개발자(그들도 코딩을 합니다)들도 역시 자기 코딩 스타일을 고집할겁니다. 오히려 신입보다 더 오랜 경륜으로 자기 나름의 스타일이 확고하겠죠. 그리고 그것을 허용하면 여러가지 코딩 스타일이 난무하는 코드를 보게되겠죠. 유지보수를 하게될 개발자도 마찬가지입니다.
저도 여러사람의 코드를 관리하지만, 그 사람들 이상의 코딩을 합니다. 저도 제 나름의 스타일(오픈소스 프로젝트에선 그 스타일을 마음껏 사용하죠)이 있지만 그냥 코딩 컨벤션에 맞춥니다. 말하지면 이클립스에서 수시로 esc,ctrl+f를 눌러댑니다.

선임 개발자라는 이유로 후임 개발자에게 자신(선임자)의 코딩스타일을 쓰도록 강요해도 된다는 것은 절대 아닙니다. 코딩 컨벤션은 모두의 묵시적/명시적 동의하에 정해져야 것입니다. 선임의 입김이 후임보다 더 쎈것이 불만이라면 그건 아무도 도와줄수 없는 문제군요. 그냥 널리 알려져있는 몇가지 대표적인 코딩 컨벤션(gnu건 knr이건, 자바라면 썬의 그것이건)을 기초로 수정하는 정도겠지요.
앞에서도 말했지만 변수명은 3자로 하라는 코딩 컨벤션을 가진 회사라면... 일찌감치 다른 곳을 알아보는 쪽이 건강에 좋지 않을까요?

회사에서의 코딩은 공장에서의 생산과 같은 것입니다. 부품이 표준화되는것이 효율적이라는 것은 분명한 사실입니다. 소스코드가 왜 부품이냐고 하시겠지만 말씀드렸다시피 (고객이 요구하건 아니건) 그것은 산출물입니다. 상품의 부속품이죠. (원형이 보이지 않는다고 해서 부품이 아닌것은 아니지 않습니까?)

말이 길어졌는데, 정리하면:
"코딩 컨벤션을 정하고 이것을 따르는 것보다
나름의 코딩 컨벤션을 허용하는 것이 더 합리적이다"라고 할만한 객관적이고 구체적인 자료를 제시해야 할듯 합니다.

p.s. "왜 그걸 내가 제시해냐 하냐? 니가 그게 아니라고 할만한 근거를 제시해라!"라고 하신다면, 아직은 코딩 컨벤션을 정하고 따르는 것이 일반적이기 때문입니다. 악법은 바꿔야하지만 그 전까진 법입니까요... 그러기위해선 그것이 악법이라는 것, 새로운 제안이 더 좋다는 것을 증명해야 하는 것이죠. (절대 다수당이라면, 당론이라고 밀어붙이는 방법도 있나요?)

----
the smile has left your eyes...

ㅡ,.ㅡ;;의 이미지

iolo wrote:
말이 길어졌는데, 정리하면:
"코딩 컨벤션을 정하고 이것을 따르는 것보다
나름의 코딩 컨벤션을 허용하는 것이 더 합리적이다"라고 할만한 객관적이고 구체적인 자료를 제시해야 할듯 합니다.

p.s. "왜 그걸 내가 제시해냐 하냐? 니가 그게 아니라고 할만한 근거를 제시해라!"라고 하신다면, 아직은 코딩 컨벤션을 정하고 따르는 것이 일반적이기 때문입니다. 악법은 바꿔야하지만 그 전까진 법입니까요... 그러기위해선 그것이 악법이라는 것, 새로운 제안이 더 좋다는 것을 증명해야 하는 것이죠. (절대 다수당이라면, 당론이라고 밀어붙이는 방법도 있나요?)

님은 코딩컨벤션을 정하는것이 크게 어긋나지 않고 잘된경우만을 생각하고 있기때문입니다.
어떤자바프로그래머가 있고 Sun코딩인벤션을 잘지켜왔고 매우 좋아하는데 어느날 펌웨어하던 팀장오게되었고 모든스타일은
C처럼하며 C++은 클레스를 쓰지말것이며..등등.. 정한다면 어떨까요..? 참무식하겠죠..

사실 언어가 달라지고 환경이 달라지고 구현목적이 달라지면
그에따른 코딩스타일도 매우 미세하게 달라져야하는것이죠
여기에 누가 그것 크게 다르지 않는것쯤이야 이렇게 하나 저렇게하나 뭐가 문제냐 라고 할지모르나 문제입니다.
하물며 운동화 하나를보더라도 축구할때 야구할때 등산할때 조깅할때 다틀립니다. 그리고 그러한 모양세가 나온것도 다 아유가 있습니다. 축구할때 운동화신고 해도 된다고요? 해도 되기야되겠죠..
그러나 축구화 농구화 운동화 여러가지 다신어보고 아 이게 좋겠군
하고 축구화 신었는데 이국가의 경우에는 잔디가 너무 무르기때문에 축구화의 요철이좀 굻게재작해서 신는것이 더유리하겠군..
머이러면서 개선해서 신을수도 있을겁니다.
안그런가요..? 축구선수라면 누가 축구하는데 고무신신고와서 축구할사람 누가 있을까요..

자그럼 감독이 농구하다온감독이와서 농구화가 최고여~! 전부농구화통일하도록~!ㅡㅡ;;
이랬다면 선수들 어떨까요.. 프로젝트할때 이런경우 없다고요?
종종 있습니다. C를 마치 자바처럼 억지로 끼워맞추려는사람..
반대로 자바를 C처럼 억지로 끼워맞추어하라고 하면어떨까요..

그리고 코딩컨벤션을 정하고 룰을지키도록하고 하는것이 반드시 득이된다는생각이 과연 그럴까요?
정했을경우 분명 어설프게 적용된 프로그램도 있을것입니다.

그리고 그런규제가 없을경우.. 그코딩컨벤션보다 더기가막히게 잘하는사람도 있을것이고 못하는사람도 있을것이고 이런사람저런사람이 생겨날것입니다.

그를보는사람은 다양한 방식을 경험하게 될것이며 장단점을 알게될것입니다. 다음번프로젝트에서는 이사람은 전에 자기가경험한것중에 최고의것을 사용하게 될것입니다.
또한 프로젝트 진행중하면서 새롭개 끊임없이 개선될것입니다.
과연 어느것이 더발전적일까요..

그리고 딱정해버린곳을보면 더이상의 발전은 없습니다
또한 시간이 갈수록 새로운것추가되고 변형되고
예외가생기고..날이갈수록 프로그램은 걸래가되어갑니다.
아니라고 하시겠습니까?

종종 덩치가 큰 시스템을 새로운 언어로 완전히 재개발하는경우
있습니다. 기존 개발언어의 기능에 한계가 있어 그런것같습니까
개발언어에 한계가 있는경우는 잘없습니다. 웬만큼 구현방법은틀리지만 할수 있게 되어 있습니다.
그런데도 완전 갈아 업어야하는경우는 날이갈수록 시스템은 늘어나기마련인데 정리는 안되고 답이안나오게 걸래가 되어가기때문입니다.
프로그램이 날이갈수록 발전이되어야할텐데 오히려 걸래가 되어갑니다.

이걸재대로 고쳐놓을까.. 아니면 어차피 돌던지말든지 내상관인가..기존해놓은대로 붙여넣기하고 냅둘까..이런고민 안하시나요?

그리고 잘못된것 건의해서 수정해서 더좋게 발전시키면되지?
라고 생각하시나요? 그게 말처럼 안된다는건 잘아시죠..

코딩컨벤션은 초기 인수인계받을때 편할지 모릅니다.
그러나 시간이 가면갈수록 그것은 자신의 목을조일뿐입니다.

그리고 제가말하고자하는건 완전히 난잡하게 해도좋다란것이 아닙니다.
단지 과도하게 이상한것만 배제하고 좋은방식을 한번쯤권장정도에서 끝내도 된다는것이지요..


----------------------------------------------------------------------------

iolo의 이미지

분명히 말씀하신 사례들도 있을 것이고 변수명을 세자로 쓰라고 하는 곳도 있겠죠.
그리고 그 나름의 원칙와 이유가 있겠지만... 그건 어디까지나 비정상적이 경우입니다.

그러나, 그런 비정상적인 사례를 이유로 일반적인 상황에서의 공동 작업에서 코딩컨벤션을 정해서 지키는 것은 나쁘다라는 식은 곤란하네요.

짧게 말해서 "구더기 무서워서 장 못 담그랴"

----
the smile has left your eyes...

iolo의 이미지

글을 올리고 나니 또 한가지 글귀가 생각 납니다.

자기 주장을 번복하는 것이 싫어서 자꾸 억지 논리를 끼워 맞추다보니..
이젠 빠져나올 길이 없어 보입니다.

짧게 말해서 "자승자박"

----
the smile has left your eyes...

ㅡ,.ㅡ;;의 이미지

위에님 그건 넘겨집기 입니다.논리를 억지로 끼워맞춘부분없읍니다.
대부분 자신들이 정한 룰에는 문제가 없을꺼라고 생각합니다.
아니 오히려 참잘만들었다라고 생각하는것 같습니다.
그러나이건 얼마나 큰 착각인지 모릅니다.
왜냐하면 누가 만들어도 잘만들지 못합니다.
실제로 하지도 않으면서 어찌 모든것을 안다고 할수 있을까요..
제가위에 축구를 예로들었듯이 좋은방법은 항상새롭게 나오기마련이기때문이죠...
만일 히딩크를 기존에 감독이하던룰데로만 감독하라고 못박았다면
아마도 4강신화는 없었겠죠..

코딩컨벤션 강제하는데는 자가당착의 모순이 숨어 있습니다.
논리적으로따져보면
1. 개발자들이 허용범위를 벗어나서 용납할수 없는수준의 스타일의개발을한다 는전제가 있어야만 위의 룰을 정하게됩니다.

맞습니까?

2. 코딩컨벤션 강제하는 사람도 개발자출신혹은 아니라면 더욱불행한경우가 발생하겠지요..

3. 따라서 코딩컨벤션 강제하는사람도 일반적으로 용납할수 없는수준의 스타일을 강제하는 경우가 발생할수 있게됩니다.

4. 두경우 어느것이 프로젝트 진행에 더큰타격을 가져오며 발생확률은 어떨까요.. 타격은 당연히 후자가 더크며 개발자가 코딩컨벤션을 강제하는사람이됬다면 발생확률도 비슷하다고 봐야겠지요

5. 그러면 어느것이 더 합리적인지 답은 나오지 않습니까.


----------------------------------------------------------------------------

kwon37xi의 이미지

ㅡ,.ㅡ;; wrote:

3. 따라서 코딩컨벤션 강제하는사람도 일반적으로 용납할수 없는수준의 스타일을 강제하는 경우가 발생할수 있게됩니다.

4. 두경우 어느것이 프로젝트 진행에 더큰타격을 가져오며 발생확률은 어떨까요.. 타격은 당연히 후자가 더크며 개발자가 코딩컨벤션을 강제하는사람이ㅤㄷㅚㅆ다면 발생확률도 비슷하다고 봐야겠지요

아뇨..

ㅡ,.ㅡ;; 님과 제가 다르게 생각하는게 이것인 거 같습니다.

다른 분들은 어떻게 생각하는지 모르지만, 코드 컨벤션이 불합리함을 증명하면 바꾸면 그만이지, 이게 무슨 헌법입니까?

그리고 바꾼것은 모든 사람들에게 공지하고, 다시 그렇게 지켜나가는거죠.

중요한것은 모든 바뀌게 되면 모든 사람이 함께 수긍하고 바꿔야한다는 거라고 봅니다.

그리고... 3번과 4번의 말은 바로 딱 "구더기 무서워 장 못담근다." 이거 맞는거 같습니다.

남들이 도저히 용납할 수 없는 코드 컨벤션을 자기만 옳다고 남의 말은 전혀 듣지 않고 강제하는 그런 PM이 있는 프로젝트는, 코드 컨벤션이 있든 없든 잘 되긴 힘들다고 봅니다.

한마디로 구더기 PM이겠죠..

장을 담궈도 구더기가 끼면 먹기 힘들고, 구더기 무섭다고 안담궈도 못먹고.. 마찬가집니다.

ㅡ,.ㅡ;;의 이미지

바꾸기 힘듭니다. 프로젝트가 크면클수록..
바꾼다는건 아예포기하는게 상책입니다.
그리고, 그걸바꾸려 하느니 그냥 걸래만들고 말게됩니다.
그리고 그걸 설명하려다가 엉뚱한곳에서 시간허비하고 결과적으로
답안나옵니다.

그리고 변수명 3자리 규정하는거 실제 있었던일입니다.
프로그램전체는 아니고 일부분이긴했지만요..
그거 왜그렇게 하냐고 따져봐야 결국 소영없습니다.

당연한것이 사람생각이 다틀린데 어찌 그게 답이나올까요..
그리고 보통 그런것정하는사람은 웬만해서는 다른사람말을 안듣습니다. 오히려 화내죠..


----------------------------------------------------------------------------

iolo의 이미지

ㅡ,.ㅡ;; wrote:

1. 개발자들이 허용범위를 벗어나서 용납할수 없는수준의 스타일의개발을한다 는전제가 있어야만 위의 룰을 정하게됩니다.

아닙니다. 별 문제가 없는 코딩 컨벤션이라고 하더라도 통일해야 한다고 하는 것입니다.

ㅡ,.ㅡ;; wrote:

2. 코딩컨벤션 강제하는 사람도 개발자출신혹은 아니라면 더욱불행한경우가 발생하겠지요..

역시 아닙니다. 마소의 기자들이 다 프로그래머(또는 출신)이라고 생각하십니까?
컨벤션은 단어 그대로 "관행"입니다. 실제로 그 관행이 만들어지는 과정에는 많은 프로그래머들의 시행착오가 담겨있겠죠. 그걸 제 3자 - 보통 프로젝트 매니저들 이겠죠 - 정리한다고 해서 이상할 것은 없습니다. 그럴 자격이 있기 때문에 프로젝트 매니저를 하는 겁니다. 낙하산 PM이라구요? 잘못된 일반화를 시도하지 마시길...

ㅡ,.ㅡ;; wrote:

3. 따라서 코딩컨벤션 강제하는사람도 일반적으로 용납할수 없는수준의 스타일을 강제하는 경우가 발생할수 있게됩니다.

잘못된 코딩 스타일은 코딩 "컨벤션"이라고 하지 않습니다. 그냥 코딩 "스타일"일 뿐이죠. 그러나 그것이 강제된다면 따를 수 밖에 없는 게 월급쟁이입니다.

ㅡ,.ㅡ;; wrote:

4. 두경우 어느것이 프로젝트 진행에 더큰타격을 가져오며 발생확률은 어떨까요.. 타격은 당연히 후자가 더크며 개발자가 코딩컨벤션을 강제하는사람이ㅤㄷㅚㅆ다면 발생확률도 비슷하다고 봐야겠지요

타격은 당연히 전자가 더 큽니다. 다소간에 문제의 소지가 있는 코딩 스타일이라도 모두 같이 쓴다면 모두가 이해할 수 있습니다. 반면 별로 문제가 없는 코딩 스타일이라도 제각기 다른것을 쓴다면 서로 이해하는데 어려움이 따릅니다. (물론 이해할 수 없는 것은 아닙니다. 효율성의 문제일 뿐이지요).

A는 함수이름을 소문자로 시작해서 단어를 대문자로시작하는 이른바 스몰톡식 카멜 표기법을 사용합니다. B는 함수이름을 소문자만으로 쓰고 단어 사이를 띄우는 C언어식 표기법을 사용합니다. C는 그 식별자를 보고 함수포인터라고 생각할까요 변수라고 생각할까요? 물론 코드를 보면 알수 있습니다. 그 얘기가 아니지 않습니까?

ㅡ,.ㅡ;; wrote:

5. 그러면 어느것이 더 합리적인지 답은 나오지 않습니까.

그런것 같습니다. 체계적으로 풀어보니 더욱 명쾌하군요.

----
the smile has left your eyes...

ㅡ,.ㅡ;;의 이미지

iolo wrote:
ㅡ,.ㅡ;; wrote:

1. 개발자들이 허용범위를 벗어나서 용납할수 없는수준의 스타일의개발을한다 는전제가 있어야만 위의 룰을 정하게됩니다.

아닙니다. 별 문제가 없는 코딩 컨벤션이라고 하더라도 통일해야 한다고 하는 것입니다.

일단 1번만 따져보면
별문제가 없는 코딩 컨벤션이라도 하더라도 통일해야한다
별문제가 없는데 왜 통일할까요
님의 주장대로 효율성? 때문이라고요?

그건 효율성의 문제가 있기때문에 통일한다는뜻아닙니까..
효율성이 떨어지기때문에 용납할수 없다는뜻아니었던가요?
용납할수 있는데 뭣하러 강제 합니까.
그리고 개발시의 효율성은 강제하면 할수록 떨어진다는건 인정하시는지요..


----------------------------------------------------------------------------

iolo의 이미지

Quote:

그리고 개발시의 효율성은 강제하면 할수록 떨어진다는건 인정하시는지요..

엡. 인정합니다. 저라고 해도 제가 쓰는 코딩 스타일이 제일 좋죠.
그 개인 한명에겐 떨어지겠죠. 그러나 전체로 보면 득입니다.

산수를 해볼까요?

개발자가 N명이라고 하고,
자기 코딩 컨벤션이 아닌 코딩 컨벤션을 따르는데서 오는 손실을 E라고 하죠.

통일된 코딩 컨벤션에서는 N*E의 손실이 생깁니다.
개인별 코딩 컨벤션에서는 N*(N-1)*E의 손실이 생깁니다.

나의 작업 효율이 떨어지니까 공통 코딩 컨벤션을 못따르겠다면...
혼자 하면 됩니다.

----
the smile has left your eyes...

creativeidler의 이미지

ㅡ.ㅡ;;님께 썬의 자바 코드 컨벤션을 한 번 읽어보라고 권하고 싶습니다. 그 중에 그렇게 ㅡ.ㅡ;;님의 개발 생산성을 헤칠 만한 것이 있는지 한 번 찾아보세요. 그 정도라면 누구라도 납득할 수 있지 않을까 싶은데요. 아니면 혹시 다 읽어봤는데 그런 컨벤션도 지키면 생산성이 떨어질 것 같다고 생각하시는 것인가요?

iolo님이 '산수'로 명쾌하게 설명해주셨듯 컨벤션의 통일은 중요합니다. 그러나, ㅡ.ㅡ;;님 주장처럼 불합리한 컨벤션이 가져오는 불이익도 만만치 않죠. 그래서 전 늘 컨벤션은 개발자간 토론을 거쳐서 합리적인 사항들로 최소화시켜 정하되, 정한 것은 반드시 지켜야한다고 주장합니다.

임창진의 이미지

제가쭉읽어봤는데요
ㅡ.ㅡ;;님이 iolo님이나 creativeidler님이 지적하신거처럼
'컨벤션을 지키는것' = '생산성이 떨어짐' 이라 생각하시는거 같지는 않구요 이론과 실제는 다르다 라는 말씀을 하시려는거 같습니다.
저도 iolo님 말씀에 동의하는데요 내가 개발자의 role 을 맡고있으면 현실적으로 정해진 rule이 잘못되었다고 그걸 뒤집을수는 없는경우가 많았습니다
마치 tv 시사프로그램에서 여러가지 근거로 어떤대형국책사업이 잘못된것인걸 보여주지만 시민단체나 NGO 언론들이 그걸 중지하거나 변경하는게 쉽지않은것처럼 말입니다.(불가능하다는건 아닙니다)

가족이달린사람이 그지같은 rule 때문에 괴로워도 위에 어떤분 말씀처럼 절이싫으면 중이떠나라 그렇게 할수는 없는 노릇이지요.
ㅡ.ㅡ;;님이 원래 말씀하시려던 의도가 조금 왜곡되어서 받아들여지고
있는거 같아서 몇자 적어봅니다.

ㅡ,.ㅡ;;의 이미지

코딩컨벤션을 강제하는것은 마치 자유주의와 사회주의와 같습니다.
자유시장의 다양함이 불편하고 발전이 없을것같지만 오히려 정반대임을 잘알고 계실겁니다.
계획경제의 모든것을 계획하고 마치 완벽하고 최고인것인양되지만.
그것은 조만간 자유로움의 발전보다 뒤지게 되어 있습니다.

만일 옛날 에셈이나 이런시절부터 그러한것이 생겨났다면
아마도 썬의 자바 코드 컨벤션은 나오지 못했을겁니다.


----------------------------------------------------------------------------

iolo의 이미지

코딩컨벤션에서 사회주의 자본주의까지 나오다니...

효율성이라는 명분으로 코딩컨벤션을 강요하는 것이 오히려 더 자본주의 답다는 생각은 안하십니까? 사실 제가 코딩컨벤션이라는 것에서 맘에 안드는 부분이 그 점입니다.

힘없는 소수의 의견이 무시되고 힘을 가진 다수의 의견만이 인정되는 것... 그것을 사회주의라고 보는 것이 더 이상하지 않습니까?

사회주의니 자본주의니 하는 것이 등장할 자리도 아니고 말만들기에 따라 얼마다는 해석이 가능하지요. 어느 한가지 측면만을 가진 것이 아니라는 겁니다.

그 모든 것을 떠나서, 우리는 지금 자본주의 세상에 살고 있습니다.
그럼 거기에 맞춰 사는 거지요. 안타깝지만 ㅡ,.ㅡ;;님(참 타이핑하기 힘드네요)이 결정할수 있는 힘을 얻기까지는 힘들어도 참고 이겨나가는 수 밖에요.

자본주의와 사회주의에 대해서 얘기하는 것은 논점일탈인듯 하니 이 정도로 하겠습니다.

임창진님께서 좋게 마무리할려고 변호까지 해주셨는데...
정말 코딩컨벤션을 지키는 것이 생산성이 떨어진다고 생각하시나 봅니다.

어차피 결론을 목적으로 시작한 토론은 아니니까요... 다양한 측면을 볼 수 있었다는 사실에 만족을 하고... 이쯤에서 접도록 하죠. 이념논쟁은 제 전문이 아니라서요.. -.-;

----
the smile has left your eyes...

nohmad의 이미지

코딩 컨벤션을 안 지키면 매번 cvs 커밋할 때마다 엄청난 쓰레기 diff가 쏟아져나올 것이 아닙니까? 물론 merge 하기도 힘들겠지요.

notexist의 이미지

자본주의나 사회주의 보다는 법이나 규범이랑 비슷한거같은데요.
사거리들을 보면 좌회전이 없는 사거리가 많습니다. 이렇게 하는 것은 그것이 전체적으로 더 효율적이기 때문이죠. 그런데 어떤 사람은 거기서 좌회전을 막는 것은 비효율적이라고 생각합니다. 자신의 집이 좌회전하면 바로인데...한참 돌아가야되기 때문이죠. 그래서 그 사람은 내 차를 모는 것은 내 자유야 그러면서 사거리에서 혼자 좌회전을 항상 한다고 하면...전체 교통은 혼란에 빠지겠죠.
제 예도 좀 과한 감이 없지 않지만...어쨋든 코딩컨벤션이라는 것은 자본주의나 사회주의랑은 별 연관이 없어보입니다.
자바코딩컨벤션 정도 되면 이미 자유경쟁을 통해서 선택된 코딩컨벤션 중에 하나가 아닐까 생각합니다. 그것을 프로젝트나 팀에서 정했으면 지켜줄만한 수준의 코딩컨벤션은 된다고 생각합니다. ㅡ,.ㅡ님이 전에 예를 드신 것처럼 말도 안 되는 코딩컨벤션은 아니라는 것이죠.
팀을 운영할때는 어떤 방안을 정할때 자유롭게 의견을 제시하고 서로의 의견을 받아들이고 해서 제일 좋은 방안을 찾아내는 것이 중요합니다. 하지만 일단 하나의 방안을 결정하면 자신의 생각이랑은 쪼오금 다를지라도 따라주는 것이 필요하지 않을까 생각합니다.

그리고 소스관리 프로그램의 diff에 관한 것인데...
clearcase같은 경우에는 단순 라인단위 비교가 아니라 문법에 따라서 비교를 해주기 때문에 diff가 알아서 잘 비교해줍니다.
공백이나 괄호의 위치가 다르지만 내용이 같으면 파란색...
의미가 다르면 빨간색 등으로 표시를 해줍니다.
물론 자동머지할때도 알아서 잘 해줍니다.
소스세이프 볼때는... cvs에 비해서 별 감흥이 없었는데...
clearcase를 비롯 rational의 SE툴은 써보면 참 편한것같습니다.
그런 툴도 있다는 의미에서 적었습니다.

ㅡ,.ㅡ;; wrote:
코딩컨벤션을 강제하는것은 마치 자유주의와 사회주의와 같습니다.
자유시장의 다양함이 불편하고 발전이 없을것같지만 오히려 정반대임을 잘알고 계실겁니다.
계획경제의 모든것을 계획하고 마치 완벽하고 최고인것인양되지만.
그것은 조만간 자유로움의 발전보다 뒤지게 되어 있습니다.

만일 옛날 에셈이나 이런시절부터 그러한것이 생겨났다면
아마도 썬의 자바 코드 컨벤션은 나오지 못했을겁니다.

There is more than one way to do it...

soyoyoo의 이미지

서로 다른 스타일의 두사람이 작업한 소스 코드를 나중에 보게 될 때에는 보는 사람이 좀 괴롭겠죠?

ㅡ,.ㅡ;;의 이미지

제가 님의 글을 서너번 잘읽어보았습니다만..뭐가좀 맞지 않는군요..

iolo wrote:
코딩컨벤션에서 사회주의 자본주의까지 나오다니...

효율성이라는 명분으로 코딩컨벤션을 강요하는 것이 오히려 더 자본주의 답다는 생각은 안하십니까? 사실 제가 코딩컨벤션이라는 것에서 맘에 안드는 부분이 그 점입니다.

제가위 자유주의라고 했습니다.뭐 비슷한말이지만요..
효율성명분으로 강요하는것이 자유주의답다구요? 아무리생각해도 말이 안되는군요..권장과 강요의 차이를 아시죠 강요는 강제입니다.
즉 자유가 없는것이죠..

Quote:

힘없는 소수의 의견이 무시되고 힘을 가진 다수의 의견만이 인정되는 것... 그것을 사회주의라고 보는 것이 더 이상하지 않습니까?


다수의 의견만 인정되는것이 사회주의다..??
이말이 왜나왔는지 알수 없군요..
어쨋거나 소수의 의견을 존중한다면 강제해서는 안되겠죠..

Quote:

사회주의니 자본주의니 하는 것이 등장할 자리도 아니고 말만들기에 따라 얼마다는 해석이 가능하지요. 어느 한가지 측면만을 가진 것이 아니라는 겁니다.


등장할수도 있습니다.. 생각해보세요.. 자유가 있고 없고..
가장비슷한게 자유주의 사회주의(공산주의) 아닙니까?
아마 지나가는사람 "자유","강제" 두단어 던지면 뭐생각할까요..
자유주의,사회주의국가,정치 아주 축소판이구만..

Quote:

그 모든 것을 떠나서, 우리는 지금 자본주의 세상에 살고 있습니다.
그럼 거기에 맞춰 사는 거지요. 안타깝지만 ㅡ,.ㅡ;;님(참 타이핑하기 힘드네요)이 결정할수 있는 힘을 얻기까지는 힘들어도 참고 이겨나가는 수 밖에요.

이말도 왜나오는지 의문이군요.. 당연히 맞추어서 사는거지요..
갑짜기 제 이야기로 돌아섰네요..마치 제가 무슨 제문제를 해결해달라고 했던가요..?
왜, 엉뚱하게 말하시는지..
그리고, 참고로 님은 제상황을 잘못 넘겨짚기 하고 계십니다.
저지금 전혀 님이 생각하는 그런상황 아니거든요..

Quote:

자본주의와 사회주의에 대해서 얘기하는 것은 논점일탈인듯 하니 이 정도로 하겠습니다.

임창진님께서 좋게 마무리할려고 변호까지 해주셨는데...
정말 코딩컨벤션을 지키는 것이 생산성이 떨어진다고 생각하시나 봅니다.

어차피 결론을 목적으로 시작한 토론은 아니니까요... 다양한 측면을 볼 수 있었다는 사실에 만족을 하고... 이쯤에서 접도록 하죠. 이념논쟁은 제 전문이 아니라서요.. -.-;

어차피 결론을 목적으로 시작한게 아니었다..
즉, 당신이 어떠한말을하든 난당신과 장단점을 가려 정확한 결론을 내려한게 아니다..
애초부터 현제 생각하고 있는것이 절대적이라고 믿고 계셨군요...


----------------------------------------------------------------------------

ㅡ,.ㅡ;;의 이미지

soyoyoo wrote:
서로 다른 스타일의 두사람이 작업한 소스 코드를 나중에 보게 될 때에는 보는 사람이 좀 괴롭겠죠?

님은 한사람이 쓴듯한 소설만 읽습니까..
아니면 다양한사람의 소설을 읽고 싶습니까..
전 오히려 여러사람꺼 보는게 즐겁던데요..엉뚱하지만 않다면요..
똑같은내용의 삼국지도 쓰는사람에따라 재미가 다르지요..


----------------------------------------------------------------------------

soyoyoo의 이미지

ㅡ,.ㅡ;; wrote:
soyoyoo wrote:
서로 다른 스타일의 두사람이 작업한 소스 코드를 나중에 보게 될 때에는 보는 사람이 좀 괴롭겠죠?

님은 한사람이 쓴듯한 소설만 읽습니까..
아니면 다양한사람의 소설을 읽고 싶습니까..
전 오히려 여러사람꺼 보는게 즐겁던데요..엉뚱하지만 않다면요..
똑같은내용의 삼국지도 쓰는사람에따라 재미가 다르지요..

아. 물론 그런 느낌으로 본다면 재미있을 수도 있겠군요. 삼국지라.
저도 몇년전에 나온 영웅삼국지인가 먼가, 일본 작가 것이어쓴데, 엄청 읽고 싶어했던 기억이 있습니다.

뭐 제가 아직 실력이 허접해서 소스를 소설읽듯이 즐기며 읽을 수준은 안됩니다.(이 부분 쓰면서 엄청 부끄러웠습니다. :oops: ) 하지만 시간에 쫓겨가며 일해야 할 때는, 조금 불편한 것이 크게 느껴질 때가 있죠.
각 회사의 코딩규칙이 전혀 색다른 곳도 있는데 (제가 느끼기만 색달랐는지 모르겠지만요. 클래스명을 z01002a1이런식으로 한다던지 하는..) 기왕 그렇게 통일될 바에는 모두 그런식으로 익숙해졌으니 맞춰주는 것도 다른 사람을 위한 배려 아니겠습니까. 어차피 저 혼자 일하는 것도 아니고, 나중에 다른 사람이 일을 받게 될지도 모르고요.

어느정도 규모의 프로젝트라면, 프로젝트 문서들에 코딩 규칙들도 명시됩니다.
그런데 나중에 그 프로젝트 유지보수등을 하게 되는 사람이 문서상에 규정된 규칙을 보고 감을 잡고 시작하는데 규칙에 벗어난 소스를 만나게 된다면 조금 귀찮아지겠죠.

iolo의 이미지

ㅡ,.ㅡ;; wrote:
soyoyoo wrote:
서로 다른 스타일의 두사람이 작업한 소스 코드를 나중에 보게 될 때에는 보는 사람이 좀 괴롭겠죠?

님은 한사람이 쓴듯한 소설만 읽습니까..
아니면 다양한사람의 소설을 읽고 싶습니까..
전 오히려 여러사람꺼 보는게 즐겁던데요..엉뚱하지만 않다면요..
똑같은내용의 삼국지도 쓰는사람에따라 재미가 다르지요..

코드 보는 일이 소설같이 재미를 추구하는 일이면 얼마나 좋겠습니까마는...
코드 보는 일은 재미보다는 효율성을 추구하는 "일"이라서요...

off topic:
앞에서 "자유주의"라고 하신부분을 제 임의대로 "자본주의"라고 판단해 버렸네요. 자유주의라는 말은 생소해서요... 문맥을 보고 지레 판단해버린것 같습니다.
말씀하신 자유주의 자유경제를 의미하는 거라면, 자유경제의 자유는 이윤 추구의 자유입니다. 그러나 돈을 받고 일하는 동안에는 인간이 가진 "온전한 자유"를 다 보장받을 수 없는 것 아닐까요? 말하자면 자유를 일부 팔아버린 거죠.
말씀 하신 자유주의가 자유민주주의를 의미하신 거라면, 글쎄요... 이 상황에서 나올만한 "주의"는 아닌 듯 하네요. 그것은 이상 세계의 "주의"아니던가요? 자유민주주의는 지난 수세기동안 모든 인류가 갈망하던 이상적인 세계의 모델이었습니다. 이를 실현하기 위한 현실적인 방법 중의 하나가 "자본주의"였죠(전 그렇게 알고 있습니다.) 우리나라도 자유민주주의를 추구하고 있다고 합디다마는, 실상은 수정 자본주의일 뿐이죠. -.-;; 이상 세계의 "자유"를 빗대어 현실을 부정하시는 거라면 저로썬 더 드릴 말씀이 없습니다.
말그대로 오프토픽입니다. 가능하면 (답이 없는)이 얘기는 그만했으면 좋겠네요. 하더라도 별도의 토픽을 여는게 좋을 듯...

----
the smile has left your eyes...

transf의 이미지

뭐 저도 오래된 습관이라 {을 New line에 쓰는 편이기는 하나
프로그래밍으로 밥빌어먹고 산지도 한 10년 넘고 보니
크게 중요한 문제로 삼지는 않고 있습니다..^^ 좀 포기했다고 보는거지요..ㅋㅋ

근데 대형 프로젝트가 어떤 것인가요??
소스랑 관련 이미지를 zip으로 압축했는데 한 200-300M정도 되면 대형 프로젝트 인가요??
흠...뭐 이런 경우에는 코딩스타일로 문제가 발생할 확률은 제 경우에는 별로 없더군요...
코딩스타일은 뭐랄까 좀 부차원적이더군요...많은 상용개발자가 소프트웨어 설계에 따른
이해도 부족으로 문제가 만들어 지고 그런 친구들일수록 코딩스타일이 아주 개성(?)있어서
나름 뭐 코딩스타일이 문제인것 처럼 보인적은 여럿 있지만 여튼 꼭 그런것 만은 아니더군요..
참고로 저희팀은 한번 프로젝트가 시작하면 한 20명에서 30명 정도 운용됩니다.
그리고 위에 분중에 이야기 하셨는데 어떤 PL이 코드 전체를 다 보고 있는지 궁금합니다..^^
저도 노력은 해봤지만 양이 너무 많아서 다 보질 못하겠더군요..
그래서 주로 회의를 통해 구조에 대한 논의를 많이 가졌습니다.
제 주변의 경력높으신 PL중에 팀원 코드를 모두 보시는 분은 본적이 없는 것 같네요..
예전에 CVS나 SVN없이 소스 Merge하던 시기에는 가능한 이야기겠지요...
그러나 물론 이런 경우에도 프로젝트별 코딩스타일은 프로젝트 설계당시에 만들어 지지만
이또한 참조의 성격이 많이 강합니다..^^
개인적으로 저는 이런 프로젝트의 경우 들여쓰기 문제 보다는
함수명, 변수명에 대한 Naming rule에 좀더 집중하는 것이 효율적이었던 것으로 기억합니다.

아니면 소스 용량은 작으나 그 구성이 치밀해야 하고
기간은 한 1년은 넘어가는 경우가 대형프로젝트인가요??
이런 경우에는 더더욱 코딩 스타일이 문제 되지 않더군요..
보통 이런 경우 팀원이 6-10명 정도 구성되는데 이런 경우는 어느 정도 팀원들의 성향을 알기때문에
니중에 정리된 소스를 받아보면 살펴보는데 별로 어렵지 않더군요..
오히려 코딩스타일 보다는 우리가 잘 알고 있는 주석이 더 많은 영향을 미치더군요...
개인적으로 이런 경우에는 변수명을 엉망으로 쓰더라도 들여쓰기가 엉망이더라도
주석을 명확하게 달것을 요구를 많이 하는 편입니다.

뭐 어디까지나 제 개인의 경험이다 보니 다른 분들은 또 어떤지 궁금하네요...
생산성 있는 코딩은 어떤것인지 궁금하기도 해지네요..이런건 다른 글타래로 가야 하나??
여튼 그러네요..^^

xyhan의 이미지


저도 프로그래밍 배울때 그렇게 배워서 그런지 몰라도..
한길님 스타일이 편합니다..

그런데 잘은 몰라도 자바 코딩 표준 가이드가 많은 곳에서 ...
void test() {
}
이런 형태로 사용 되어 지고 있습니다..

로직이 복잡해지면.. 보기 힘들던데요..

============================================================

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

============================================================

============================================================

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

============================================================

cleansugar의 이미지

제가 예전에 구상했던 건데 생각난 김에 그려봤습니다.

컬리브레이스 때문에 싸움나니까 아예 없애서 보기 좋게 하는 방법입니다.

변수 이름 옆에도 GUI 아이콘처럼 눈에 확 띄게 해당 아이콘이 붙어 있습니다.

순서도나 UML같은 시각적인 언어가 많이 나와 있지만 많이들 쓰는 언어는 아닙니다.

주로 쓰는 C 형태의 문법을 그대로 쓰고

IDE만 보기 편하게 바뀌었으면 좋겠습니다.

지금 IDE의 컨트롤은 텍스트 기반에 펼침이나 꺽쇠만 보여주는데 저는 이런 식으로 된걸 쓰고싶습니다.

이십분만에 급히 그려서 제 구상보다는 단순합니다.

이런 식의 IDE가 있을 법해서 예전에 뒤져봤다가 못 찾았습니다.

혹시 컬리브레이스 안쓰고 문법은 C같이 널리 쓰이면서 가독성 높은 IDE 없을까요?

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

죠커의 이미지

왠지 스퀵을 보는 듯한 느낌입니다.
- CN의 낙서장 / HanIRC:#CN

cleansugar의 이미지

저는 프로그래밍 초보라서 잘 모르지만 스퀵이란 객체지향언어는 익숙해지면 프로그래밍하기 쉽겠군요.

지금은 여유가 없어서 못하지만 나중에라도 한번 배워보고 싶군요.

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

cleansugar의 이미지

그리고 int의 위쪽이나 옆쪽에도 할당 크기에 따라서 네모칸 아이콘을 1~4개 정도 붙이고

정수형이냐 플로트냐에 따라서 색깔을 다르게 붙여야 되는데 그리기 귀찮아서 못그렸습니다.

그리고 if문의 테두리 모양은 마름모를 연상하는 모양으로 되면 좋겠고

배경색은 꼭 회색이 아니어도 함수의 종류에 따라서 붉은 계통, 푸른 계통, 노란 계통 등을 쓰거나

무늬가 그려진 배경을 쓸 수도 있습니다.

주석도 풍선 박스같은데 표시되고

큰따옴표도 겹줄 테두리 박스 등으로 표현할 수 있습니다.

함수의 패러미터나 리턴값도 다르게 표현할 수도 있는데 나중으로 미루겠습니다.

함수의 첫 줄은 창의 제목부분처럼 클릭하면 폴더 아이콘으로 줄어들거나 맥OS처럼 내용이 말려올라가도 됩니다.

public 함수면 폴더를 투명하게 할 수도 있겠네요.

물론 배경, 테두리, 아이콘은 내용 인식해서 자동으로 생기게 할 수 있습니다.

그리고 IDE만 바뀌기 때문에 다른 언어에도 이런식으로 적용할 수 있습니다.

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

cleansugar의 이미지

올렸던 파일이 서버에서 지워져서 다시 올립니다.

댓글 첨부 파일: 
첨부파일 크기
Image icon visualcpp.jpg34 KB

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

cleansugar의 이미지

몇 년 만에 접속했더니 첨부한 이미지가 다 삭제되었네요. 누가 책임지실 겁니까?

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

cleansugar의 이미지

어 나오네. 죄송합니다.

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

nainu의 이미지

개발자들끼리 코딩 규약을 정하지 않으면 VCS를 사용할 경우에 문제가 발생할 수 있습니다. 고치지 않은 부분임에도 인덴트 조금 수정되었다고 전혀 다른 줄로 표시될 것이니 말이죠.. 최악의 경우 파일 통째로 바뀌었다고 비교가 될 수도 있죠..

서로 작업하는 파일이 겹치지 않는다면 상관이 없겠지만 그래도 툴이 강제할 수 있는 확실한 규약이 존재해야 한다고 생각합니다.

nainu in wonderland.

bluewolf의 이미지

코드 라이프 사이클 내내 자신이 관리할 코드가 아닌데도 불구하고,
자기 취향대로 짜면 결국 나중에 좋은 소리는 못 듣습니다.

조직 내에 확실한 컨벤션이 필요하고 그것을 따를 필요가 있다고 보는 입장입니다.
특히 java는 Sun에서 미는 convetion이 있으니까 그걸 따르면 편합니다.
따로 문서화할 필요도 없구요. :-)

소프트웨어 엔지니어
- MHP 미들웨어 개발
- WAS 개발
- Backend 서버 소프트웨어 개발

익명사용자의 이미지

이곳에 온지 얼마안되지만.. 이곳은 코딩규칙부터 매우 엄격하군요..
규모도 상당히 큽니다. 유지 비용만도 월 몇십억은 들겠네요..
그런데 조만간 전체를 폐기할 계획을 세우는군요...

팀장급들은 새프로젝트로 전향하려하고 잔여인원들은 그냥 이대로 있나봅니다.
아마도 전향하는데는 엄청난 시간과 비용이 들것으로 보입니다.

아마도 이시스템이 개발당시에는 좋다고 만들었는지몰라도.. 지금생각해보면 너무도 엉터리며 어이없습니다.
하드코딩들도 많고. 그것을 프로그램 100개가 하는일을 새로운 방식을써서 단한개의 프로그램으로 해결하는걸
만들어줘도 퇴자맞습니다..
이유는 기존에 그렇게 하지 않았다 입니다. 이시스템을 본사람들은 누구나 말합니다. 너무도 어이없다고..최악이죠..
하지만.. 아무도 감히 이것이 잘못되었으며 개선해야한다고 주장하지 못합니다.
팀장급들이 그걸좋아하지 않나봅니다.
즉, 오래된사람은 과거에서부터 여테까지 해온방식에서 변하고 싶지 않은거죠..
특히나 집접코딩하지도 않는 팀장으로썬말이죠..
그러나 저도 아쉬울건 없습니다.. 잘되도 크게 득될것도 없고 못되도 손해나지도 않기때문이죠.

xog2000의 이미지

간단히 글 적습니다. 저랑 같은 생각 하시는 분들 많이 계시리라 믿습니다.

자신이 일하는 곳에 규칙이 있으면 따르면 되고

없으면 자신의 스타일을 따르면 되는겁니다.

일하는 곳에 사내 표준이라는 것이 없는상태에서 다음 개발자를 위해

코딩한다는 것이 과연 다음 개발자가 편할까요?

자신만의 생각이 아닐까요?

그냥 간단히 생각하면 됩니다. 싸울필요도 없습니다.

사내 표준이 있으면 따라줌으로 남에게 피해 안주고

표준이 없다면 자신의 스타일대로 하면 되는 것입니다.

나의 스타일을 부사수나 신입으로 팀원이 된 사원이 더 읽기

편할지도 모르는 일입니다.

신입 사원들이 다 이등병 같지는 않죠.

참고로 저는...

//test.c
#include <stdio.h>
 
int main () {
 
    int i = 1;
    int j = 2;
 
    if (i>j) {
        printf("haHa");
        return 1;
    }
 
    printf("HuHu");
    return 0;
}

를 기본 베이스로 하고

윈도우 관련 (현재 하는 일)일 경우는

회사 표준에 맞춰서

이 글을 쓰신 분 처럼 코딩합니다.

그 외는 제 방법 고수하구요.

----------------------------------------
// 두뇌설정
memset((void *)&두뇌, 0x00, sizeof(두뇌));

든게 없구나..

----------------------------------------
내가사는세상-Kernelist : http://blog.naver.com/xog2000
"모르는 것은 어리석은 것이 아니다.
어리석은 것은 알려는 의지가 없음을 말한다."

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.