1. 일반적인 대부분의 경우 표준 씨샵 컨벤션 사용
2. 컨트롤과 유저컨트롤은 헝가리안 케이스 적용 필요
button => btn
label => lbl
panel => pn
progress bar => pgb
user control => uc
…
축약어는 컨벤션 따라서.
개인적으로 작업할 때는 3글자 무조건 맞춤(ex panel은 pnl)
컨트롤은 디자이너 코드에 숨겨져 있으므로 읽는 입장에서 헝가리안 케이스가 좋은 예.
3. 이벤트 처리기는 {컨트롤이름}_{메소드명} 으로 지음
ex. 세이브버튼(btnSave) 클릭 이벤트
private void btnSave_Click(object sender, EventArgs e)
{
}
씨샵 표준 컨벤션에는 위배되나, 이런 방식이 디폴트이고 많은 사람들이 따르므로 최선이라고 생각함.
3. 개인적인 컨벤션
일반적 멤버 변수는 m으로, 불리언은 b로, 스태틱은 s를 접두사로 붙힘
private int mNumber;
private bool bFlag;
private static object sObject;
그러나 실무에서는 아직도 c++ 컨벤션을 따르는 코드가 많음. 이런 케이스를 훨씬 많이 본다.
private int m_number;
private bool b_flag;
private static object s_object;
mfc 만지다가 오신 분이 많아서 그렇다고 생각함.
2. 컨트롤과 유저컨트롤은 헝가리안 케이스 적용 필요
button => btn
label => lbl
panel => pn
progress bar => pgb
user control => uc
…
축약어는 컨벤션 따라서.
개인적으로 작업할 때는 3글자 무조건 맞춤(ex panel은 pnl)
컨트롤은 디자이너 코드에 숨겨져 있으므로 읽는 입장에서 헝가리안 케이스가 좋은 예.
3. 이벤트 처리기는 {컨트롤이름}_{메소드명} 으로 지음
ex. 세이브버튼(btnSave) 클릭 이벤트
private void btnSave_Click(object sender, EventArgs e)
{
}
씨샵 표준 컨벤션에는 위배되나, 이런 방식이 디폴트이고 많은 사람들이 따르므로 최선이라고 생각함.
3. 개인적인 컨벤션
일반적 멤버 변수는 m으로, 불리언은 b로, 스태틱은 s를 접두사로 붙힘
private int mNumber;
private bool bFlag;
private static object sObject;
그러나 실무에서는 아직도 c++ 컨벤션을 따르는 코드가 많음. 이런 케이스를 훨씬 많이 본다.
private int m_number;
private bool b_flag;
private static object s_object;
mfc 만지다가 오신 분이 많아서 그렇다고 생각함.
m_은 이해되는데 b_랑 s_는 뭐야? s_는 static 멤버변수에서나 쓰는 거 아니였나
어.. 글에 써놓음 불리언은 b, 스태틱은 s. 니가 말한 그대로임
해당 댓글은 삭제되었습니다.
나도 헝가리안 축약 매우 좋지 않게 생각함, 일반적인 케이스에서는. 근데 윈폼 컨트롤의 경우에는 변경가능성이 거의 희박한데다가 명시적이어서 나쁘지 않다고 봄.. ide 기능 없이도 유추가 가능하니까.
m 등을 통한 멤버 구분은 나쁘지 않다고 생각한다. 자바처럼 쓰고 접근할 때 this. 붙이는게 꼭 정답은 아니라고 봄. 마소 개발자들도 실제로 어떤 방식으로는 멤버를 구분하고, this. 키워드는 잘 안씀
맞음 ide없이 윈폼할 일은 없음. 그러나 컨트롤 갯수가 수십 수백개가 되고 파악이 어렵다면 마우스 올려 확인하는 수고는 좀 덜 수 있음. 단, 정말 유저컨트롤에 한해서만 해당됨.
progressBarFileUpload, flowLayoutPanelPicture 처럼 매우 장황해지는 경우에 대해 어떻게 처리해야 하는지 특수한 해답이 없기 때문임. 이에 대한 좋은 방밥이 있다면 소개 부탁함.
?? 더 적절한 방법을 말해 달라고 하니 왜 그런식으로 회피함? 그리고 헝가리안 드물게 적용되는 분야에서도 축약어는 꼭 필요할 때만 붙이는거고 안쓰는데?? 해당케이스는 pgbFileUpload가 되겠지
헝가리안은 진짜 좋은 방법이 맞음..40년 전 기준으로는 ㅇㅇ 현대에서 헝가리안을 컨벤션이라고 따르는 새끼는 다 뚝배기 한대씩 때려도 무죄라고 생각함
대부분의 경우에는 니 말이 맞다고 생각함. 그러니 윈폼 컨트롤을 써보기 바람. 이미 써봤다면, 해당 규칙 없이 일관성을 지키면서 한눈에 확인 가능한 더 좋은 방법도 말해주고.
객체지향과 컨벤션은 무관함.
그리고 씨샵 공식 컨벤션은 멤버변수 구분을 위해 _를 쓰고, s_도 쓰고, this 키워드는 최대한 회피함. 1번은 인정하는데 4번은 싫다고 한 이유도 궁금함
그렇게 추측하고 한 말이라면 내가 더 이상 할 말이 없음..
아니 왜 대답을 안하고 토낌?? 씨샵 공식 컨벤션을 따르는건 괜찮다고 했다가 갑자기 씨샵 공식 컨벤션을 부정하더니 축약어를 쓰는게 객체지향적이지 않다고 하길래 객체지향과 컨벤션이 관계없다고 하니까 축약어를 쓰는 인간은 분명히 객체지향적인 코드를 짜지 않을거라고 주장하고
해당 특수한 케이스에 더 나은 대안을 제안해 달라고 하니까 갑자기 왜 댓글들 삭제함?
닷넷에서 헝가리안 안씀 멤버변수 앞에 언더바 붙이는건 있지만
윈폼은 인정 근데 굳이 bFlag, sField 같은게 필요한이유가??
동의함. 회사에 관습적 사용이 되고 있는 c++ 네이밍이 있는 상황에서 한번에 모든 규칙을 나 혼자 변화시켜선 안되기 때문임. 객체지향 언어들의 보편적 컨벤션에 대해 모르는 것은 아니지만, 윈폼 컨트롤 네이밍에 대한 것은 아직도 골칫덩이임
윈폼 컨트롤 변수 네이밍의 대안에 대해서도 찾아보고 있는데, 대안이라는게 매우 쓸모없는 경우가 많음. 헝가리안을 없애는 경우에는 맥락 파악이 안된다. 나중에 컨트롤이 변경되면 어쩌냐고 하는데, 그게 변경될 정도면 사용 방법상 어차피 소스코드 변경이 불가피함. 혹은, 접미사로 타입명을 적으라고 하는데 이건 분류를 어렵게하며 단점만 취한다.
전반적으로 윈폼으로 일정규모이상의 작업을 해보지 않은 사람들의 의견으로 보였음.