프로그래밍 이름짓기, 클래스명, 함수명 변수명 관련

 

 

 

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

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

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

 

 

 

 

 

 

출처: http://www.joinc.co.kr/w/Site/Development/Env/Prog_rule





아무래도 네이밍 규칙정도는 좀 정리를 해놔야하지 싶다. 이대로 따르지는 힘들겠지만 따를려고 노력해야 겠다. 기본룰이 없으니 프로젝트마다 네이밍 룰이 제각각이고 동일한 프로젝트에서도 중구난방이니 코드보기가 여엉 괴로운거 같다.


 
세부적으로 조정하기는 귀찮고, 중요한것들만 좀 정의해볼 생각이다. 헝가리안 표기법 그런거에 따로 신경쓰지는 않을련다.

명명 일반 규칙
{동사/형용사}{목적어}

getIteratorNext
getDeviceName
videoSetProperty
videoGetProperty
파일
파일명 : 단어 첫글자를 대문자로 한다.
NetworkProxy.cc, XmlParser.cc
Proxy.hpp
확장자
C : .c
CC : .cc
C Header : .h
CC Header : .hpp
클래스 & 구조체
클래스명 : 단어 첫글자를 대문자로 한다.
MultiParser, Object, NetworkProxy
접두사 규칙 : 팀이니셜혹은 다른 은유어들, 2자를 넘지 않도록
MuNetworkProxy, MuFormBuilder
메서드명 : 단어 첫글자를 소문자로 한다.
initParser, tcpConnector
멤버변수 : m_ 으로 시작한다.
m_clientConnector, m_fd
일반함수명
첫글자는 소문자로 한다.
getCurrentTime
변수명
지역변수 : 변수명 첫글자는 소문자로 한다.
userName, cpuInfo
전역변수 : g_ 로 시작한다.
g_maxLine
루프변수 : 가능한 루프의 루프를 지양해야겠지만 어쩔수 없는 경우도 있겠는데, i, j, k는 왠지 헛갈린다. 잘못써서 버그 생기는 경우도 있고.
iCount, jCount : Count를 붙여줘서 좀 명확해지기는 했는데, i와 j가 여전히 쓰이니 좀 불만이긴 하다. 좀 다른 방법 없을려나 ?
리스트인 경우 : 접미사 List를 붙여준다.
nameList, nodeList
블럭 및 줄맞추기
들여쓰기 : tab (출력시 tab size는 4로)
블럭 괄호 사용 : 하나의 라인을 차지하도록 했다.
개인적으로 함수옆에서 블럭이 시작되면, 블럭영역이 눈에 잘 보이지 않더라는.
하는일에 따른 명명 규칙
함수명
값의 초기화 : 접두사 init 를 붙인다.
initXmlParser, initThreadPool
값의 설정 : 접두사 set 을 붙인다.
setTimer, setNodeName
값얻어오기 : 접두사 get 을 붙인다.
getTime, getNodeName
값의 추가 : 배열등에 값을 넣을때. 접두사 push
pushItem, pushNode
값빼오기 : 배열등에서 값을 빼올때. 접두사 pop
popItem, popNode
생성 : create
createUserObject, createFile
열기 : open
openXMLFile, openImage
닫기 : close
closeXMLFile, closeImage
주석
표준포멧으로 주석을 작성하고 변환툴을 이용해서 문서화를 해버리는 방법도 생각했지만.. 너무.. 너무 귀찮다. 그래서 나름 간단 포맷을 정해버렸다. 복잡하면 있어보이기는 하는데, 사용하지 못할 복잡함이란건 의미가 없어 보여서.
그리고 영어 사전
워낙 영어맹이라서 함수명등을 제대로 만들려면 반드시 필요한게 영어 사전이다. 구분을 gubun으로 하기는 좀 그렇지 않은가.

 

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

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

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

 

 

 

출처: http://cie.kunsan.ac.kr/programmer/3981



시작하기전에..

가끔 친구들에게

"야 이거 왜안되냐?" 라는 요청을 받습니다.

그래서 간혹 질문한 코드를 보면 이게 뭐하는 함수인지, 뭐하는 변수인지 햇갈리게 지어서

저도 왜 이렇게 되는지 햇갈리는 경우가 더러 있습니다.



그래서 이번에는 어떻게 하면 변수이름과 함수이름을 잘짓는지 알려드릴까 합니다.



변수나 함수의 이름 짓는법은 딱히 정해진것은 없습니다.

하지만 보통 헝가리안 표기법을 지키시면 좋습니다.



헝가리안 표기법이란?

변수앞에 자료형의 접두어를 붙혀서 만드는 표기법 입니다.



자료형

접두어

사용예
 바이트

b

bData 

bool

is

isOn 

 int

i

iCount 

 long

l

lTotal

 short

