함수와 변수의 네이밍 룰에 대한 의견을 듣고 싶습니다.

next의 이미지

처음 C를 접했을 때와, 객체지향 언어들을 접했을 때, 그리고 Windows의 헝가리안 표기법들을 접하다 보니

요즘은 모든것들이 짬뽕이 되어 함수 이름과 변수 이름을 짓는데에 애로가 많습니다.

혼자서 진행하는 프로젝트라면 아무 문제가 없겠지만, 여러 사람이 함께 진행해야 하고, 차후 유지보수를 위해서라면 어느정도 규칙성이 있고 체계화 되어 있는 스타일을 정해야 한다고 생각 하는데요.

전역변수, 구조체의 멤버변수, 스태틱 변수, 자동 변수, 모듈별 혹은 기능별 함수 명명법 등등 어떤식으로 하고들 계신지 궁금하네요.

댓글

espereto의 이미지

제 경우는...
일단, 전역변수는 "절대 안 쓴다"라는 원칙을 세우고 작업합니다. 쓴다고 하면 const 변수인 경우만 한정해서 씁니다. (쓰레드 안전성과 그 외의 몇 가지 이유때문에)

거의 모든 변수는, theVariableOne 과 같이 작성합니다. 전역 변수가 없기때문에 모든 변수는 구조체의 멤버이거나 자동 변수입니다. 제가 쓰는 자동 변수는 어차피 대부분 정해져 있어서... (ret, retval, tmp, i, j, k, x, y, p 와 같이) 괄호에 적은 것들 이외에는 변수명으로 적당히 구분해서 씁니다.

구조체의 타입이나 이름은 TheStructure 와 같이 대문자로 시작합니다. 그리고 구조체 변수의 이름은 변수 규칙을 따릅니다.

함수이름은 modFunctionOne() 혹은 mod_functionOne()과 같이 모듈명의 단축어를 말머리로 해서 3~4자 정도 소문자로 적고 그 뒤에 _는 선택사항, _를 안 넣으면 대문자로 _를 넣으면 소문자 시작하게 함수이름을 정해서 붙입니다. 그리고 가능하면, 동사가 먼저 나오고 그 다음 목적어라던가 등등이 나오도록 합니다.

keep tabs, tab size 4, indent size 4 로 설정하지만, keep tabs 대신 insert space를 쓰는 쪽으로 요즘은 바꿔가고 있습니다.

대략 이 정도로 정해서 씁니다.

zepinos의 이미지

크게...어떻다! 라고 말씀드리기 보다는...

어쨌든 공동으로 쓰는 표준안을 하나 정해서 쓰십시오. 같이 코딩하는 사람들끼리만 이용하는 표준도 괜찮습니다.

어떤 표준안이냐...보다는 표준안을 만들어서 철저히 지키는게 훨씬 중요하니까요.

(얻그제 제가 표준 전혀 없는 프로젝트 때문에 열받아서 글도 올렸었죠)

개인적으로는 iCount, sBuf, fSum 과 같은 변수명과 fSubstring(), fSubmitQuery() 와 같은 펑션명, CAccessDB 와 같은 클래스명을 이용했습니다.
그것보다 더 중요한 것이 사용되는 변수, 함수, 클래스에 대한 목록을 Excel 이나 Access 로 관리하고, 기획 단계에서 나온 시나리오나 페이지 명세서에 사용될 함수나 변수, 그리고 파라매터 이동상황 같은 것을 명확히 적어두는 것이죠.

어쨌든 누가 그러한 것을 봤을때 변수명 같은게 마구 바뀌어서 혼란을 겪지 않을 정도만 되면 되지 않을까 합니다.

ㅡ,.ㅡ;;의 이미지

그냥 지나가다 한마디 하자면..

1. 룰이 없는것이 룰..
2. 그렇지만 권할것이 있다면.. 쓸데 없이 길게쓰지말것..
3. 그리고 몇가지 로컬변수혹은 함수에 lf li lc 따위를 붙이라고 제발 강요하지말것...( 홍길동 이 집에가서도 홍길동아! 로 불리는격)
4. 참고로 전역은 첫글자대소문자로 표현해줌으로써 궂이 접두어를쓰지 않도록..define 은 모두대문자..
4. 네이밍에 대소문자를 마구뒤썩어서..보는이로 하여금 이름을외워쓰기힘들게 하지말것..


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

김준경의 이미지

저같은 경우는 같이 작업하는 사람들의 소스를 눈치껏 보고 스타일을 비슷하게 맞추려고 노력하는 편입니다. 혼자 작업하는 거라면 그냥 평소에 자주 쓰는 스타일로 작성합니다. 물론 어떤 규칙에 따른 일관된 모습은 보여줘야 겠지요.

솔직히 아직까지 어떤 소스는 정말 특이한 방식으로 소스를 적어놨더라...라는건 잘 보질 못했습니다. (외국의 소스들을 보면 가끔 보이긴 하더군요.) 실제 작업장에서도 흔히 많이 알려져 있는 3~4가지 정도의 코딩스타일을 대충이라도 안다면 어렵지 않게 남들이 불편해하지 않는 소스를 작성 할 수 있지 않을까 생각됩니다.

아무래도 인터넷상에 떠돌아다니는 소스라던가 문서화된 코딩 스타일을 참고하시는게 보다 직접적인 도움이 되지 않을까 싶습니다만..

ps. 마구잡이 식으로 작성해놓고 남들을 설득하는 방법도 있기는 하겠군요. :twisted:

happycat의 이미지

http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200504080001

이 책이 도움이 될 지도 모르겠군요. (보지는 않았습니다;; )

스타일은 프로젝트 단위로는 반드시 통일되어 있는 것이 좋을 것입니다.

스태틱, 맴버, 클래스, 변수 등에 대해 많이 쓰는 규칙은 몇몇 있습니다.

아마 위 책에서 소개되어 있을 것이라 생각되고요..

꼭 한가지 말씀 드리고 싶은 것은 x, y 따위의 변수는 쓰지 말라는 것입니다.

머리 좋고 코드를 잘 짜는 프로그래머 들이 변수 명 등은 x, y로 막 쓰는 것을 자주 봤습니다.

변수명 따윈 아무래도 좋다 그런 자세인데요.. 차후 유지 보수 하는 사람이 아주 괴로워지고, 결국 자기도 보기 힘들어집니다.

lovu77의 이미지

>꼭 한가지 말씀 드리고 싶은 것은 x, y 따위의 변수는 쓰지 말라는 것입니다.

>머리 좋고 코드를 잘 짜는 프로그래머 들이 변수 명 등은 x, y로 막 쓰는 것을 자주 봤습니다.

변수의 lifecycle이 짧고, scope이 좁다면 오히려 가독성을 더 향상시킨다고 봅니다.

for (DWORD dwLoopIndex = 0; dwLoopIndex < 10; ++dwLoopIndex) {
...
}

이런 경우도 본적이 있는것 같습니다.

