여러분의 코딩 스타일은?
글쓴이: geekforum / 작성시간: 목, 2001/12/27 - 10:34오전
프로그래머로서 코드를 만들어 나가다 보면 자기 자신만의 코딩 스타일이 생기게 마련이죠. 똑같은 루틴을 구현한다고 할지라도 실제로 표현된 코드는 사람마다 제각각 다를 것입니다. 문법적으로 완전히 동일한 코드라도 탭사이즈나 스페이스 등을 어떻게 사용하느냐는 만드는 사람 마음이죠.
리눅스 커널의 코딩 스타일은 다음과 같습니다. 전체 내용은 아래 관련 링크를 참조하시고요....
if (x is true) {
[TAB]we do y
}
int function(int x)
{
[TAB]body of function
}
do {
[TAB]body of do-loop
} while (condition);
if (x == y) {
[TAB]..
} else if (x > y) {
[TAB]...
} else {
[TAB]....
}
여러분들은 어떤 스타일로 코딩을 하시는지, 왜 그렇게 하는 것을 좋아하는지요?
댓글
정답입니다.프로그래밍 완전정복이라는 책에도 그렇게 나와있습니다.
정답입니다.
프로그래밍 완전정복이라는 책에도 그렇게 나와있습니다.
과자가 아닙니다.
cuckoo dozen, 즉.12마리의 뻐꾸기란 뜻입니다.
tloen님 글에 답장 붙일려고 한 것입니다.일관성을 유지하는 게
tloen님 글에 답장 붙일려고 한 것입니다.
일관성을 유지하는 게 중요하다라는 글요.
과자가 아닙니다.
cuckoo dozen, 즉.12마리의 뻐꾸기란 뜻입니다.
탭을 빈칸으루 하느냐 탭키로 넣느냐-_-;;이건 정말 고민 되던데
탭을 빈칸으루 하느냐 탭키로 넣느냐
-_-;;
이건 정말 고민 되던데..
vi로 따지면,
set et 를 넣느냐 마느냐
스페이스로 넣으면 그만큼 소스용량이 커집니다. --;일반적인 경우
스페이스로 넣으면 그만큼 소스용량이 커집니다. --;
일반적인 경우는 단점 이지만 장점일때도 있습니다.
일로써 할때 프로그램 소스 용량을 키울수가 이거든요.
전 보통 탭사이즈를 4정도로 맞추고 합니다.
어떤 언어든.
저의 코딩스타일은1. 발이 머리보다 높은 곳에 위치해야 할것...
저의 코딩스타일은
1. 발이 머리보다 높은 곳에 위치해야 할것...
2. 해드폰으로 음악을 들을 것...
3. 음악은 반드시 클래식일 것.
4. 키보드는 배위에 위치할 것...
5. 마우스는 가능한 안쓰고, 단축키로 해결할 것.
6. 아주 연한 냉커피를 1리터쯤 준비할 것.
7. 대용량 재떨이 담배 2갑이상 준비..
8. 의자가 매우 편해야 할 것.
왜 그렇게 하냐면.. --;;;그래야 장시간 일해도 들 지치니까.
왜 그렇게 하냐면.. --;;;
그래야 장시간 일해도 들 지치니까.. --;;;
존 보통..if ( x ) {[tab]}else
존 보통..
if ( x )
{
[tab]
}
else
{
[tab]
}
이런.. 스타일을 씁니다. 가장 보편적이지 않나요?-_-
무의미한 토론에 수많은 답장이 올라왔네요.개인적으로 코딩스타일에서
무의미한 토론에 수많은 답장이 올라왔네요.
개인적으로 코딩스타일에서 지켜야할 규칙은 하나라고 생각합니다.
일관성. Consistency
vim 외에도 많이 쓰는구나...
vim 외에도 많이 쓰는구나...
indentation 관련된 토론 역시 holy war죠. :)h
indentation 관련된 토론 역시 holy war죠. :)
http://www.tuxedo.org/~esr/jargon/html/entry/indent-style.html
전 대학초년 때는 K&R style. 그 후로 BSD style로 전향했습니다.
BSD style이란... 어떤 스타일이죠?전... K&R 스타일을
BSD style이란... 어떤 스타일이죠?
전... K&R 스타일을 쓰고 있습니다만...
Allman 스타일 쓰는 사람이 훨 만은거 같더군요...
1.공부하던 책2.사용하던 툴3.협업하면서 쓰던 규칙세종류
1.공부하던 책
2.사용하던 툴
3.협업하면서 쓰던 규칙
세종류의 영향을 받는 것 같군요.
예전에 큰 회사의 코딩에 관한 내부 문건을봤는데 지침서가 수십쪽 되더
예전에 큰 회사의 코딩에 관한 내부 문건을
봤는데 지침서가 수십쪽 되더군요. 주석은
어떻게 달고 들여쓰기는 어떻게 하고 몇번
이상 어기면 시말서를 쓴다거나 하는 조항도
있고.. 그런게 대외비라니.. -_-;
아마 회사 간부들의 노파심에서 그런 규정을 만들었을겁니다.혹시나 소스
아마 회사 간부들의 노파심에서 그런 규정을 만들었을겁니다.
혹시나 소스가 유출될경우 소스 해독법이나 다름없기 때문입니다.
심지어 그 회사에서 일하던 프로그래머가 다른 회사로 이직하는 것을 금지(?)하는 서약까지 한다고 합니다.
if(...){ ...}for() { ....
if(...){
...
}
for() {
....
}
do{
....
}while();
while(){
...
}
switch(){
case 1:
...
}
이러케 코딩합니다..
예전부턴 하던 습관이라서 쉽게 안고쳐집니다.
MFC 는 { 를 자동으로 밑으로 내리지요..허나
그거 무시하고 내식대로 짭니다.
헝가리안 표기법은 MFC 쓸때 마니 쓰다보니까
리눅스에서도 사용합니다..편하더군여
그리고 변수명은 될수있으면 의미를 알수있게
글자가 길더라도 알수있또록 만듭니다..
허나..회사에서 할때는 남들하고 얘기를 하고나서
규약을 정해서 합니다..허지만 지버릇 개못주죠..
똑똑한 해커들은 줄바꿈을 하지않고서도 하더군여..
전에 DVD코드를 깬애들이 짠소스가 7줄이던가?..
그냥 쫙 붙어있떤데..
짠다음에 쫙 붙이는거죠, uglizer라도 있나봅니다. -_-
짠다음에 쫙 붙이는거죠, uglizer라도 있나봅니다. -_-
옛날에 마소지에 원라인 프로그램 컨테스트가 생각나는 군..
옛날에 마소지에 원라인 프로그램 컨테스트가 생각나는 군..
그거 베이직에서 행번호 1만 가지고 하던거였죠?한 행이 256자까지
그거 베이직에서 행번호 1만 가지고 하던거였죠?
한 행이 256자까지 가능했던가 그랬는데.
거기에 나온 프로그램들 입력해서 run 쳐보고 신기해 하던 기억이 납니다.
저는 몇달 전까지만 해도if(expression){[tab]
저는 몇달 전까지만 해도
if(expression)
{
[tab]statement
.
.
[tab]statement
}
else if(expression)
{
...
}
이런식으로 짰는데요..
요즘은..
if(expression) {
[tab]statement
.
.
[tab]statement
} else if(expression) {
.
.
}
이런식으로 짭니다..
{를 같은 줄에 써주는게..코드 줄수를 줄여줘서..
한 화면에 보여지는 코드양이 더 많아지더군요..
그래서 한결 코드 읽기나 짜기가 편하더군요..
아! 그렇군요..저도 님과 같은 스타일로 짭니다만, 그게 소스길이
아! 그렇군요..
저도 님과 같은 스타일로 짭니다만, 그게 소스길이를 줄여준다는 생각은 한번도 못해봤군요.. 내가 왜 이러지?
이런 버릇들은 없으신가요?저는{} 를 쓸 때 미리 쳐놓고 그 안을
이런 버릇들은 없으신가요?
저는
{} 를 쓸 때 미리 쳐놓고 그 안을 채워 넣습니다.
다들 기본으로 하시겠져?
if ()
{
}
를 쳐 놓고 나서
if ()
{
.....궁시렁궁시렁;
}
) 를 칠때는 항상 %를 사용해보구염 (vi)
가독성을 높이기 위한 vi의세팅들은 많은게 있더군염..
hlsearch, incsearch 는 /,? 로 검색할때 편리하구요,
(검색 글자 반전, 글자치는대로 바로 움직이기)
background=dark는 글씨를 찐하게 해서 보기 편하게 하더군요
또 저는 smartindent나 cindent보다
그냥 autoindent를 쓰는데염...
vi세팅은 코딩 습관과 직결된다고 보기에.. ^^
vi세팅에 관한것도 써 봤네염..
음...두 부류군요~ 갈매기가 옆에 붙는 경우와 아래줄에 붙는 경우~
음...
두 부류군요~ 갈매기가 옆에 붙는 경우와 아래줄에 붙는 경우~
전 오랫동안 옆에 붙이다가
최근에 팀원간에 코딩 규칙을 통일시키면서 밑에 붙이고 있습니다만...
여기서 문제가 되는 것 몇가지가 있는데...
원래부터 밑에 붙이시는 분들은 어떻게 해결하시는지...
1. do { } while문의 경우
규칙대로 하면
do
{
...
}
while (...)
이 됩니다.
while-do인지 do-while인지...
2. switch/case
switch (...)
{
case xxx: /* case를 들여쓸것인가 말것인가...*/
/* 여기서 갈매기를 열어야 한다면?
(물론 대부분 함수로 뺄 수 있습니다만... 그렇지 않을 경우도~)
*/
}
3. try / catch문의 경우...
try
{
}
catch (...)
{
}
catch (...)
{
}
음... 가독성이 상당히 떨어집니다.
라인수도 급격히 늘어나고...
이 외에도 몇가지 경우가 있었는데...
지금 당장 생각나는 건 이 정도군요.
어떻게 하는 것이 좋을까요?
do { ... } while (...)이렇게 씁니다. 말
do
{
...
} while (...)
이렇게 씁니다. 말씀하신 형태는 처음 보는군요.
switch (...)
{
case xxx: /* 들여쓰지 않습니다 */
{
int i = 0;
break;
} /* 갈매기 열 필요 없죠;; */
}
그렇게되면 switch의 닫는 갈매기와case xxx의 닫는 갈매기가
그렇게되면 switch의 닫는 갈매기와
case xxx의 닫는 갈매기가 같은 들여쓰기 레벨에 놓이게 되지 않나요?
do
{
} while의 경우도...
원칙의 예외 조항이 되는것 같은데...
{ 와 } 는 한 라인을 사용한다는...
사실 case 문제 갈매기 붙일 필요가 없죠..;;
사실 case 문제 갈매기 붙일 필요가 없죠..;;
헝거리안 표기법은 C/C++에서는 상당히 유리한 점이 많습니다. 기본 데
헝거리안 표기법은 C/C++에서는 상당히 유리한 점이 많습니다. 기본 데이터타입(자바에선 primitive type이라고 하죠)이 종류가 많고 포인터가 있기 때문에 이런 걸 표시해주면 코딩할 때 아주 편리하죠. 특히 포인터 앞에 p 붙이는 거, 스트링 앞에 str(s만 쓰는 사람도 많죠)을 붙이는 거, 숫자형 앞에 n붙이는 건 정말 편리하죠. 특히 윈도우 프로그래밍에서는 매크로로 재정의된 정수 타입이 엄청나게 많은데 n을 붙여주면 쉽게 감을 잡을 수 있죠.
근데 자바에서는 별로 좋지 않은 방법입니다. 포인터도 없고 primitive type이 제한되어 있는데다가 대부분의 변수가 클래스에 기반하고 있기 때문에 앞에 prefix를 붙이는 게 의미가 별로 없습니다. 오히려 의미 구조 전달에 장애만 되죠. 그냥 의미만을 살린 변수명이 좋습니다.
블럭 시작 괄호를 어디 붙이느냐도 상당히 논쟁 거리인데 SUN의 Java Code Convention이란 문서를 보니
if (expr) {
[tab]expr;
} else {
[tabl]expr;
}
이런 방식을 권장하더군요. 전 {를 줄 바꿔서 쓰는 걸 선호합니다. 블럭이 길어질 경우 앞뒤 짝을 찾기가 쉽기 때문이죠. vi에서는 %누르면 잘 찾아주긴 하던데.. 근데 { 쓰고 줄 바꾸는 것도 장점이 많더군요. try-catch-finaly 쓸 때도 좋고 if-else 쓸 때도 좋고.. 어차피 indenting만 제대로 하면 블럭 매치가 그렇게 어려운 것도 아니고.. 그래서 sun에서 권장하는대로 바꿀까 생각 중입니다.
또 하나의 논쟁 거리.. tab을 space로 할 것이냐, tab character를 쓸 것이냐가 문제죠? 전 tab character가 훨씬 좋습니다. 코딩할 때 훨씬 편하니까요. 근데 요즘 추세는 space인 것 같더군요. 각 출판사에서 나오는 코드들은 거의다 space로 되어 있던데.. 그래도 이건 tab character가 더 좋은 듯. 어차피 전 모든 에디터의 탭 간격을 4로 맞춰놓거든요-_- 근데 tab을 space로 쓰면 smart tab이 되서 좋은 점도 있는 것 같더군요. 머, 어쨋든 전 indent를 tab으로, tab은 tab character를 쓰는 거에 한 표~
그 외에 연산자 사이를 어떻게 할 것이냐가 문젠데..
left = right + right;
이런 건 분명히 띄어쓰는 게 보기 좋은 거 같은데..
for (int i; i<0; i++)
for (int i; i < 0; i++)
이건 어느 게 나은지 모르겠군요. 전자가 보기 좋은데 원칙에 따르자면 후자가 맞고..그렇다고
left=right+right; 이것도 이렇게 바꾸자니 별로고...
keyword 뒤의 ()는 띄어 쓰고 함수 뒤의 ()는 붙여 쓰는데 ()안에도 띄울 것이냐 말 것이냐는 좀 고민이네요.
if (expr == expr)
if ( expr == expr )
function(a, b, c);
function( a, b, c );
전 () 안에는 안 띄우는..그러니까 전자가 나은 것 같군요.
주석은 자바에선 가능한 한 javadoc 방식을 따르는 것이 낫고 SUN 문서에서는 주석이 없으면 이해하지 못할 정도가 아니면 되도록 내용 주석은 달지 말라고 되어 있더군요. 그러니까 클래스에 주석을 단다면 클래스의 용도, 메쏘드의 기능, 멤버 변수 설명 정도만 달고(javadoc에서 필요한 것들이죠.) 내부적인 알고리즘에 대해서는 부연하지 마라는 거죠. 저도 거기에 동의합니다. 주석이 없어도 이해할 수 있는 프로그램이 좋은 프로그램이죠. 머, 주석에 대해선 이견이 분분할 테니 이 정도로..--+
80라인 줄바꿈은 전 필요하다고 생각합니다. 한두 파일만 편집하는 경우라면 큰 상관 없지만 동시에 5~6개의 파일을 오가며 작업해야할 경우 긴 줄이 있는 파일이 있으면 정말 짜증나죠. 에디터에서 줄바꿔 보여주는 것보다 코딩할 때 미리 줄을 바꿔두는 게 좋다고 생각합니다. 사실 자바에선 클래스명이 길어서 단순히 한 문장만 써도 길어질 경우가 많은데 적절히 잘라주는 게 좋을 것 같습니다.
무엇보다 중요한 건 code convention에 대해서 자신이 그 이유를 생각해보고 써야한다는 것입니다. 그렇게 쓰는 이유에 자신이 동의를 하고 쓰는 게 의미가 있죠. 헝거리안 표기법 같은 건 사람들이 그냥 그거 좋다더라..해서 자바에서는 오히려 안 좋은데도 헝거리안 표기법을 쓰는 이유도 생각해보지 않고 그냥 도입해서 쓰는 곳이 많은데 그래서는 그 표기법의 장점을 살릴 수 없죠. 어떤 code convention을 채용하든 그 이유에 대해 스스로 동의할 수 있는 것을 써야합니다.
if(조건){....(어쩌고)}else{....(저
if(조건)
{
....(어쩌고)
}
else
{
....(저쩌고)
}
이렇게 하면
if(내용) {
....(어쩌고)
} else {
....(저쩌고)
}
보다 3줄이 늘어나죠. 블럭을 다른 줄에 쓰면 라인 수로 작업량을 체크할 때 매우 유용합니다. _^_
나두 본문대로 하는데...옛날에 터보이빨 임인건씨 베게책으로 공부
나두 본문대로 하는데...
옛날에 터보이빨 임인건씨 베게책으로 공부한 사람은 다 저럴껄여?
갑자기 궁금한게 하나 더 생각났네요... if나 for같은 건 대충 몇
갑자기 궁금한게 하나 더 생각났네요... if나 for같은 건 대충 몇 가지 많이쓰는 표준이 있는 것 같은데, 그렇다면 자바의 inner class는 어떻게 처리 하나요? 저는,
addWindowAdapter(
new WindowAdapter() {
public void windowClosing(WindowEvent event) {
System.exit(0);
}
}
);
과 같이 쓰는데 코드 정리도구 등을 쓰면 조금씩 어긋나 버리더군요.
또한 배열의 내용을 선언과 함께 직접 쓰는 경우는 어떤가요? 예를 들어
dummy.setSomeAttribute(
new String[] {
"blah blah...",
"another one..."
}
);
이렇게 하는게 표준적인지 모르겠습니다.
다른 분들은 어떻게 처리하시는지 궁금하군요.
흘... 스페이스가 다 짤렸네요. 위의 모든 브레킷은 레벨별로 4칸의 스
흘... 스페이스가 다 짤렸네요. 위의 모든 브레킷은 레벨별로 4칸의 스페이스가 있습니다. 그럼...
제 경우엔 한 문장을 여러줄로 나눠쓸때는더블 탭을 씁니다.mybt
제 경우엔 한 문장을 여러줄로 나눠쓸때는
더블 탭을 씁니다.
mybtn.addActionListener(
[tab][tab]new ActionAdapter()
[tab][tab]{
[tab][tab][tab]public void actionPerformed()
[tab][tab][tab]{
[tab][tab][tab][tab]...
[tab][tab][tab]}
[tab][tab]}
[tab]);대신 그 문장이 끝나는 줄을 싱글 탭하죠.
여러줄 문장은 항상 괄호나 브레이스같은 앞뒤짝이 있기때문에 이런식으로 해결합니다만...
라인수가 급격히 늘어나는 문제가 있더군요~
그래서 가급적 inline class는 쓰지 않는 편입니다.
전 보기 좋게 코딩하거든요void main(){ for(int
전 보기 좋게 코딩하거든요
void main()
{
for(int a=0 ; a<=100 ; a++)
{
printf("天才STAR이다");
}
}
그리고 딴 사람들이 코딩한 소스보면 잘 못보겠더라고요
대부분
for(int a=0;a<=100;a++){
printf("케케케");
}
이런 식으로 코딩하시더라고요...쩝~^^;;;
개개인의 코딩스타일도 중요하지만 요러명이 같이 개발할 때는 코딩 규약을
개개인의 코딩스타일도 중요하지만 요러명이 같이 개발할 때는 코딩 규약을 미리 정하는게 더욱 중요한 경우가 많습니다. 저는 주로 자바를 이용하기 때문에 코딩 컨벤션은 표준을 따라가지만 문제가 되는 부분은 탭을 쓸 것인지 스페이스를 쓸 것인지, 그리고 무엇보다 라인의 끝을 어떻게 할 것인지(CR/LF 문제)가 더욱 중요하더군요.
저는 탭보다는 스페이스를 선호합니다. 그래서 IDE에서 탭이 자동으로 스페이스 4칸으로 바뀌게 합니다. 왜냐하면 일반 편집기로 볼 경우 탭이 8칸으로 되어 있는 경우가 많아 한눈에 안들어오기 때문입니다. 스페이스는 소스 크기가 약간 커지지만 어느 편집기에서도 비슷하게 보이지요...
CR/LF문제는 특히 한 팀안에서 윈도우즈/리눅스를 동시에 개발환경으로 사용하는 경우 큰 문제가 됩니다. 윈도우즈에서 작업한 파일을 열어보니 모든 줄에 다 ^M이 붙어 있다던지 반대의 경우 모든 코드가 한줄로 붙어버렸다던지 하는 경우 난감하지요... 그래서 가끔은 Ant의 CR/LF 수정기능이나 코드 컨벤션을 맞추어주는 툴을 쓰지만 이 경우 cvs와 같이 쓰면 문제가 됩니다.
결론적으로 이런 문제는 프로젝트 이전에 미리 결정해서 문제가 없는지 테스트 해봐야 된다는 것입니다.
한 가지 더 생각나는게 자바에서 헝가리안과 같은 (자바 기준에서 보면) 비 표준적은 명명법을 쓰는 경우 입니다. 특히 C/C++경험이 있는 사람들이 m_strAccountName 같은 이름을 고집하는 경우가 있는데 이는 해당 변수의 getter/setter를 달 때 문제가 됩니다. getM_strAccountName()이라는 식으로는 쓰지 않지요... 그냥 getter는 getAccountName()으로 하면 된다고 하지만 이 경우 UML툴 등으로 리버스 엔지니어링을 하면 인식을 못하기 때문에 문제가 됩니다.
개인적으로 자바 언어에서 m_str같은 걸 안붙이면 헷갈릴 정도로 많은 멤버변수를 쓰는건 절차적인 프로그래밍에서 벗어나지 못했거나 잘못된 설계에서 비롯된 것이라고 봅니다.
출근하자마자 그냥 생각나는 걸 적다보니 두서가 없군요... 어쨌든 흥미로운 토론인 것 같습니다.
그럼...
그런 것도 처리할 수 있는 툴도 있습니다. prefix를 지정하면알아
그런 것도 처리할 수 있는 툴도 있습니다. prefix를 지정하면
알아서 해 주더 군요.
chat *func ( int c, int b ) {.......
chat *
func ( int c, int b ) {
.......c=b;
.......if ( c == b ) {
..............printf ( "c와 b는 같은 것만 같습니다. 무슨 프로그램이 이러냐구요? 내 맘입니다. 양자역학이 판치는 세상이라도 저는 한줄이 아무리 길어도 절대로 줄바꿈을 하지 않습니다.\n" );
.......}
.......if ( c < 0 ) {
..............printf ( "물론 높은 해상도의 모니터가 필수겠지요. -_-;\n" );
.......}
.......else {
..............pritnf ( "이것은 C, JAVA 같은 넘들을 할 때의 이야기구요\n" );
.......}
.......exit ( 0 );
}
html 코딩할 때는...
.
.....
......
......
......
.....
..
이렇게 합니다 -_-;
(-_-!!! 오타다!!)컴파일도 하기 전에 에러를 내뿜는 이런
(-_-!!! 오타다!!)
컴파일도 하기 전에 에러를 내뿜는 이런 프로그램은 짜지 마세용 T_T
if (...){ 내용 }else if (...){ 내용}
if (...){
내용
}else if (...){
내용
}
전 main을 제외하고는 다 이런 식으로 괄호를 붙이는데...
그리고 탭은 vi가 띄워 주는 데로 받아 먹습니다.
for(....) {}if(...) {}else
for(....) {
}
if(...) {
}
else if(..) {
}
else {
}
그리고 -_-
int main(argc, argv)
int argc;
char *argv[];
{
}
이걸씁니다 -_-
탭은 많이 쓰는편이지만 탭길이에 구애는 받지 않습니다.
그리고 한 행이 긴거는 제일 싫어하죠;
printf("......", num1, num2, num3, num4
num5, num6 );
-_-;;;;
공백이 무시당했군요printf("......", num1, num
공백이 무시당했군요
printf("......", num1, num2, num3, num4
.................num5, num6 );
이런.. num4뒤에 컴마 빼먹으셨네요 ^^;;
이런.. num4뒤에 컴마 빼먹으셨네요 ^^;;
예전에 연습할땐 제어문이나 함수 들어갈 때탭으로 하위 레벨 분류 일일
예전에 연습할땐 제어문이나 함수 들어갈 때
탭으로 하위 레벨 분류 일일이 해주면서 한눈에
봐도 알아보기 쉽게 완전히 C책에 나오는 예제
스타일식으로 했었는데 이것도 먹고 사는거랑 연결이
되니 웬만하믄 안띄우고 쭉 달아서 짜게 되더군요.
for (;주절주절;) {
주절주절...
}
요즘엔
for(;주절;){ 주절주절}
좀 길면 if(주절){주저리주저리...
주저리주저리...} //if end
ㅎㅎ
배울땐 네가 짜놓고도 이해가 안가는(?) 일이 잦아서
최대한 알아보기 쉽게 짜다가 이력이 나니 볼놈도
나말고 별로 없고 또 별로 소스 보여주고 싶지도
않아서 그냥 대충 짜는 스타일이죠...
그래도 한가지 지키는건 패턴은 일정하게 유지 해야
나중에 자기가 쳐다봐도 이해가 빨리 온다는 ㅡㅡ;
펑~
library header------------------------
library header
-----------------------------------------------
#define _대문자_(전역으로 쓰이는 정의) [정의]
-----------------------------------------------
local header
-----------------------------------------------
#define 대문자 [정의]
extern int _전역변수_;
int 로컬변수;
-----------------------------------------------
source
-----------------------------------------------
char *
function(a,b)
....char *a;
....char *b;
{
....char *output;
....output=(char *)malloc(strlen(a)+1);
....strcpy(output,a);
....return output;
}
main(void)
{
....char tmp[1024];
....char buf[4096];
....int count,result;
....do
....{
........process;
........switch(a)
........{
............char *ptr;
............case a:
................break;
............case b:
................break;
............default:
................ptr=function;
................process(ptr);
................free(ptr);
........}
....}while(a ....if(a==b)
....{
....}
....else if
....{
....}
....else
....{
....}
}
머 대충 이런 식으루 짭니다.. 그리구 for 구문은 사용을
안합니다.. 왜냐면.. 걍 짜다보니 사용 안하게 되서리..
고전적 bsd 스타일을 선호하시는군요 :)emacs 의 기본 코딩스타
고전적 bsd 스타일을 선호하시는군요 :)
emacs 의 기본 코딩스타일에 들어있습니다.
저는 for를 주로쓰고 while을 안쓰게 되더군요;;;;
저는 for를 주로쓰고 while을 안쓰게 되더군요;;;;
저도 auto-indenting을 매우매우 즐겨쓰는 사람입니다.. -_-
저도 auto-indenting을 매우매우 즐겨쓰는 사람입니다.. -_-;;
일반적으로 java를 많이 쓰다보니 java 규약대로 짜게 되더군요...
그 머였더라... jakarta 프로젝트 규약 비슷한 모양의 코드가 나오더군요...
아참. javadoc은 가능한 한 다 달아놓으려고 노력합니다... -_-;;
이게 너무 중요한 것 같더군요...
코드 indenting같은 것은 자동 툴로 하면 되는데...
주석은 자동으로 정리해 주는 툴이 없다보니...
변수 할 때 static변수는 s_ 앞에 붙이고...
instance변수는 m_ 앞에 붙이는 정도만 좀 특이하고요.. -_-;;
local변수는 암것두 안 붙이고... -_-;;
자동완성기능을 쓸때 m_ 까지만 입력하고 그담에 쫓아다니는 게 편하다보니.. -_-;;
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
저는 항상 {}를 내려 쓰는데여... 아래 처럼여...if(con
저는 항상 {}를 내려 쓰는데여... 아래 처럼여...
if(condition)
{
[TAB]statement
} else if (condition)
{
[TAB]statement
}
그 전에는 {를 ) 뒤에 바로 썼는데...CoreJava책으로
Java공부하다가...스타일을 바꿨져...ㅡㅡa
그 뒤로 C코딩 스타일도 거의 Java랑 비슷합니다.
함수나 변수 이름은 JAVA방식을 씁니다...
함수의 이름 경우 시작은 소문자 그 다음부터는 대문자로
시작....
getString() <- 이런 식?
변수도 글쿠여...
그리고 가능하면 i, j, k, x, y, z같은 변수도
안 씁니다...count 이런식으로 다 알아보게...ㅡㅡa
그러다보니 전반적으로 이름이 길어지는 경향이...쩝
저도 변수명을 길게 적는 것을 좋아합니다.어차피 vim에서 자동완성기
저도 변수명을 길게 적는 것을 좋아합니다.
어차피 vim에서 자동완성기능도 있겠다 (vi기능일지도 모르겠군요. ctrl-p 말입니다)
알아보기 상당히 쉬워지죠..
개인적으로 변수명에 data type 적는 것은...
글쎄요...혼자 짤 때는 data type을 변수명에 기입하지 않습니다.
더 헷갈려요 -_-;;
그리고 indentation은...저..위에 있는 kernel 코딩시의 style과 같군요...=)
전 저게 편하더라구요... =)
#include <something.h> // 띄우구요for( ;
#include // 띄우구요
for( ;; )
{ // 이놈은 꼭 내려 써요
function( 100 ); // 괄호 위치는 저런식...
// 스페이스바는 4번
}
예전에는 헝가리안식 안썼는데, 요즘은 한정적으로 전역변수 g_, 클래스 멤버 m_, 지역변수 temp 를 접두어로 붙여줍니다.
ㅎㅎ 코딩스타일에 관한 이야기라면 모든 분들이 할 얘기가 많으시겠죠 ^.^
#include<... <-딱 붙여씁니다-_-main(){
#include<... <-딱 붙여씁니다-_-
main(){
int n;
char c;
.
.
.
위에 보면 아시겠지만,줄이 맞춰줘야 합니다-_-
만약 않될경우,탭키를 써서 그밑줄부터 다시-_-;
if(n<0){
do{
........
.........
..........
}while(...);
}
처음 코딩할떄부터,이런 습관이 형성됬습니다-,.=;
간혹,안그러긴 하지만-.-
적당히 스페이스 눌루고, 탭눌구, 주석처리 해가면서 마구 짠다.그
적당히 스페이스 눌루고, 탭눌구, 주석처리 해가면서 마구 짠다.
그러다 못 알아보겠으면 씨 소스 이쁘게 해주는 걸로 돌려 버린다.
예) bcpp 돌려 버리면 자기가 알아서 이쁘게 해준다.
전 헝가리언 표기법을 철칙으로 알고 (마치 안지키면 컴파일도 안될것처럼)
전 헝가리언 표기법을 철칙으로 알고 (마치 안지키면 컴파일도 안될것처럼) 지켜왔는데요... 팀장말로는 MS에서 잘나가는 프로그래머들은 헝가리언 안지키고...C에서 프로그래밍하듯이 한다네요.. code_len, ret_string 이렇게...
mSQL이나 qMail봐도 헝가리안 표기법 아예 볼수가 없던데..
그리고 꼭
if(..)
{
} // end if
이렇게 씁니다.
if(...){
}
이거 넘 알아보기 힘들던데.. 소스가 길어지면...
그리고
for(;;)
{
} // end for
중괄호 닫을 때 꼭 // end for 이런거 붙여줍니다.
OpenSSL 소스 보면 -_-if (condition)[ta
OpenSSL 소스 보면 -_-
if (condition)
[tab]{
[tab]어쩌고저쩌고
[tab]}
이렇게 되던데 ㅠ_ㅠ
아... 정말 보기 싫습니다 :'(
Microsoft Press에서 나온 Code Complete라는 책에
Microsoft Press에서 나온 Code Complete라는 책에 보면 Indentation에 대한
다양한 연구 결과과 있고 실제로 방식에 따라 다른 오류와 완성도를 보인다고
합니다. 언급하신 스타일은 거기서 추천하는 것 중의 하나로 Pure Block Style입니다.
또다른 것으로
if ( condition ) {
[TAB|SPACE]code
}
가 있지요. 좋지않은 방법으로
if ( condition )
{
[TAB|SAPCE]code
}
가 예로 나와 있습니다. 이유는 필요 이상으로 블럭을 복잡하게 보이게 한다는
것이지요.
마이크로 소프트에서 나온것이니 버그 패치하기 전에는 그대로 따라하지 마세
마이크로 소프트에서 나온것이니 버그 패치하기 전에는 그대로 따라하지 마세요.
나중에 패치가 3번쯤 나온뒤에 사용하시는 것이 정신건강에 좋으실 듯 하군요.
참고로 전 무조건 {를 내려 씀니다.
하하...연구 결과는 MS와 아무 상관이 없습니다. 그리고 다른 회사
하하...
연구 결과는 MS와 아무 상관이 없습니다. 그리고 다른 회사도 마찬가지로
이 책을 보고 교육을 시킵니다. 유명한 책인데... 모르셨나요/ 아니면
제가 제목을 잘못 썼나?
제가 이런 code 때문에 죽을 맛입니다. 주변에 있는 사람은 다 이렇게
제가 이런 code 때문에 죽을 맛입니다. 주변에 있는 사람은 다 이렇게 program을 짭니다.
CodeWright를 배우면서 다들 이렇게 배웠다네요.
반도체업체에서 받은 code는 모두
if(Condition) {
...FuncA(,,,)
}
else {
...FuncB(,,,)
}
로 되어있고
회사동료들은 모두
if(condition)
...{
...Func_A(,,,)
...}
으로 짜구요.
저는
if(...)
{
...FuncA(...)
}
else
{
}
으로 짜는 데, 한번씩 정리하려면 미칩니다. 아마도 editor에 따라서 좀 다른 것 같군요. 물론 습관도 있구요.
전 괄호의 위치까지는 중요하지 않다고 생각합니다.중요한 건 일관성
전 괄호의 위치까지는 중요하지 않다고 생각합니다.
중요한 건 일관성이라고 생각하며,,
그리고 다른 사람의 코드 보면서 가장 필요하다고 느끼는 건 코멘트 이지요..^^
코멘트는 많으면 많을 수록 좋다고 생각하구요.
코멘트도 align 맞춰주는 게 좋고..
또 모니터 작은 사람 생각해서 코멘트 옆으로 너무 길게 달지 않는게 좋다고 생각합니다.
그리고 디렉토리에 파일 나눠서 관리하는 것도 중요하다고 생각하구요.
또 디렉토리 나눈 것과 그에 저장된 각 파일들에 대한 간단한 코멘트 파일 역시 중요하다고 생각합니다.
code complete (프로그래밍 완전 정복) 이라는 책도 이런 것에 관해서 자세히 다루고 있는데 군데군데 읽을만한 내용도 많더군요.
뭐 Microsoft Press 에서 나온 책이긴 하지만..^^;;
코드를 indent하는데 텝을 쓰느냐, 스페이스를 쓰느냐, 괄호를 어
코드를 indent하는데 텝을 쓰느냐, 스페이스를 쓰느냐,
괄호를 어디에 위치시키느냐 하는 문제는
아마 결론이 나지 않을 문제일것 같습니다.
예전에는 텝사이즈를 4로하냐 8로 하냐 가지고도
격렬한 토론이 있던 것으로 기억합니다.
역시 이미 말씀하신 대로 일관성이 중요한 것 같습니다.
다만 주석(comment) 많을 수록 좋다는 말씀에는 반대합니다.
(개인적인 의견이니까 기분 나빠하지는 마세요...)
사실 잘 디자인된 명확한 코드에는 주석이 필요 없다고 생각합니다.
변수 이름, 메쏘드 이름을 잘 지어 놓으면, 코드를 읽는 것 만으로도
주석을 읽는 것처럼 코드를 이해할 수 있습니다.
주석이 잔득 붙어 있는 코드를 보면, 코드가 엉성하거나 명확하지 않기 때문에
주석이 붙어 있는 경우가 얼마나 많은지 생각해 보시기 바랍니다.
물론 javadoc 같은 경우는 좀 다르구요. (이건 문서화의 의미도 있으니까)
사실 코드만 봐도 명확한데 주석이 붙어 있다면 좀 짜증이 날 수도 있습니다.
그리고 주석을 붙여야만 이해할 수 있는 코드라면, 코드 디자인이 잘 못 되어
있을 확률이 높다고 할 수 있습니다. 이런 경우에는 주석이 없어도 이해할 수
있도록 코드를 수정해야 할 것입니다.
따라서 저는 코딩할 때 주석을 많이 달지 않습니다.
대신 변수 이름, 메쏘드 이름을 지을 때 그 의도를 명확히 하려고 고민을 합니다.
그러나 몇몇 경우에는 주석을 꼭 달아 놓는것이 좋습니다.
예를 들면 Java의 Swing에는 아직도 많은 버그를 포함하고 있는데,
컴포넌트를 만들다 보면 이런 버그를 피하는 코드를 작성해야 할 때가 있습니다.
이런 코드는 그냥 봐서는 그 의도가 명확하지 않기 때문에 주석을 달아
놓으면 나중에 찾기도 쉽고, 그 의도도 명확히 이해할 수 있겠죠.
제가 책에서 읽은 내용과 개인적인 의견을 몇줄 적어보았습니다.
모든 경우에 해당된다고 할 수는 없겠지만,
주석에 대해서 한번 다르게 생각해볼 기회가 되었으면 좋겠습니다.
- ntalbs
주석을 어떻게 다는지에 관한 여러 사람들의 다양한 의견은http:
주석을 어떻게 다는지에 관한 여러 사람들의 다양한 의견은
http://geekforum.kldp.org/stories.php?story=01/05/08/9655663
을 참고하세요... :-)
저는 GNU type에 가까운 것 같네요.. 똑같진 않지만...T
저는 GNU type에 가까운 것 같네요.. 똑같진 않지만...
TAB을 많이 이용하고 간격을 4를 주로 이용합니다.
띄어쓰기를 많이 이용해서 최대한 가독성을 높여 줍니다.
또, {}는 항상 그 줄에 맞도록 위/아래로 배치해서 플밍을 하는 편입니다.
C에서는 코딩하기가 좋았는데.. PHP 같은 Web용 language 경우 HTML로 같은 형식으로 코딩을 하니까.. echo or print文에서 좀 줄이 맞지 않는 단점이 있습니다. 함수안에서의 ()괄호안에서 예전엔 띄워쓰기를 했는데, ( aaa ) 형식으로... 요즘은 (aaa) 형식으로 씁니다.
변수명은 헝가리안 표기에 맞도록 쓸려고 합니다.
그럼...
항상 코딩하기전 가장 앞줄은 쓰지 않고 TAB으로 처리합니다.
if(condition)
{
statement;
}
else if(condition)
{
statement;
}
else
{
statement;
}
앞줄에 탭으로 띄워야 하는데.. 띄어쓰기가 안되네여...PRE tag라도
앞줄에 탭으로 띄워야 하는데.. 띄어쓰기가 안되네여...PRE tag라도 쓸걸 그랬나여?
이런 스타일은 어떤가요..#define max(A, B) ((A)
이런 스타일은 어떤가요..
#define max(A, B) ((A) > (B) ? (A) : (B))
아주 고전적인 스타일이지만
{}나 탭등의 논란꺼리보다는 조금 더 발전적인 코딩 스타일이라고 봅니다만..
매크로도 너무 많이 쓰면 안좋은거 같아요...MFC같은경우에는 그
매크로도 너무 많이 쓰면 안좋은거 같아요...
MFC같은경우에는 그 엄청난 매크로때문에 코딩하기가 짜증날 정도던데요...
MFC의 M이.. 매크로의 M이라는 설도 있던데... -_-
gnu util의 소스를 보다보니 중첩된 if를 많이 봤는데이런것도
gnu util의 소스를 보다보니 중첩된 if를 많이 봤는데
이런것도 '스타일' 같네요.
p.s.
if보다 switch가 더 나쁘다는군요.
그래서 그런가 파이썬에선 switch문이 없지요.
이런식으로 다 빼고나면 for, while, ? (3항연산자) .. --;
차빼고 포빼고나면 뭘로 장기두지요?
고수는 상과 마로 한다는데 초보에겐 엽기로 밖에 안보입니다..
goto가 아주 엽기짓이죠 -_-;;for,while 모두 거부할 수
goto가 아주 엽기짓이죠 -_-;;
for,while 모두 거부할 수 있는 쓰레기 스파게티 코드를 만드는 아주 멋진 -_-;;
예전에 간단한 프로그램 짰을때 시간 없다고 goto 몇 번 썼는데
역시나 사람이 할 짓이 못되겠더라는
switch가 나쁘다는것은 객체지향에서나 나오는 얘기랍니다.if
switch가 나쁘다는것은 객체지향에서나 나오는 얘기랍니다.
if else if else if else나 switch나 그게 그거죠
글쎄요. 단순히 switch문이 나쁘다 if문이 나쁘다고 하기는 어렵지요
글쎄요. 단순히 switch문이 나쁘다 if문이 나쁘다고 하기는 어렵지요. 배우셨으니 아시겠지만, 어떻게 compile되는 지를 먼저 확인하시고 code 길이가 중요한지 시간이 중요한지 뭐 따질 것이 좀 많겠네요. 제 경우는 이런 것들을 먼저 확인하고 program을 시작하지요.
제가 하는 것이 embedded분야라서 가끔은 처음보는 ARM, MIPS, SHARC, 등의 assembler도 볼일이 있어서요.
while도 제거할 수는 있습니다. for문으로 대체하면요 ^^;
while도 제거할 수는 있습니다.
for문으로 대체하면요 ^^;
개인적으론 while보다 for(;condition;) 스타일을 선호하는 편이라...
----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ
아마 내가 최고로 조잡한 코딩스타일이 아닐까? ㅋ ㅔㅋ ㅔ주석절대없음
아마 내가 최고로 조잡한 코딩스타일이 아닐까? ㅋ ㅔㅋ ㅔ
주석절대없음(대신변수명졸라김)
공백절대없음
예제:
for($i=0;$i if($Kind=="Edit") echo"ㅋ ㅑㅋ ㅑ";
else echo"ㅋ ㅕㅋ ㅕ";}
얼마전 어떤 책을 보니...코딩할때 if 문 많이 쓰는 놈은 남
얼마전 어떤 책을 보니...
코딩할때 if 문 많이 쓰는 놈은
남 고생시키지 말구. 배추장사나하라구...
그리구 박영만씨(학원경영하죠?)는 코딩할때
if문없이 코딩해야 한다구 했다던데... 이게 가능한지...
이것도 어쩌면 코딩스타일하구 관계가 있겠죠..
전 요즘 if문 쓸때면.. 한번 더 생각합니다...
여러분은 어떠세요..
if 문을 무조건 쓰지 말라는 얘기는 아니고조심해서 사용하라는 얘기겠
if 문을 무조건 쓰지 말라는 얘기는 아니고
조심해서 사용하라는 얘기겠지요.
실제로 무분별하게 사용된 if문은 실행의 흐름을
뒤엉켜놓아서 읽기 어렵게 합니다.
if문을 잘 쓰는 요령은 조건문의 조건을 신중하게 살펴서
가능한 분기의 수를 줄이고
중첩된 if문보다는 else if를 사용할 것.
(switch보다 else if를 사용하라는 얘기가 있는데 저는
여기에는 찬동할 수 없습니다. 제 생각엔 switch문이
훨씬 읽기가 쉽습니다.)
for문이나 while문의 조건절을 잘 사용할 것.
이정도가 되지 않을까요?
그리고 대개 함수 초입부에서 파라미터 검사나 에러처리를
하기 위해서 if문을 많이 사용하는데 저는 이런 에러처리는
ASSERT로 모두 간단하게 처리해버리고 실제 릴리즈할때는
모두 뺍니다.
그래서 제가 만드는 함수는 void 타잎이 많죠.. 귀찮게
에러값 리턴 안합니다. 실제 해보시면 아시겠지만 훨씬
편합니다.
그럼 이만
우선은 간단하게 말씀드리자면 박영만씨 말은 틀립니다. programm
우선은 간단하게 말씀드리자면 박영만씨 말은 틀립니다.
programming language에서 제공하는 것들은 필요할 때 제대로 사용해야지 무조건 if문이 없이 코딩해야 한다면 문제가 있습니다.
if문은 programming시 너무나 다양하게 많이 사용되어서 사용하지 않는 프로그램은 없습니다. hello world 프로그램이라면 모를까, 사실 우리가 사용하는 모든 프로그램은 거의 if를 내장합니다.
Freedom
저도 물론 goto less 를 지지합니다. 하지만 박영만씨의 경우는 '
저도 물론 goto less 를 지지합니다. 하지만 박영만씨의 경우는 '학원'이라는 곳에서 다수의 사람을 가르키다 보니 어쩔수없는 '강한' 표현을 하신게 아닐까 합니다.
아, 물론 전 박영만씨를 알지도, 보지도 못한 사람임다.
음...근데... UNIX 프로그램밍 하면서 if문을 안쓰고 가능
음...
근데... UNIX 프로그램밍 하면서 if문을 안쓰고 가능한지?
저같은 경우는 딴거 중에 if문이 가장 많이 들어 가는거 같은데...
if문 만큼 에러 처리에 유용한 놈은 없는거 같네요...
거의 if문으로 -1이나 0값을 잡아내는...
만약 UNIX에서 if문이 없다면은 M$만큼이나 자주 많이 다운이 되지나 않을라는지요?
그리고 저도 코딩 처음하면서 부터 goto문은 사용하지 않는게 좋다고 뱌웠습니다.
물론 지금도 저의 코드엔 전혀 goto문은 없습니다.
그러나 주의만 한다면 이것도 사용을 해도 문제가 없을 듯 한데 이걸로 인해 에러가 발생하고 잡지 못하는 경우는 아주 치명적일 듯...
그리고 코딩을 함에 있어 대세를 따른는 것도 좋지만은 일관성 있게 짜주는게 더욱더 중요할거 같네요.
처음엔 보기 힘들지라도 자꾸 보면은 쉽게 파악이 가능하니깐요...
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!
이 주제와는 상관없는 내용이지만...goto문을 무조건 쓰지말라는건
이 주제와는 상관없는 내용이지만...
goto문을 무조건 쓰지말라는건 아닙니다.
같은 모듈내에서는 goto문을 쓰셔도 상관없습니다.(물론 이것도 프로그램의
가독성을 떨어뜨리긴 합니다만, 어쨌든 프로그램의 성능의 측면에서는 문제가 없습니다.)
SW공학 측면에서 볼때 다른 모듈로 점프하는 goto문을 쓰면 프로그램의 결합도가 높아져서 좋은 프로그램이라고 할 수 없습니다.
goto 문이 programming에서 사용하면 안된다고 하면서 왜 아직
goto 문이 programming에서 사용하면 안된다고 하면서 왜 아직도 존재할까요?
goto 문은 system programming을 하다보면 많이 사용합니다. 우리가 사용하는 standard library에서도 내부적으로 사용될 정도이며 잘 아시다시피 UNIX Kernel을 분석하시다 보면 쉽게 발견되지요...
그 이유는 속도입니다. 아무리 소프트웨어 공학도 중요하지만 정작 중요한 것은 사실 어떻게 해서든 탄생되어 좋은 프로그램이 되는 것이지 프로그래머에게만 좋은 코드로 탄생된 프로그램은 아무 쓸모도 없습니다. (물론 프로그램이 좋다면 상관없지만요... ^^)
Freedom
goto를 쓰는 것은 성능이나 속도 때문이 아닙니다. 오히려 컴파일러들은
goto를 쓰는 것은 성능이나 속도 때문이 아닙니다. 오히려 컴파일러들은 goto가
있으면 더 최적화에 불리하다는 연구 결과들은 많습니다. goto를 쓰는 이유는
비 정상적 상황, 즉 C++나 Java, Objective-C등의 Exception으로 처리해야
하는 상황이 있을 때 C에서는 특별한 방법이 없는 경우가 있고(실제로는
longjmp, setjmp등으로 가능하다고 합니다.) 무조건 적인 탈출을 요하는 경우에만
한정적으로 씁니다. 물론 Hand Optimization을 위해서 하는 경우도 있겠지만
그런 경우는 거의 없다고 봐야죠. 차라리 inline assembly가 낫겠지요.
그래서 자바에는 break문에 레이블을 쓸 수 있죠. 이런 경우는 괜찮다
그래서 자바에는 break문에 레이블을 쓸 수 있죠. 이런 경우는 괜찮다고 보는 것 같군요.
몇 단계 while을 빠져나오게 하느라고 조건 마구 붙여서 복잡하게 하는 것보다 낫다고 봅니다.
indent 의 맨페이지를 보니미리 정의되어 있는 코딩 스타일이 몇가
indent 의 맨페이지를 보니
미리 정의되어 있는 코딩 스타일이 몇가지 되더군요.
GNU style, Kernighan and Richie style, original Berkeley style...
저는 Kernighan & Richie style 에 약간의 변형을
가해서 쓰고 있습니다 :)
커널의 소스도 K/R 스타일에 약간의 변화를 준
스타일이더군요 :)
시간나시면 indent 의 맨페이지를 한번 보세요. 재미있습니다.
때려쳐 뭘 하겠다고..
때려쳐 뭘 하겠다고..
들여쓰기는 두칸 정도로만 합니다.들여쓰는 칸이 커지면 중첩문이 많아지
들여쓰기는 두칸 정도로만 합니다.
들여쓰는 칸이 커지면 중첩문이 많아지면 정신없기도 하고요.
두칸 정도로도 충분히 구분이 되던데요. -_-
옛날엔 그냥 다 탭으로 해버렸는데 소스보려면 정신없어서 --;.
중괄호는
int functionName ( argument ) {
...
}
if ( condition ) {
...
} else {
...
}
do {
...
} while ( condition );
이런식이고요. 제일 보기 무난한듯 합니다.
전 gnu 코딩스타일을 따릅니다.if () { 내용
전 gnu 코딩스타일을 따릅니다.
if ()
{
내용
}
else if ()
{
}
emacs 로 하면 디폴트더군요.. :)
맨앞의 공백문자가 사라지다니... :)http://www.gnu.
맨앞의 공백문자가 사라지다니... :)
http://www.gnu.org/prep/standards_toc.html
GNU Coding Standards
저 같은 경우에는 위와 비슷한 코딩 스타일로 코딩합니다..특히
저 같은 경우에는 위와 비슷한 코딩 스타일로
코딩합니다..
특히 자바 코딩 표준과 거의 같져...
이유는 보기 싶다는 것입니다.
물론 보시는 분에 따라 틀리겠지만 제가 생각하기에는 가장 좋은 코딩 스타일은 다른 사람이 보기 쉬운 코딩이지 않을까요????
그럼..
저 같은 경운...느낌으로 코딩을 하기 때문에.. 머리에서 막 떠오르
저 같은 경운...
느낌으로 코딩을 하기 때문에.. 머리에서 막 떠오르는 순간 바로 손이 움직이기 시작합니다.
그래서 ... 어느 순간 막히면 좀 생각하고 .. 또 떠오르면 코딩하고.. 이렇거든요.
부분부분의 루틴에 대한 주석을 달 여력이 없죠 ...
주석을 다는 순간 뇌리를 스치고 지나간 그 알고리즘 구현이 잊혀지거든요..
칠대는 알아먹게 치는데 ...
치구 나서 난중에 한 일주일쯤 지나서 보면 ...
1-2시간은 헤매고서야 이해를 하지요 ..
무지 멍청하지 않습니까? 부디 저같은 분이 없기를..
훌륭한 프로그래머는 코딩 스타일부터 훌륭하거든요~디버깅 잘하는 사람이 훌륭한 프로그래머라고 하는데.. 디버깅 잘하는 사람 코딩 스타일도 좋을거에엽.
의미없는 토론 아닐까요?깔끔한 스타일을 일괄적으로 사용하시요
의미없는 토론 아닐까요?
깔끔한 스타일을 일괄적으로 사용하시요
그런가요? code convention은 나름대로 의미가 있다고 보는데
그런가요? code convention은 나름대로 의미가 있다고 보는데
보통 언어에서 추천하는 code convention 들이 있죠
다들 잘 알고 계시겠지만
자바 같은 경우는 http://java.sun.com/docs/codeconv/ 에 보면 규약으로 나와 있고...
헝가리안 표기법등 많이 있지 않나요?
그런 code convention들을 적용하면 코드 해석하기 쉽고 결정적으로 프로그램 규모가 커지거나 협업할때 다른 사람 코드를 보기도 편해서 좋은 것 같은데... 님들의 생각은 그렇지 않나요?
최소한 헝가리안 표기법은 모든 프로그래머가 배워야 된다는 생각이 드는군요
최소한 헝가리안 표기법은 모든 프로그래머가 배워야 된다는 생각이 드는군요.
변수 앞에 형식을 표시하는 것은 쓸만한 것 같기는 한데, 거기 적힌 표기
변수 앞에 형식을 표시하는 것은 쓸만한 것 같기는 한데, 거기 적힌 표기법을 그대로 쓸 필요는 없다고 생각합니다.
int, double, string(char이지만 하여튼) 정도까지는 그렇다 쳐도, 직접 정의한 구조체나 클래스 정도까지 가면 꽤 난감해집니다. 함수에 쓰려면 더 복잡해지죠. 전 그래서 기본형 변수에만 씁니다. 나머지는 마음대로죠.
헝가리안 표기법이 어떤지는 알아야겠지만,헝가리안 표기법이 그렇게 맞는
헝가리안 표기법이 어떤지는 알아야겠지만,
헝가리안 표기법이 그렇게 맞는 건 아닐텐데요.
밑의 분 말씀대로 리눅스 커널 쪽 코딩 스타일에서도 언급되어 있고,
자바의 코딩 스타일에 관한 것에도 헝가리안 표기법에 대한 언급이 있습니다.
(밑의 것과 거의 비슷한 주장을 하는 걸로 ...)
헝가리안 표기법에 대해 부정적인 의견을 펼치는 것은 여러군데서 많이 보았습니다.
페이지
댓글 달기