s

sWidth

 double

d

dPi

 float

f

 fPi

 문자열

str

strFileName 

 객체

객체접두어

gvtThread 


물론 이것 말고도 더많습니다. ㅎㅎ

그건 더 찾아서 사용하시면 됩니다. 물론 자기만의

표기법이 있으면 그걸 사용하시는것도 좋습니다.



저같은 경우에는 헝가리안 표기법도 사용하지만,

영어단어로 변수를 서술하는 방식도 사용합니다.

또, 첫어절은 변수이름이 이상하지 않는이상 소문자로작성하고,

이 변수가 어떤 용도인지를 적습니다.(arr라든가 str이가든가 tmp라든가...).



예를들어서

int sizeOfRectanle;

DType whatIsDataType;

OPin whoIsWinner;



이런식으로 sizeOfRectagle은 사각형의 크기를 나타내는 변수.

whatIsDataType은 어떤 데이터 타입인지 저장한 변수.

whoIsWinner는 누가 이겼는지 저장한변수.

이렇게 됩니다.

 

반응형

 

728x90

추천 하지는 않지만 _변수명 이런식으로 작명하기도 합니다.

추천하지 않는 이유는 특정 언어에서는 기능이 전혀 다르게 수행 되기 때문입니다.

특히 Obj-C에서 변수 앞에 _을 붙히면 weak reference변수가 되기때문입니다.(보통은 strong reference)



변수 이름 짓는법은 알았는데 이제 함수 이름짓는법도 알아야죠?



함수 이름짓는법 역시 변수 이름짓는법과 다르지는 않습니다.

다만 함수는 접두어를 동사로 적는것입니다.



제가 자주 사용했던 대표적인 접두어를 보겠습니다.

물론 별거 없습니다. 그냥 상황에 맞게 적어주면 됩니다.

또한, 변수와 마찬가지로 접두어는 함수명이 이상해지지 않는한 무조건 소문자로 씁니다.



get-, extract-, read- : 반환값이 있다. 즉, 함수가 무엇인가 나오거나 추출되어지는 기능이다.

save-, write- : 무엇인가를 저장하거나 기록한다.

input- : 입력받는다.

init- : 무엇인가를 초기화 하는 동작을 하는 함수이다.

is- : 단순 부울 값이 나온다.

do- : 뭔지는 모르겠는데, 아무튼 뭘한다.... (응? ㅡ.,ㅡ)



예를들어

getDataFromFile

saveSetting, writeTabFile

inputData, inputKey

initWithData, initVar

isLeapYear, isEqual

doSomething

이렇게 지을수 있습니다.



마치기전에..

제가 적은대로 이걸 그대로 지킬필요는 없습니다.

상황에 맞게 바꿀수도 있는거고, 진짜 간단한 프로그램이라 저걸 지킬 필요도 없는경우일수도 있고

아니면 자기만의 방식으로 해도됩니다.

하지만 자기만의 방식이 없는경우에 저렇게 지켜서 프로그래밍을 하신다면

더 보기좋은 코드를 만들수 있지 않을까요? :)

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

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

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

 

 

출처: http://www.gamedevforever.com/116





코딩 스타일에서 정의하는 것들의 예
우선 코딩 스타일의 예부터.....

인덴테이션/줄바꿈
다음 형태 중에 어떤 놈을 이용할까? 하는 고민...

a)
for ( int i = 0; i < 10; ++i ) {
  sum += i;
}

b)
for ( int i = 0; i < 10; ++i )
{
    sum += i;
}

c)
for ( int i = 0; i < 10; ++i )    sum += i;


등등

빈칸(white space)의 사용
대충 이런 것들 중에 어떤 놈을 써야하는지...

a)
int a = c * ( d + e );

b)
int a=c*(d+e);

등등

변수이름 짓는 법
단어별 대소문자, 멤버변수앞에 m 접두어를 붙이는지 등등...

a)
mMemberVariable = temp_variable * 2.0f;

b)
MemberVariable = tempVariable * 2.0f;

등등

함수이름 짓는 법
단어별 대소문자, private, public 대소문자 등등

a)
int MyClass::getNumPrivate();
int MyClass:GetNumPublic();
int do_something();

b)
int MyClass::_getNumPrivate();
int MyClass:getNumPublic();
int doSomething();

 

등등

주석다는 규칙
클래스 선언 마다 주석을 달아야 하는가?
함수 선언마다 주석을 달아야 하는가? 변수명 설명? 반환값 설명?
그 외 어떤 코드에 주석을 달아야하는가?
주석 달때 스타일은 어떤걸로? /* ... */,  //, ///, /**...**/ 등등
기타 잡다한 것들...

 