물론 for 루프 내가 엄청나게 길다면, 의미가 있을 수 있지만 (그렇다 하더라도 저 이름은 정말 아니죠 ㅎㅎ) 10-20중 내의 짧은 경우라면 당연히 i, j 또는 x, y와 같은 변수가 맞다고 봅니다.

cppig1995의 이미지

10-20중... 후덜덜

for(int i = 0; i < 100; ++i)
        for(int j = 0; j < 100; ++j)
                for(int k = 0; k < 100; ++k)
                        for(int l = 0; l < 100; ++l)
                                for(int m = 0; m < 100; ++m)
                                        for(int n = 0; n < 100; ++n)
                                                for(int o = 0; o < 100; ++o)
                                                        for(int p = 0; p < 100; ++p)
                                                                for(int q = 0; q < 100; ++q)
                                                                        for(int r = 0; r < 100; ++r)



한말글 프로그래밍 언어 "열정" http://me-lang.wo.tc

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

김준경의 이미지

Quote:
꼭 한가지 말씀 드리고 싶은 것은 x, y 따위의 변수는 쓰지 말라는 것입니다.

머리 좋고 코드를 잘 짜는 프로그래머 들이 변수 명 등은 x, y로 막 쓰는 것을 자주 봤습니다.

전 머리도 안좋은게 x, y던가 i, j같은건 자주 쓴답니다. :oops:

happycat의 이미지

i, j는 저도 많이 씁니다. 주로 for룹의 index로 자주 들어가죠.

사실 i, j정도는 일반적으로 index로 이해한다고 봐도 좋을 거 같습니다.

x, y도 좌표축의 의미라면 의미를 가질 수도 있겠죠..

하지만 '임의의 의미'를 가지는 x, y, a, b 따위등은 문제가 많다고 봅니다 :)

죠커의 이미지

the c++ programming language에서 추천한 rule이 좋다고 생각합니다.

유효범위가 좁은 명칭에 대해서는 최대한 간결하고 관습적인 명칭을 사용하고 긴 명칭은 길고 직관적인 이름을 사용하라는 것이지요. 이 정도 정책이 혼란스럽지도 않고 유지 노력에 비한 효과도 크지 않나 생각합니다.

유효범위가 긴 명칭은 나중에 접하게 되었을때 "어떤 명칭이냐?"에 답하기 어려운 부분이 있기 때문에 길고 직관적인 이름이 좋지만 짧은 범위에 쓰이는 명칭을 FirstIterationOfNestedFiniteLoop처럼 길게 적을 필요는 없을 것 같습니다. 소스를 보면서 충분히 이해가능하고 관습적인 부분으로도 이해가능하니깐요. for(int i=0; i != 10; ++i)의 i를 길게 적을 필요는 없겠지요. 함수의 인자에 대해서도 짧은 함수에 대해서는 관습적이고 짧은 명칭을 적용하는 것이 좋은 선택이라고 생각합니다. 연산자 오버라이딩을 했고 그 길이가 짧다면 이 경우에도 lhs, rhs와 같이 짧고 관습적인 인자명이 충분히 통할 수 있다고 봅니다.

헝가리언 표기법은 안 지키는 것이 좋다고 생각합니다. 헝가리언 표기법은 아주 원초적인 자료형 부터 프로그래머가 수동으로 형의 정보를 명칭에 기록을 해주어야 하기 때문에 관리에 부담이 됩니다. 그래서 제대로 지켜지지 않고 이런 점이 나중에 코드를 읽을 때 집중에 방해가 되는 요소가 됩니다. Refactoring 툴과 같이 자동화 도구가 있다면 모를까 현재로서는 에러입니다.

public 속성과 private 속성에 대해서 명칭의 앞 혹은 뒤에 _를 붙일 것이냐. 아니면 차별없이 사용하며 명칭이 겹칠 경우 this->를 사용할 것이냐는 선택의 문제가 되겠지요.

anarch의 이미지

별다른 룰은 없지만...
우선 생각 나는 데로 적어 본다면.

객체 이름의 경우 ClassName 처럼 위키 스타일로 합니다.(사실 스몰토크 죠..)
인스턴스의 경우 objectName 처럼.. 소문자로..

정적 메소드는 GetList 처럼 대문자로 시작하고
인스턴스 메소드는 getList으로 소문자로 합니다..

파이션같은 언어는 function도 지원하니까..

get_list을 씁니다.

사실 별다른 룰이 없군요.. T_T

creativeidler의 이미지

썬에서 제시한 Java Code Convention을 참조해 보시기 바랍니다. 아마도 현재 가장 널리 쓰이는 컨벤션일 것이고 다른 언어에도 많은 영향을 미치고 있습니다.

ㅡ,.ㅡ;;의 이미지

CN wrote:
헝가리언 표기법은 안 지키는 것이 좋다고 생각합니다. 헝가리언 표기법은 아주 원초적인 자료형 부터 프로그래머가 수동으로 형의 정보를 명칭에 기록을 해주어야 하기 ....

동감입니다. 헝가리안 만은 쓰지마세요..^^


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

ㅡ,.ㅡ;;의 이미지

creativeidler wrote:
썬에서 제시한 Java Code Convention을 참조해 보시기 바랍니다. 아마도 현재 가장 널리 쓰이는 컨벤션일 것이고 다른 언어에도 많은 영향을 미치고 있습니다.

C를 자바가 같지 않은데 같이 쓴다면 그건 C와 자바의 차이를 무시하는격이 되겠지요..
제생각엔 C는 C답게 쓰는것이 좋습니다.차라리
표준C함수들의 네이밍을 보시고 하시는게 훨씬 자연스럽습니다.
써보면 어느정도 이유도 있구요..
또한 C를쓰는 사람이면 C표준함수들을 당연히 많이쓰고 익숙할것이니 누가봐도 얼마나 편할지는 말할필요가 없겠죠..


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

Prentice의 이미지

http://bbs.kldp.org/viewtopic.php?t=51271#259592

원조 Apps Hungarian은 그런 것 만은 아니라고 합니다.

creativeidler의 이미지

Quote:
C를 자바가 같지 않은데 같이 쓴다면 그건 C와 자바의 차이를 무시하는격이 되겠지요..
제생각엔 C는 C답게 쓰는것이 좋습니다.차라리
표준C함수들의 네이밍을 보시고 하시는게 훨씬 자연스럽습니다.
써보면 어느정도 이유도 있구요..
또한 C를쓰는 사람이면 C표준함수들을 당연히 많이쓰고 익숙할것이니 누가봐도 얼마나 편할지는 말할필요가 없겠죠..

전 C에서 Java Code Convention을 그대로 따르라고 한 적은 없습니다. 그저 code convention 관련 문서로 정리가 잘 되어 있는 문서이기에 참고해보면 좋으리라는 것을 말한 것 뿐입니다.

그러나...

