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

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

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

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

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

강제가 아닌 관습입니다.

ref
http://java.sun.com/docs/codeconv/
http://zeropage.org/wiki/CodeConvention

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

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

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

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

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

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

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

void 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 키를 사용하면 알아서 맞춰주더군요.

그렇게 해서 씁니다. ^^

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

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

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

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

더 좋겠죠...

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

이렇게는 안쓰시나요?

int
main(void)
{
}

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

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

int main(void)
{
    return 0;
}

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 "{"

void test() {
}

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

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

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

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

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

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

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

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

void test() {
}

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

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

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

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

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년 넘게 코딩했었지만 지금 썬의 스타일이 훨씬 편합니다. 거부하려하지 말고 한 번 적응해보세요. 많은 사람들이 쓰는 게 다 이유가 있습니다.

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

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

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

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

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

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

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

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

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

--feanor

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

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

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

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

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

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

전 사실 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같은 툴로도
그런 오류때문에 파싱을 못하는 경우까지 있고 말이죠.
심미적인 취향이야 어쩔수 없대도 그런 논리적인, 그리고 순전히
코드레벨에서의 오류는 조심해야 할텐데...(아 찔린다...ㅋㅋ)

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

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

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

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

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

이클립스의 경우 코드 포맷팅 옵션이 매우 자세히 되어 있고 설정 내용을 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 와 같은 버전 관리 시스템에서 문제를 일으킬 소지가 많아서 별로 권장하지 않습니다.

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

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

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

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

    return 0;
}

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

제 코딩스타일은 ... 자바나 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 를 사용하구요

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

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

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

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

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

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

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

우엉...

이건 좀 심한 경우고요..

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

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

전
main(){

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

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

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

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

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

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

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

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

감사합니다.

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

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

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

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

    }
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

그런 의미에서 {를 내려 쓰는 문제를 본다면 요즘 추세는 점점 {를 내려 쓰는 방향이 많아지고 있습니다. 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 정렬해주는 이런툴 혹시 어디 없나요?

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

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

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

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

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

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

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

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

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

맞습니다. 제가 말하려던 바의 반은 이해하신거 같습니다.
코딩스타일은 개인자유에 맡겨야 합니다. 단 '도구'가 그것을 지원한다면 말이죠. 위에서 분명히 도구가 해결해야할문제라고 언급하였습니다.
여기서 '도구'란 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 지원되는 도구입니다. 아무튼 감사합니다.

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

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

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