하지만 의문이 들다
저도 좀 뭔가 깔끔하게 정리되어 있는 걸 좋아하는 놈이라 한동안 이런 미신에 푹 빠져살았습니다. 그런데 최근 몇 년 동안에 '정말정형화된 코딩스타일이 생산성을 향상시키나?'하는 의문이 들더군요. (물론 게임업계에 한정된 이야기입니다. 의료업계에서는 계속 빡세게 해주세요... 수술대 올라갔다가 버그 때문에 뻗은 기계 대문에 죽긴 싫습니다... -_-)

사실 코딩 스타일이란게 종교와도 같은 것이어서 이렇다 할 정답이 없습니다. 프로그래머 10명 잡고 물어보면 다들 선호하는 코딩 스타일이 다릅니다. 일례로 함수이름만 들어도 어떤 프로그래머는 private함수는 getNum() 이란식으로 작성하고 public 함수는 GetNum()이라고 작성하자고 하는 반면 다른 프로그래머는 get_num()과 GetNum()이라고 하자고도 할 겁니다.

어차피 회사란 집단체니까 그냥 일률적으로 정해놓고 프로그래머들을 다 강요하면 된다고 생각하는 건데... 정작 문제는 이 스타일로 개종해야하는 사람들에게는 이게 오히려 생산성 저하의 요소가 됩니다.

중요한건 프로그래머의 상식/배려/역량
그리고 참 웃겼던건.. 제가 지금까지 함께 작업했던 프로그래머만 해도 수백명인데... 그리고 이 엔진 저 엔진 옮겨다니면서 거친 코딩 스탠다드만도 대여섯은 될텐데..... 코딩 스탠다드하고 가독성은 정말 별 상관이 없었단 겁니다. 그보다는 오히려 어떤 코딩 스타일을 사용하던 간에 깨끗한 코드를 작성할 수 있는 프로그래머의 역량이 더 중요하더군요. 이런 분들이 대부분 이었습니다. 즉 굳이 코딩 스탠다드가 필요없는 인간들이 대부분...

회사에서 아무리 철저한 코딩 스탠다드를 만들어 놓아도 코드 드럽게 쓰는 애들(소수에 그칩니다)은 여전히 코드 이해 안되게 쓰더군요. 그래서 이런 애들을 좀 더 잘 관리하려고 코딩 스탠다드에 규칙을 더 추가합니다. 이러면 얘네들이 좀 나아질까요? 아닙니다. 얘네들이 코드가 드러운 이유가 있습니다. 남생각을 별로 안하거든요. 규칙이 얼마나 철저하던 간에 어떻게든 빠져나갑니다. 그 덕에 오히려 원래부터 깔끔한 코드 쓰던 사람들만 고생하죠. 이 사람들은 악법도 법이라고 존중하고, 다른 프로그래머들도 배려할 줄 아는 분들이므로 새로 생긴 규칙에 맞게 또 열심히 코드를 작성합니다. 이 규칙 없어도 원래부터 이해잘되는 깔끔한 코드를 작성하던 사람들인데 따라야 할 규칙만 늘어버렸죠. 

 

결국 제값주고 산 놈들만 손해란 건가?
이렇게 생각을 하다보니.... 꼭 게임에 DRM 입히는거와 마찬가지란 생각이 들더라구요. DRM을 아무리 빡세게 입혀도 해적질 할 애들은 다 해적질하고 쓰니 아무 상관없는데, 정가내고 산 사람들만 그 DRM에 얽매여서 온갖 귀찮은 일을 다 당해야 하는....


해석은 귀찮으니 생략..... 그림만 봐도 대충 뭔 귀찮은 일을 당하는 지 알거다...



차라리 개별적으로 갈구자. 짜르던가. 칼부림도 가끔?
결국 제가 내린 결론은 저희가 너무도 당연하게 여기며 쓰던 코딩 스탠다드가 생각보다 별로 효과적이지 않단 겁니다.

물론 코딩스탠다드를 싸그리 없애자는 건 아닙니다. 좀 최소한으로 줄이자는 거죠. 그리고 코드 드럽게 쓰는 애들을 개별적으로 갈궈서 좀 고치게 하던가... (인간이 직접 갈구는게 문서 던져주고 따라하라는 것보다 훨씬 효율적입니다... 칼부림이 가끔 날 뿐이지... -_-)...... 안되면 그냥 짜르던가....