C답게..라는 것에는 이의를 제기하고 싶습니다. 무엇이 C답게인가요? 자바와 C는 문법상 많은 유사성을 갖고 있는데 자바에서 좋은 컨벤션이 갑자기 C로 오면 안 좋은 컨벤션이 될 이유는 없습니다. 소위 말하는 C 컨벤션은 사실상 코드 컨벤션에 대한 고민이 별로 없던 시절에 만들어진 것이라는 점을 염두에 둬야 할 것입니다.

그리고, 최근 C++ 계열에서는 자바 코드 컨벤션을 적극적으로 흡수해서 쓰고 있습니다. 파이썬도 처음에는 언더스코어(_)를 쓰다가 점점 camelCase를 쓰고 있고 C#도 마찬가지죠. Pascal은 원래부터 camelCase를 많이 썼구요. 범세계적이고 범언어적인 추세라 해도 과언이 아닐 겁니다.

ㅡ,.ㅡ;;의 이미지

creativeidler wrote:
Quote:
C를 자바가 같지 않은데 같이 쓴다면 그건 C와 자바의 차이를 무시하는격이 되겠지요..
제생각엔 C는 C답게 쓰는것이 좋습니다.차라리
표준C함수들의 네이밍을 보시고 하시는게 훨씬 자연스럽습니다.
써보면 어느정도 이유도 있구요..
또한 C를쓰는 사람이면 C표준함수들을 당연히 많이쓰고 익숙할것이니 누가봐도 얼마나 편할지는 말할필요가 없겠죠..

전 C에서 Java Code Convention을 그대로 따르라고 한 적은 없습니다. 그저 code convention 관련 문서로 정리가 잘 되어 있는 문서이기에 참고해보면 좋으리라는 것을 말한 것 뿐입니다.


그게 암묵적으로 사실상 따르라는말같이 들리더군요...
Quote:

그러나...

C답게..라는 것에는 이의를 제기하고 싶습니다. 무엇이 C답게인가요? 자바와 C는 문법상 많은 유사성을 갖고 있는데 자바에서 좋은 컨벤션이 갑자기 C로 오면 안 좋은 컨벤션이 될 이유는 없습니다.


안좋은것이 많습니다.
Quote:

소위 말하는 C 컨벤션은 사실상 코드 컨벤션에 대한 고민이 별로 없던 시절에 만들어진 것이라는 점을 염두에 둬야 할 것입니다.

바로 그러한것들도 이유가 될수 있겠죠..
그리고 고민이 없었던건아닙니다 그리고 사람들이 C코딩하면서 자바보다 더많은 고민을 했으면 했지 적게하진 않았을걸요..
Quote:

그리고, 최근 C++ 계열에서는 자바 코드 컨벤션을 적극적으로 흡수해서 쓰고 있습니다.


C와 C++은 많이 틀리죠..제가볼때 C++과 자바가 훨씬 가깝다고 생각되는군요..
말하자면 C++은 손목시계에 전자계산기기능을 넣어두고
계산기와 가깝다고 생각하면 안되죠..또한 동일한기능의 계산을 해날수 있다하여 수퍼에쓰는 계산기보다 낫다고 할수도 없는것이죠..
Quote:

파이썬도 처음에는 언더스코어(_)를 쓰다가 점점 camelCase를 쓰고 있고 C#도 마찬가지죠. Pascal은 원래부터 camelCase를 많이 썼구요. 범세계적이고 범언어적인 추세라 해도 과언이 아닐 겁니다.

추세를따라가기만한다면 세상에 바뀔것은 없겠죠..
그리고 그게 범세계적이라고 생각하지도 않습니다.

그에대해 한마디하면 C의 특징을 보면 아직도 많은 사람들이 vi 에서 작업하는경우가많고
어쩔수 없이 vi로 소스를 분석하거나 간단히 수정작업을 하는경우에는 매우편리하게 사용
하는경우입니다. 이때에도 많일 변수명이 길다거나 한다면
한화면에 나오는 내용이 그만큼 줄어들며 따라서 분석하기 힘들어지고
또한 그변수를 외워 다른곳에 타이핑하기또한 곤란하게 됩니다.
따라서 변수명은 간단하며 눈으로 외우기 편리해야하는데 그러기위해서는 눈에 직관적으로
들어와야겠지요.. 과연 camelCase가 눈에 잘띌까요 _가눈에 잘띌까요..
또한 실상은 _를쓰지 않고 camelCase로 구분함으로써 더짧은 네이밍이 되지 않을까 생각하지만
잘생각해보면 그런것도 아닙니다.
camelCase를 쓴다는건 어떠한단어의 조합을 쓰되 첫글자를 대문자로 구분하려는 의도이고
그러기위해선 첫머리글자만 딴다는건 좀의미없는일이 되겠지요..그렇게되면 대문자들이
줄줄이 나오게되니까. 따라서 한단어에 최소 몇글자를 할당하든지 아니면 온전한단어로
써야하게되겠지요.. 그렇기때문에 실상은 줄어드는것이 아니라 오히려 아주길어지게 됩니다.
실제로 이런류의 코딩들을보면 네이밍이 아주길다는걸 알수 있습니다.
따라서 결과적으로 이러한것은 언어와 환경에따라 분명히 차이가 있다고 볼수 있겠죠.


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

creativeidler의 이미지

Quote:
안좋은것이 많습니다.

이런 주장은 구체적인 예가 필요하지 않을까요?

Quote:
사람들이 C코딩하면서 자바보다 더많은 고민을 했으면 했지 적게하진 않았을걸요..

과거의 고민은 쌓여서 현재의 고민에 영향을 미치게 된답니다. C에서의 고민들은 자바의 재산이기도 하지요. 그 고민들을 했던 사람들이 자바 컨벤션을 만든 것이랍니다.

실례가 될지 모르겠습니다만 ㅡ.ㅡ;;님의 camelCase에 대한 생각, 네이밍에 대한 생각을 볼 때 camelCase로 코딩해본 적이 거의 없을 뿐더러 객체지향 언어로 뭔가 큰 프로젝트를 해본 적도 없고 뿐만 아니라 C로도 production 환경에서 대규모 프로젝트를 해본 적이 없는 것 같아 보입니다. 좀더 경험해보시면 생각이 많이 달라질 것입니다.

혹시 예측이 틀렸다면 미리 사죄드립니다..

kslee80의 이미지

C 에서라면 OO 언어들이 많이 채용한 방식보다는
GNU Coding Standards 가 더 나을지도...

http://www.gnu.org/prep/standards/

ㅡ,.ㅡ;;의 이미지

creativeidler wrote:
Quote:
안좋은것이 많습니다.

이런 주장은 구체적인 예가 필요하지 않을까요?
Quote:
사람들이 C코딩하면서 자바보다 더많은 고민을 했으면 했지 적게하진 않았을걸요..

과거의 고민은 쌓여서 현재의 고민에 영향을 미치게 된답니다. C에서의 고민들은 자바의 재산이기도 하지요. 그 고민들을 했던 사람들이 자바 컨벤션을 만든 것이랍니다.

