멤버변수 m_
전역변수 g_
정수형 n
포인터 p
벡터 v
기본은 카멜
예를들어 m_pCodeSafer
변수같은건 길게쓰더라도 한눈에 뭐하는 놈인지 알게
근데 사실 프로젝트마다 룰이 조금씩 달라져서 그거에 최대한 맞춤
변수 중간에 언더바 많이 들어가는건 마이컴할때만 그랬던것같음
뭐가 좋은지는 잘모르겠고 뭐든 눈에 익숙한게 좋아보이는거 같음
전역변수 g_
정수형 n
포인터 p
벡터 v
기본은 카멜
예를들어 m_pCodeSafer
변수같은건 길게쓰더라도 한눈에 뭐하는 놈인지 알게
근데 사실 프로젝트마다 룰이 조금씩 달라져서 그거에 최대한 맞춤
변수 중간에 언더바 많이 들어가는건 마이컴할때만 그랬던것같음
뭐가 좋은지는 잘모르겠고 뭐든 눈에 익숙한게 좋아보이는거 같음
m_, g_도 헝가리안 표기법임. Hungarian Notation + Camel Case네. 근데 m_까지는 괜찮다고 보는데(클래스의 멤버 요소는 타입이 중요한 경우가 많기도 하고 말야. 멤버 변수나 멤버 함수의 구분이라던지) 나머지는 극혐. 없어도 되는 것들임.
나도 멤버에 엠 붙이다가 이젠 안쓸려구 점점 경험이 쌓일수록 지역변수는 템포럴 하든지 아주 구체적이 되더라 그래서 멤버랑은 구분됨
참조 포인터는?
전역만 구분하면되 나중에 리팩할때 쮜끔 편함
최대한 간결하게 다 줄임말로 네이밍하는거는 같이 프로그래밍 하는사람에게 민폐라고 생각한다
헝가리안 표기법을 써도 되는 걸 권장하는 수준은 m_ 정도나 UI 디자인할 때 btnOK처럼 컨트롤 타입에 따라 prefix를 붙여주는 거 정도랄까. 그 이외엔 사족(蛇足)이야.
돼
언더바 극혐
헝가리안이랑 frmMain 은 다르지
꼭붙어야 될 네이밍의 약어 표현인데 분류를 우선으로 배치한거잖아
이런거 프로젝트 시작하기전에 입맞추고해야 나중에 딴소리 안나오지. 이런거 하나하나때문에 은근히 남 흉보게됨
하물며 타잎이 변할 가능성도 적고
코세 성님. 헝가리안 표기법이 아니라는 근거 혹시 드실 수 있나요? 저는 헝가리안 표기법으로 알고 있고
http://en.wikipedia.org/wiki/Hungarian_notation#Advantages
에도 그렇게 나오는데요?
헝가리안의 문제는 길어 타잎변하면 다 바꿔야해 이따윈데
(frmMain 말하는 거임)
mainForm 의 도치에 약어표현일 뿐
카테고리 우선 네이밍인거지 타잎은 아님 엄밀히
헝가리안은 너무 세분화되어서 카테고리 정리가 안됨