이런 생각을 하게 된 또 다른 계기는 게임업계가 엄격한 코딩스타일이 필요한 분야가 아니란 겁니다. 어차피 코드작성한 건 다 내부적으로 쓰는거고, 문제 있으면 소스코드가 다 떡하니 있으니 아무나 가서 고칠 수 있으니까요. 게임업계가 아니라 미들웨어를 만들어서 판매하는 회사라던가 군사업체 및 의료장비에 들어가는 소프트웨어를 만드는 회사에서는 이게 좀 더 엄격해야겠죠. 미들웨어 회사는 라이브러리만 던져주는 경우가 많으니 그렇고, 군사업체 및 의료장비는 사람 생명이 걸린 일이라서 어쩌다 뭔 짓을 하더라도 버그를 아예 처음부터 만들지 않는게 중요하니까요. 어차피 게임이 엔터테인먼트 산업이고, 게임의 요구사항은 하루가 멀다하고 바뀌므로 차라리 유연하게 재빨리 코드를 작성할 수 있는게 게임 품질 향상에 더 기여한다고 봅니다. 게임의 품질이란건 사실 게이머가 느끼는 품질일 뿐이거든요. 인간의 목숨이 걸린 의료소프트웨어에서의 품질하고는 전혀 다르죠.

그냥 이정도면 하면 안될까요?
그래서 과연 '코딩스탠다드를 어디까지 줄일 수 있을까?' 하는 걸 좀 생각해봤죠. 이게 좀 간단해야 정작 남 배려할 줄 아는 프로그래머의 인생도 편해지지 않을까 해서....


나도 좀 단순히 편하게 살고 싶다... 물론 패리스 힐튼과 함께.... 근데 토토샵 질이 좀 심한데? -_-

 

위에서 들었던 목록을 한번씩 살펴보면서 이야기하죠.

인덴테이션
코드의 가독성을 위해서는 여전히 중요하다고 생각합니다. 특히나 코드의 scope를 보여주는데 도움이 되니까요. 근데 이제 Visual Studio 가 이런 인덴테이션을 직접 알아서 해주므로 크게 걱정할 필요가 없습니다. 20년 전에 이런 게 자동으로 안될때나 문제였지...

빈칸사용
뭐 이건 사실 int k = a * ( b + c );로 해주냐 int k=a*(b+c);로 해주냐 차인데... 어떻게 쓰던 코드 이해하는데 별 차이가 없습니다.... 굳이 목숨 걸 필요 없지 않나요? -_-

변수명/함수명
일단 멤버변수 이름앞에 m을 붙이니 public 함수는 대문자로 시작하니 마니 하는 건 이젠 별 의미가 없는거 같습니다. 어차피 IDE가 워낙 좋아져서 그냥 마우스만 올려도 나오는 경우가 많고 아니면 F12키 한번 누르면 곧바로 선언된데로 이동하니까요. 그리고 다시 돌아올땐 Ctrl + -키 누르면 끝이고... Visual Studio의 인텔리센스가 잘 작동안하면 Visual Assist 를 깔아도.....

단, 가독성을 위해 변수명이나 함수명을 잘 작성해주는 건 찬성입니다. 즉 int a = 1; 이라기보단 int numLoop = 1; 이란 식으로 변수명을 작성해주는거죠.. 딱 보면 이해가 되게... 함수명도 마찬가지고요.

주석다는 규칙
사실 주석달아야 할 곳에 안달아서 헷갈리는 경우도 많고, 달지 않아도 될 곳에 달아서 오히려 코드만 지저분해지는 경우 허다하죠... 이건 사실 어떻게 정의해도 코드 드러운 애들은 여전히 드럽고 코드 깔끔한 분들은 여전히 깔끔한.. 그런 부분...

저 개인적으로는
클래스 이름만 잘 정하면 굳이 클래스마다 주석을 달 필요가 없다. 이름보고 이해안될때만 기재.
함수/변수 이름만 잘 정하면 굳이 함수/변수마다 주석을 달 필요가 없다. 이름보고 이해 안되거나 변수의 반환값이 기묘할 때만 기재.
코드에서 곧바로 이해되면 주석은 필요없다.
옆에 앉은 놈이 코드만 보고 곧바로 이해가 안되면 코드블럭 별로 그 위에 주석으로 기재
정도가 젤 난거 같습니다.

대충 정리
이렇게 써보고 보니 결국 제가 괜찮다고 생각하는 법은 코딩 스타일의 통일성을 유지하려고 괜히 쓸데없는 규칙을 만드는 대신에 개발자들의 상식을 믿으란 쪽이 되어버린듯...

어쨌든 제가 좋다고 생각하는 코딩스타일은 이것 정도입니다.
변수명/함수명에 의미를 담을 것
코드의 스코프를 보여주기 위해 인덴테이션을 잘 할 것
동료 프로그래머가 코드에서 곧바로 이해못할 만한 내용이면 코드 블럭 위해 간단히 주석을 달 것

개종 안하셔도 되요~
뭐, 다들 이러세요~ 라는 걸로 쓴 글은 아니고.... 그냥 한 번 생각해보시라고... 그리고 토론 좀 해보잔 의도로... (어차피 종교적인 토론이라... 난장판이 될 가능성이 높지만...-_-)

 

 

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

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

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