실례가 될지 모르겠습니다만 ㅡ.ㅡ;;님의 camelCase에 대한 생각, 네이밍에 대한 생각을 볼 때 camelCase로 코딩해본 적이 거의 없을 뿐더러 객체지향 언어로 뭔가 큰 프로젝트를 해본 적도 없고 뿐만 아니라 C로도 production 환경에서 대규모 프로젝트를 해본 적이 없는 것 같아 보입니다. 좀더 경험해보시면 생각이 많이 달라질 것입니다.

혹시 예측이 틀렸다면 미리 사죄드립니다..

구체적인 예는 바로 아래나왔었고
...해서고민한것이 자바재산이고 그고민을 했던사람이 자바컨벤션을 만든것이라고말한다면.... 그컨벤션을 읽어보고 써본사람이 사람들이 C에 부적합한부분이 있다고 말하는것이라고 말할수도 있겠지요..
그리고 아랫쪽에 말씀하신 ...코딩해본적이 없다고 말하시는부분은.. 그저 아무근거도 없이 상대를 넘겨짚기 할뿐입니다.
보통은 그다지 좋은대화법이 아니라고 생각합니다.
그에대해 한가지 제가 되묻자면.. 님이 생각하시는 큰프로젝트란
어느정도의 프로젝트를 말씀하시는지..그기준을 말씀하시면 제가
답해드릴수 있습니다. 주로투입되는프로젝트가 대부분대기업프로젝튼데 전님이 어느정도프로젝트를 대형프로젝트라고 말씀하시는지 알수가 없군요..


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

creativeidler의 이미지

근거 없이 넘겨 짚은 것은 아닙니다만 예측이 틀렸다면 사과드립니다. 굳이 예측의 근거를 말하라면 camelCase 사용 경험이 별로 없다고 예측한 것은 camelCase가 머리글자를 딴 조합도 많이 쓰고 있다는 점을 몰랐고 camelCase에 익숙하다면underscore나 camelCase나 인식에 있어서는 비슷한데 그런 질문을 던진 것은 익숙하지 않기 때문이라고 보았기 ㅤㄸㅒㅤ문입니다.
OOP에 대한 사용 경험이 부족하다고 예측했던 점은 변수명이 길어진다고 한 화면에 보는 내용이 줄어들어 이해에 장애가 된다고 한 것, 그리고 변수명을 외워서 다른 곳에 쓴다고 한 것 때문입니다. OOP 언어는 대부분 IDE가 있기 때문에 변수명을 외워야할 걱정 같은 건 잘 안하죠. 게다가 어차피 API를 보고 작업하기 때문에 무언가의 이름을 외워야할 중요성보다는 그 이름이 대상의 역할을 정확히 묘사하는 것이 더 중요합니다. 어쨋든 여기까지는 제 예측이 그리 틀리지 않지 않은가요?
대규모 프로젝트라는 말로 의도했던 것은 얼굴 맞대고 하는 직접적인 의사소통만으로 모든 의사소통 욕구가 해소되지 않는 정도의 상황을 의도한 것이었습니다. 상황에 따라 다르지만 보통 10명만 넘어가면 그런 상황이 되죠.그런 상황이라면 긴 네이밍에 대한 거부감을 갖지 않으리라 생각했거든요. 근데 사실 이건 이론이 분분한 부분이니 실상 제 예측이 좀 무리했던 것 같습니다.

그리고, 또 한 가지, 결론이 좀 이상한데, 언어와 환경에 따라 달라진다고 하셨지만 실상 camelCase의 단점이라고 언급하신 것들은 특별히 C라서 그런 거라고 보기는 힘들죠. 굳이 말하자면 vi라서 그럴 수는 있겠지만 C도 좋은 IDE가 많은 마당에 꼭 vi를 쓸 때만 문제가 될 가능성이 있는 부분을 이야기하는 것이 언어에 따라 달라진다는 말에 힘을 실어주진 못합니다. 구체적인 예가 필요하다고 한 것은 그 주장들이 C답게...에 힘을 실어주는 예는 아니기 때문입니다.

죠커의 이미지

creativeidler wrote:
근거 없이 넘겨 짚은 것은 아닙니다만 예측이 틀렸다면 사과드립니다. 굳이 예측의 근거를 말하라면 camelCase 사용 경험이 별로 없다고 예측한 것은 camelCase가 머리글자를 딴 조합도 많이 쓰고 있다는 점을 몰랐고 camelCase에 익숙하다면underscore나 camelCase나 인식에 있어서는 비슷한데 그런 질문을 던진 것은 익숙하지 않기 때문이라고 보았기 ㅤㄸㅒㅤ문입니다.

original wiki나 정해진 coding convention때문에 camelCase을 더 많이 사용하고 있지만 딱 한 눈에 보았을때 눈에 잘 들어오는 것은 underscore더군요. 얼핏 보면 underscore가 그냥 공백 처럼 보이기 때문에 가독성을 높여주는 것 같습니다.

하지만 _를 누르는게 철자 하나 쉬프트 누르는 것보다 귀찮기 ㅤㄸㅒㅤ문에 별 군소리 없이 쓰는 편입니다. 사실 space 하나 더 누르기도 귀찮은데 변수명을 적을 때마다 _를 누르는 것도 조금 귀찮습니다.

ㅡ,.ㅡ;;의 이미지

creativeidler wrote:
근거 없이 넘겨 짚은 것은 아닙니다만 예측이 틀렸다면 사과드립니다. 굳이 예측의 근거를 말하라면 camelCase 사용 경험이 별로 없다고 예측한 것은 camelCase가 머리글자를 딴 조합도 많이 쓰고 있다는 점을 몰랐고 camelCase에 익숙하다면underscore나 camelCase나 인식에 있어서는 비슷한데 그런 질문을 던진 것은 익숙하지 않기 때문이라고 보았기 ㅤㄸㅒㅤ문입니다.
그건좀좀 어이없는..
Quote:

OOP에 대한 사용 경험이 부족하다고 예측했던 점은 변수명이 길어진다고 한 화면에 보는 내용이 줄어들어 이해에 장애가 된다고 한 것, 그리고 변수명을 외워서 다른 곳에 쓴다고 한 것 때문입니다. OOP 언어는 대부분 IDE가 있기 때문에 변수명을 외워야할 걱정 같은 건 잘 안하죠.
그러니까 제가 말했듯이 언어나 환경에따라 차이가 있다고 말한거죠..
바로 그러한차이가 스타일의 차이가 발생한다는말이고 그중 C는 C답게라고 한겁니다.
Quote:
게다가 어차피 API를 보고 작업하기 때문에 무언가의 이름을 외워야할 중요성보다는 그 이름이 대상의 역할을 정확히 묘사하는 것이 더 중요합니다. 어쨋든 여기까지는 제 예측이 그리 틀리지 않지 않은가요?

하나만고려하기보다 여러가지를 모두 고려한다면 더욱좋죠
Quote:

대규모 프로젝트라는 말로 의도했던 것은 얼굴 맞대고 하는 직접적인 의사소통만으로 모든 의사소통 욕구가 해소되지 않는 정도의 상황을 의도한 것이었습니다. 상황에 따라 다르지만 보통 10명만 넘어가면 그런 상황이 되죠.

의외군요.. 10명이상이면 대형프로젝트라니.. 대형프로젝트가 아닌것이 극히 드물정도군요..
Quote:

그런 상황이라면 긴 네이밍에 대한 거부감을 갖지 않으리라 생각했거든요. 근데 사실 이건 이론이 분분한 부분이니 실상 제 예측이 좀 무리했던 것 같습니다.

그리고, 또 한 가지, 결론이 좀 이상한데, 언어와 환경에 따라 달라진다고 하셨지만 실상 camelCase의 단점이라고 언급하신 것들은 특별히 C라서 그런 거라고 보기는 힘들죠. 굳이 말하자면 vi라서 그럴 수는 있겠지만 C도 좋은 IDE가 많은 마당에 꼭 vi를 쓸 때만 문제가 될 가능성이 있는 부분을 이야기하는 것이 언어에 따라 달라진다는 말에 힘을 실어주진 못합니다. 구체적인 예가 필요하다고 한 것은 그 주장들이 C답게...에 힘을 실어주는 예는 아니기 때문입니다.


언어에따라 사용하는툴등 차이가 많이 나죠..
사용툴이 달라지면 편리한 코딩스타일도당연히 틀려지는건 당연한이치겠지요.
마치 자동차의 엔진이나 비행기 엔진이나 오토바이 엔진이나
그기능과 용도 형태에따라 더욱적합한엔진이 필요하듯이
더욱적합한것이 필요하기 마련이지요..
당연히 언어의 특징 어떤환경적인 차이는 어떤코딩스타일이 유리한지 생각해보면 나오겠지요..그한예로 vi 를 들었을뿐입니다.
다른것도 무수히 많겠지요..또예를 들어볼까요.. C에는 포인터가있고 자바에는 없습니다. 그렇다면 이것이 네이밍과는 어떤관련이 있을지 생각해보신적 있으신지.. 포인터는 단지 *로 표시됩니다.그러나 이것의 중요도는 매우크다는걸 잘아실겁니다.그렇다면 그렇게 중요한 (표시?)가 상대적으로 덜중요한 변수명에비해 아주 작게 할당된다면 이는분명 *를 잘안보이게 혹은 변수명들의 홍수속에 묻혀지게 만들게되겠지요..
따라서 상대적으로 변수명이 길면 불리하다는결론이지요.
직접볼까요?

char c, *cp;

char djWjrhwjWjdgkgkgk, *Rflsmsalswnrsnd;

분명 포인터의 구분은 눈에 상대적으로 후자가 눈에 잘안띈다는건 부인할수 없겠죠..
그외에도 수없이 많습니다. 언어적인특징 틀린점모두가 되겠지요
그리고 개발환경적인차이도...그래서 언어마다 스타일이 다른데 궂이 한가지 스타일을 억지로 끼워맞추어 강요하는건
잘못됬다고 보는거죠..


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

creativeidler의 이미지

굳이 의미 없는 알파벳의 연속으로 대비를 시키니까 그렇죠-_-

char c, *cp;

char character, *stringBuffer, *nameOfFriends;

눈에 잘 띄는 것 같은데요? 사실 위의 님의 예도 전 포인터가 눈에 잘 들어왔는데.. 상대적이라는 건 여기서는 큰 의미가 없죠. 어차피 일정 수준 이상의 인식력만 확보하면 다른 장단점들이 있기 때문에 이거 하나가 결정적이 요소가 되진 않으니까요.

그리고 네이밍에서 초점은 저런 instant variable보다는 여러 곳에서 쓰이는 function, struct 등에 있습니다. 자바나 C++라면 클래스명, 멤버 변수명, 메쏘드명 등이죠. 그래서 다음과 같은 코드도 자연스럽게 씁니다.

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();

그런데 만약 c, cp 식으로 네이밍을 하면 다른 곳에서 그 변수를 쓸 때 대체 그게 뭔지 어떻게 알고 쓰겠습니까? 선언부까지 쫓아가서 어떤 값들이 할당되는지까지 뒤져봐야 겨우 그게 뭔지 알 수 있겠죠. 그런 식으로 프로그래밍을 한다면 소위 마틴 파울러가 말하는 "누구나 다 짤 수 있는 컴퓨터가 이해하는 코드"에서 머무를 뿐이고 "사람이 이해하는 코드"로 나가진 못합니다.

제가 굳이 ㅡ.ㅡ;;님의 경험에 대한 언급을 했던 것은 OOP에 대한 경험이 많은 사람들끼리는 이런 부분에 대해서 강한 공감대를 형성하고 있다고 보기 때문입니다. 딱히 이걸 어떤 설득의 근거로 활용하고픈 생각이 있었던 것은 아니고 님 역시 OOP에 대해 좀더 이해하게 되면 이 부분은 분명 생각이 바뀔 것이라고 보기 때문입니다.

그리고 대규모..에 대해 한 마디 하자면.. 제가 이 단어를 사용한 것이 조금 오버였던 것 같습니다. 원래 의도는 흔히 말하는 large scale이었습니다. 그대로 번역해도 같은 느낌은 안 나네요-_- not pilot project 정도의 의미라고 생각하시면 되겠습니다. 뭘 말하기 위해 이런 표현들을 쓰고 있는지는 아시리라 생각합니다.

어쨋든, remember & paste(?)의 문제는 vi이기 때문에 발생하는 문제이지 C만의 문제가 아니며, 포인터의 문제 역시 C++에도 똑같이 존재하고 Pascal에도 존재하는 문제인데 이 두 언어는 camelCase도 많이 쓰고 long naming에 대해 호의적이기 때문에 C에서 camelCase나 long naming이 나쁜 이유는 안되는 걸로 보입니다.

제가 보기엔 C답게...를 지지할만한 것은 레가시의 문제, 즉 기존 라이브러리가 underscore와 축약어를 많이 쓰는 네이밍을 채용하고 있다는 것 뿐인 듯 싶습니다. C 네이밍에서 가장 중요한 함수 명명과 구조체 명명에 있어서는 자바나 C++의 메쏘드 네이밍, 클래스 네이밍을 그대로 따라도 "C"라서 안 좋은 경우는 없다고 봐도 과언이 아닐 겁니다.

jjocbak의 이미지

espereto wrote:
제 경우는...
일단, 전역변수는 "절대 안 쓴다"라는 원칙을 세우고 작업합니다. 쓴다고 하면 const 변수인 경우만 한정해서 씁니다. (쓰레드 안전성과 그 외의 몇 가지 이유때문에)

quote]인용입니다.

jjocbak의 이미지

jjocbak wrote:
espereto wrote:
제 경우는...
일단, 전역변수는 "절대 안 쓴다"라는 원칙을 세우고 작업합니다. 쓴다고 하면 const 변수인 경우만 한정해서 씁니다. (쓰레드 안전성과 그 외의 몇 가지 이유때문에)

quote]인용입니다.

인용입니다.
htna의 이미지

저의 경우에는 전역변수를 종종 선언해서 사용하고 있습니다.
주로 테스트 코드 작성시에요..

class CClass {
    ....
};
#ifdef _DEBUG
class CTest_CClass {
public:
    CTest_CClass() {
        ....
    }
} __CTest_CClass;
#endif //_DEBUG

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

rain의 이미지

전 아직 까지도 경험의 단계에 있는 수준입니다.
단지 저의 성향은 이렇다라구 말하는 것으로 생각하고
적어 봅니다.

현재 가지고 있는 기준들은 이렇습니다.

1. 전역 변수는 절대 쓰지 않는다.
(그래도 선배들은 씁니다. ㅡㅡ;)

2. C++/Java는 SUN의 Java code convention을 따른다.
Template등을 사용할 땐...나름의...스타일로...^^;
(아직 까지 다른 객체지향은 제대로 해본적이 없습니다. C++/Java도 허접이지만..)

3. C code를 짤 때, 예전엔 GNU code standard를
따랐지만, 요즘엔 camelCase로 바뀌어 가고 있습니다.
- Struct
- Struct_Member
- int*
Prefix_DoSomething(int inValue, int* outValue)
- localValue
- if (1) {
}
- 한 파일의 내부에서만 쓰는 함수는 __LocalFunction()

4. 파일은 항상 대문자로 Main.c

요즘 쓰는 스타일을 적어보니
최근 같이 작업하는 일본 팀의 영향을 좀 받은 듯 하네요. ^^;
같이 작업하는 일본 팀의 코드가 이제 껏 봐온 코드 중에서
가장 깔끔하게 coding한 코드 같더라구요.
자신들 만의 코드 convension을 철저하게 지키더군요.

세상에서 가장 이해하기 힘든 것은 내 자신이 그것을 이해할 수 있다는 것이다.
- 알베르트 아인슈타인 -

vacancy의 이미지

장모군의 이미지

그냥 소문자로만 간단하게 씁니다

1. 변수/함수에 대문자 쓰는거 증말 싫어염~~

2. TAB은 8

3. do_something (arguments), if (condition) , while (condition) { 처럼 ( 앞에서 한칸 뜁니다. ( 뒤말구..

4. 기타 등등..

uosarang의 이미지

ㅡ,.ㅡ님은 java code convention이랑 C랑 그다지 맞진 않다는 리플로 시작하셨는데

OOP얘기는 왜 나올까요....

머리를 굴려라! 그래야 먹고 산다.

머리를 굴려라! 그래야 먹고 산다.

라이프니츠의 이미지

논의가 대부분 앞글자를 대문자 혹은 소문자로 할거냐..아니면 언더스코어가 좋으냐 헝가리안 표기법은 왜 안좋냐..등의 겉보기 네이밍규칙을 말씀하고 계신데...그 레벨의 논의라면 상식수준에서 알아볼 수 있는 코딩 컨벤션 아무거나 하나만 정해서 "일관성 있게 하라"라고 하면 끝날 문제라고 봅니다만... -_-

그보다 더 중요한것은 해당 변수가 어떤 의미로 쓰였는지, 또 어떤 의도로 프로그래머가 그런 변수를 사용했는지..그리고 어떤 맥락에서 그 변수가 사용되고 있는지를 잘 보여줄 수 있는 이름을 쓰는게 아닐까요?

특히 저는 길고 딱딱하게 늘어뜨린 설명적인 이름보다는 간결하면서도 직관적으로 잘 이해되는 비유섞인 표현이 훨씬 보기 좋더군요. 실제 많은 C guru들이 여지껏 해 왔던짓이 그렇기도 했구요. 어떤 소스코드는 문학작품에 빗댄것도 있고... 그 머시냐..Bell lab의 Inferno 시스템은 아예 유명 작가의 지옥과 연옥 체계를 그대로 차용한것 같던데...-_-;;

코딩할때 실제 이렇게 이름을 지어봤는데..코딩자체가 무지 재밌더군요. 꼭 영화찍는 기분이 들어서..;;; 코드를 보는 사람도 이해가 쉽다고 하더군요. 그리고 무엇보다..메타포 자체가 설계를 함축하는 기능이 있기 때문에 저는 이런 기법을 즐겨 사용한답니다.

라이프니츠의 이미지

어느정도 여러분야에 대한 배경지식이 빠방하고... 영어 어휘력도 중급이상은 되어야 편하게 쓸 수 있는 방법이 아닐까 합니다...저도 이 방법을 쓰다가.. 사전 뒤적인적이 한두번이 아니었거든요. ;; 설계보다 변수 이름짓는데 머리를 쥐어짤줄은 꿈에도 몰랐죠...ㅋㅋ

bookgekgom의 이미지

잘은 모르곘지만 자바로 프로그램을 짜게 되면 클래스가 10개 혹은 막 늘어나니까요.

나중에 읽어도 알기쉽도록 변수명과 클래스 인스탠스 명을 말이 되게 합니다.

공을 움직이는 클래스를 만든다고 한다면 공클래스(public class Ball)를 만든후

그것을 나중에 사용할때

말이되게...

Ball myBall = new Ball(size, cost);

if(myFriend.isMyTeam)
myBall.passTo(myFriend);
else
myBall.keep();

나중에 읽어보면 "만약 내친구가 내팀이라면 내공을 친구에게 패스하고, 아니라면 가지고 있는다." 라고

읽을수있게 작성합니다.

그런데 씨쁠쁠에선 이게 약간 힘든게...헤더 파일이랑 나누어야되니까...ㅠㅠ 읽기도 힘들고..ㅠㅠ
----------------------------------------------------------------------------------------------------------------------
허접한 페도라 가이드 http://oniichan.shii.org

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

hirameki의 이미지

제가 가진 소견은 이렇습니다.
가장 기본적인 목표는 동시 작업을 하는 또는 후에 코드를 이어받을 사람들이 모두 공통으로 하는 룰에 최대한 근접시키는 것입니다.
(철저하게 지키다보면 오히려 예외상황에서 적절하지 못한 대처가 나올수 있기 때문에)

그래서 아래와 같이 케이스를 간단하게 나누어서 생각해보면 어떨까 싶습니다.
1. 특정 회사의 시스템 개발이나 그 회사의 프레임워크를 사용해서 개발하는 입장
-> 그 회사의 정해진 코딩 룰 또는 가장 주류의 코드를 보고 작성기준으로 삼는다.

2. 자유롭게 개발하는 입장.
-> 내 소스이므로 내마음이기는 하지만, 일단은 작성시 사용한 언어에서 주로 사용되는 룰을 하나 선택하고 따른다.

3. 오픈소스에 참여(이건 참여를 못하고 있어서 그냥 짐작입니다만... 저같으면 이렇게 하겠다 라는 것을 적어봅니다.)
-> 기존 소스의 흐름을 보고 흐름을 깨지 않도록 기존의 네이밍 룰을 준수한다.
특별히 정해져있지 않은 경우에는 기존 룰에서 좋지 않다고 생각되는 부분을 먼저 포럼 등에서 상의한 뒤 반영한다.

위의 2의 경우에 개인적인 의견으로는 대략 아래처럼 쓰고 있습니다.
(주로 자바쪽 룰에 가깝습니다. 아니 그냥 자바라고 생각하고 봐주세요. 직업이 직업이다보니 일할때는 다른 코딩룰에 따라가므로 일에서 쓰는경우는 드뭅니다.)

1. 객체이름의 경우에는 무엇을 목적으로 한 객체인지 축약형이 아닌 단어를 사용하여 작성한다.
축약되서 혼동되는 예> Prc -> Process? Procedure? ProC? Price?
축약할때 혼동되는 예> Order -> odr? ord?

2. 함수/메소드 이름의 경우에는 동사+명사(수행목적) 의 형태로 동사와 명사의 미묘한 뉘앙스에 주의하며 작성한다.
특정 값의 IO > getResult(), recieveExitCode(), retrieveAlertMailTemplate(), putStreamDataOfItems(), sendMail(), insertUserProfile()
*특정 기준은 아니지만 DB등의 데이터 저장소에 데이터를 넣을때는 insert/delete/update등을(파일이라도) 사용하는 편이고,
네트워크 통신으로 데이터를 보낼때는 send/recieve를 사용하는 편이며
메모리등 시스템 내부처리나 insert/delete보다 상위 레벨에서 크게 데이터의 보관/꺼내오기 등의 개념인 경우는 get/put을 쓰는 편입니다.
또 혼동하기 쉬운 free등은 release등으로 표현하는 경우도 있습니다.(메모리 개방 등에서)
특정 처리의 수행> excuteExternalCommand()
특정 처리 객체(비지니스 로직)의 생성 등> createBatchProcessSchedule()

3. 변수명에 대해서는 해당 함수 내에서 전체적으로 의미를 지니는 경우는 가능하면 축약하지 않은 1~2단어 내에서 작성한다.
또한, 고유명사/고유한 개념인 경우를 제외하고 기본적으로 영단어로 작성한다.
주민등록번호등 유저 등록번호 > RegistrationCode 또는 UserId
구분 > gubun(X), type / kind / class (경우에 따라 맞는 단어를 구분해서 사용)
단, for, while등에서 카운터로 사용하는 경우에는
- 단순 카운터는 상위에서부터 i, j, k, m, n (L은 다른 문자와 혼동되기 쉬우므로 사용하지 않음)의 순으로 사용(5단계까지 필요하면 로직 개선 또는 하위 함수작성 검토 필요)
- 비지니스 로직적으로 의미가 부여되어야 알기 쉬운 경우는 축약하지 않은 한단어로 사용.

이 정도네요. :D

--

LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Hirameki --X-
Mail : hirafilter-comunity@yahoo.co.kr
그외 비밀..
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

--

LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Hirameki --X-
Mail : hirameki_krjp@yahoo.co.jp
God is not customer center. Do it yourself
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

pinebud의 이미지

리눅스 커널처럼.. 은 어떨까요?
리눅스 커널처럼 고치기 쉽고 읽기 쉬운 코드가 없는 것 같습니다. 한가지 일을 하는 함수는 딱 한개만 있고 파일을 나누는 방법이나 헤더 구성도 복잡하구요. 가끔은 indentation의 미학같은 것도 느낄수 있습니다. 디버그 프린트의 포인트나 커멘트를 배우기도 좋은 것 같습니다. 매크로 정의해가면서 최소의 코드만 고치기 논리 게임같은 것도 재미있구요. 커널에다 코드를 넣거나 새로 파일을 넣으면서 이정도면 고친 티가 안나겠지 싶을때 기분이 좋아집니다.

A rose is a rose is a rose..

레모네이드의 이미지

주석

/* file header **************************************************************************************************************************************
 
    copyright: Future Man Electronics
    created  : %DATE%
    created  : %DAY%:%MONTH%:%YEAR%   %HOUR%:%MINUTE%
    filename : %FILE%
    file path: %FILE_PATH%
    file base: %FILE_BASE%
    file ext : %FILE_EXT%
    author   : Yong-Woo,Lee
 
    purpose  : ?
 
****************************************************************************************************************************************************/
 
 
 
 
/* 중간 주석 ,  at 2008-4-22 17:43:12, by Lemonade */
 
/*
	c++의 주석은 /**/ 방식과 // 방식 두가지가 존재한다.
 
	소스코드 사이에 주석을 삽입할때는 이 두가지 방식의 주석에 대하여 다른 용도로 사용한다.
 
	/**/ 는 일반적인 주석을 달때 사용한다.
 
	// 는 일부 실행코드를 주석처리하여 잠시 사용하지 아니하고자 할때 사용한다.
 
	at 2008-4-22 17:43:12, by Lemonade
*/
 
 
/****************************************************************************************************************************************************
*   Log                                                                                                                                             *
****************************************************************************************************************************************************/
 
// 2008-5-2 16:40:51 Lemonade: 작성을 시작하다.
 
// 2008-11-12 15:37:27 Lemonade: add(int,char*) 함수를 추가
 
// 2008-11-12 15:37:36 Lemonade:
//     Commit. 이 문서에 대하여 더이상 수정을 금함. 
//     
//     추가 기능 요구시 다음의 방법중 하나를 사용할 것을 권함
//        1. 상속하여 기능 추가
//        2. 새로운 버젼의 문서로 변경.

네이밍

C++에서 네이밍하여야 할것들은 다음과 같이 존재한다.
 
파일명,지역변수,전역변수,멤버변수,상수,함수,네임스페이스명,클래스,구조체,전처리선언
 
 
1. 파일명
 
	클래스 문서를 작성하는 경우 클래스의 이름과 같은 이름을 사용한다.
 
	소스 파일의 확장자는 cpp를 사용한다.
	헤더 파일의 확장자는 h를 사용한다.
	템플릿클래스 구현 파일의 확장자는 hpp를 사용하며, 템플릿 클래스의 선언파일 .h에서 .hpp를 include하는 것으로 한다.
 
2. 변수
	모든 변수는 모두 소문자를 사용하며 단수 명사형을 사용한다. 단어의 구분은 _(underline)을 사용한다.
 
	지역변수는 약어를 만들어 사용할 수 있으며, 이때에 변수 선언부에서는 풀네임을 주석으로 표기한다.
 
	전역변수는 약어를 사용할 수 없으며, 헝가리안 표기법의 접두사 규칙에 따라 g_ 를 붙이도록한다.
 
	클래스의 멤버 변수는 약어를 사용할 수 없으며, 헝가리안 표기법의 접두사 규칙에 따라 m_를 붙이도록한다.
 
	포인터 변수는 p_ 접두사를 붙이도록한다. 전역포인터는 gp_ , 멤버포인터는 mp_ 를 붙이며,
	포인터의 깊이에 따라 p의 갯수를 늘리도록한다. ex> int** pp_mypointer; char** gpp_ap;
 
	예외적으로 배열이나 stl의 컨테이너클래스의 변수는 포인터명과 같은 별도의 접두사를 사용하지 않으나,
	단어의 명칭상에서 복수형으로 사용한다.
 
	함수나 메서드의 파라미터는 in_ / out_ / io_ 접두사를 사용한다. 만약 포인터일 경우에는
	pin_ / pout_ / pio_ 와 같은 형식을 사용한다.
 
3. 상수
	모든 상수는 모두 소문자를 사용하며 단수 명사형을 사용한다. 단어의 구분은  _(underline)을 사용한다.
 
	약어를 사용할 수 없으며, c_ 접두사를 사용하도록 한다.
 
	예외적으로 문자열상수의 경우 str_ 접두사를 허용한다.
 
3. 함수
	모든 함수는 모두 소문자를 사용하며 항상 동사로 시작한다. 단어의 구분은 _(underline)을 사용한다.
 
	에러 리턴 프로시저를 작성하는 경우에는 eproc_ 접두사를 사용한다.
 
	예외적으로 어떤 수학적 함수 이름에는 명사를 사용할 수 있다.
 
4. 네임스페이스
	네임스페이스명은 일반적인 도서의 타이틀 명명법과 같이 한다.
	즉, 단어의 첫머리는 대문자로 시작하고 단어의 구분은 _(underline)을 사용한다.
	예외적으로 전치사는 소문자로 사용한다.
 
5. 클래스와 구조체
	클래스의 이름은 그 성격에 따라 class_, abstract_,proxy_, stub_ 등과 같은 접두사를 사용한다.
	구조체의 이름은 struct_ , interface_ 등과 같은 접두사를 사용한다.
	모든 단어는 소문자를 사용하며, _ 를 사용하여 단어를 구분한다.
	_v1 , _v2 와 같은 버젼 접미사를 사용할 수 있다.
	이때에 클래스의 파일명은 사용된 클래스의 풀네임을 사용하도록 한다.
 
6. 전처리선언
	모든 전처리 선언은 기존의 방식대로 대문자로 사용하며, 단어의 구분은 _(underline)을 사용한다.

줄맞춤

1. Tab 삽입은 공백 4개를 삽입한다.
   이것은 일반적으로 다른 사람의 편집기나 다른 종류의 워드프로세서로 코드를 옮길때 코딩 규칙의 깨짐을 방지한다.
 
2. {} 중괄호의 사용은 깃발 규칙을 사용한다.
 
	void main()
	{
		if(...)
		{
			//지역변수 구분짓기위해
			{
			}
		}
	}
 
   단, 예외적으로 네임스페이스의 영역 설정을 위한 중괄호는 깃발 규칙을 따르지 아니하고 한줄에 모두 사용한다.
 
	1  : namespace Nerv { namespace General { namespace Center {
	2  :
	...:
	100: } using namespace Center; } using namespace General; } using namespace Nerv;
 
3. 네임스페이스 양식은 헤더파일과 소스파일의 양식을 다르게 한다.
 
	헤더파일의 경우
 
/***************************************************************************************************************************************************/
#ifndef Define__Nerv__General__Center__main_h
#define Define__Nerv__General__Center__main_h
namespace Nerv { namespace General { namespace Center {
/***************************************************************************************************************************************************/
 
    int main(int argc, char* argv[]);
    int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance, LPTSTR    lpCmdLine, int nCmdShow);
 
/***************************************************************************************************************************************************/
} using namespace Center; } using namespace General; } using namespace Nerv;
#endif // Define__Nerv__General__Center__main_h
/***************************************************************************************************************************************************/
 
	이와 같이 네임스페이스 사용전에 헤더 중복 include를 방지하기 위한 구문을 먼저 사용하고
	그 다음에 네임스페이스를 지정하며
	함수나 전역변수 클래스등의 선언에는 1 tab 을 들여쓰기 한다.
	마지막에 네임스페이스 구역을 닫고,
	헤더 중복 include의 종료 구문을 삽입한다.
 
	using namespace를 미리 사용함으로써 소스작성을 편리하게끔 한다.
 
	소스파일의 경우 일반적으로 네임스페이스를 지정하지 아니한다. (헤더에서 이미 using namespace를 사용하였기 때문에)
	그러나 예외적으로 필요하다면 (일반적으로 전역 함수 작성시에) 다음과 같이 사용한다.
 
/***************************************************************************************************************************************************/
namespace Nerv { namespace General { namespace Center {
/***************************************************************************************************************************************************/
 
int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance, LPTSTR    lpCmdLine, int nCmdShow)
{
 
 
}
 
/***************************************************************************************************************************************************/
} } } // namespace Nerv { namespace General { namespace Center {;
/***************************************************************************************************************************************************/
 

저장소 규칙

1. 모든 소스는 한 디렉토리의 아래에서 관리한다.
 
2. 디렉토리의 이름은 네임스페이스와 일치시킨다.
   (즉 첫단어 대문자, 전치사는 소문자 공백은 _ 로 처리하는 규칙)
 
3. 소스와 makefile의 저장소는 분리한다.
 
4. 다음과 같은 디렉토리 구조를 유지한다.
 
 
	Dev(최상위)
		Bin(실행파일 임시저장소)
		Build(makefile 저장소)
		Src(각종 라이브러리 및 소스파일 저장소)
 
5. 일반적으로 Build, Bin, Src 아래의 디렉토리 구조는 동일한 이름에 같은
   구조로 하위 디렉토리를 유사하게 구성하게 되어야 한다.
 
6. 전역 네임스페이스는 결코 사용하지 아니한다.

이대로 코딩하는데 코드 짤때 엄청 빡셈니다. 근데 나중에 볼때는 편하더군요..
Win API의 헝가리안 표기와 코드상 혼용되는데...Win API호출함수로 구분이 갑니다...
단, Win API의 구조체들이 대문자로 되어 있어서 #define 상수와 혼동되기도 합니다...
많은 곳에서 위와 비슷한 저장소 규칙을 사용하는데 코드의 재사용성이 확실히 높습니다.
단점으로, 하나의 코드를 수정하면 많은 프로젝트에 문제가 발생하는데 잠재적인 문제를 일괄 빌드 단계에서 찾아낼수 있는 장점으로 작용하기도 합니다.
마지막 단점, 규칙이 있어도 선수들이 귀차니즘으로 안지킬때가 많습니다..

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.