헝가리 법이란 무엇인가요? ASP에서 봤어요
헝가리 명명법
헝가리 명명법은 프로그래밍 명명 규칙입니다. 기본 원칙은 변수 이름 = 속성 + 유형 + 개체 설명입니다. 각 개체의 이름은 명확한 의미를 가져야 하며 개체의 전체 이름이거나 이름의 일부일 수 있습니다. 명명은 기억하기 쉽고 이해하기 쉽다는 원칙에 기초해야 합니다. 이름의 일관성을 보장하는 것이 매우 중요합니다.
예를 들어 폼 이름이 form인 경우 헝가리어 명명법에서는 frm으로 축약할 수 있습니다. 폼 변수 이름이 Switchboard인 경우 변수의 전체 이름은 frmSwitchboard가 되어야 합니다. 이런 식으로 변수 이름을 보면 Switchboard가 형태라는 것을 쉽게 알 수 있습니다. 마찬가지로 변수 유형이 레이블인 경우 lblSwitchboard로 이름을 지정해야 합니다. 헝가리어 명명법은 기억하기 매우 쉽고 변수 이름을 매우 명확하고 이해하기 쉽게 만들어 코드의 가독성을 높이고 프로그래머 간의 의사소통을 용이하게 한다는 것을 알 수 있습니다.
이 명명법은 찰스 시모니(Charles Simonyi)라는 헝가리 프로그래머가 고안했다고 합니다. 이후 그는 마이크로소프트에 몇 년간 머물렀기 때문에 이 명명법은 다양한 제품과 문서를 통해 마이크로소프트에 소개되었습니다. 요즘 대부분의 프로그래머는 개발에 어떤 소프트웨어를 사용하든 관계없이 이 명명법을 사용합니다. 이 명명법의 출발점은 프로그래머가 변수를 만들 때 변수 유형과 기타 속성을 직관적으로 이해할 수 있도록 속성 유형 객체에 설명된 순서대로 변수 이름을 결합하는 것입니다. 다음은 HN 변수 명명 사양입니다. 여기에는 내 개인적인 선호 사항도 포함됩니다:
속성 섹션
전역 변수
g_
상수
c_
c 클래스 멤버 변수
m_
정적 변수
s_
유형 부분
포인터
p
함수
fn
잘못됨
v
핸들
h
긴
l
부울
b
부동 포인트 유형(파일이라고도 함)
f
이중 단어
dw
문자열
sz
단축
n
배정밀도 부동 소수점
d
개수
c (보통 cnt)
문자
ch (보통 c)
정수 유형
i (보통 n )
바이트
단어별
w
실제
r
서명 없음
u
설명 부분
최대
최대
최소
최소
초기화
초기화
임시 변수
T(또는 임시)
소스 개체
Src
대상 개체
Dest
다음은 몇 가지 예입니다:
hwnd: h는 유형입니다. 설명, 핸들을 나타냄, wnd는 창을 나타내는 변수 개체 설명이므로 hwnd는 창 핸들을 나타냅니다.
pfnEatApple: pfn은 함수에 대한 포인터를 나타내는 유형 설명이고 EatApple은 변수입니다. 개체 설명이므로
EatApple 함수를 가리키는 함수 포인터 변수를 나타냅니다.
g_cch: g_는 전역 변수를 나타내는 속성 설명이고, c와 ch는 각각 카운트 유형과 문자 유형으로 함께 변수 유형을 나타냅니다.
유형, 객체 설명은 무시됩니다. 여기서는 문자 수를 세는 전역 변수를 나타냅니다.
위는 HN 명명법의 일반적인 규칙입니다.
요약: 헝가리어 명명법
헝가리 명명법
MFC, 핸들, 컨트롤 및 구조에 대한 명명 규칙 Windows 유형 샘플 변수 MFC 클래스 샘플 변수
HWND hWnd* pWnd; CDialog* pDlg; HDC hDC* pDC; ;
HPEN hPen;
HBRUSH hBrush* pBrush;
CFont* pFont; HBITMAP hBitmap* pBitmap; HPALETTE hPaltte* pPalette;
CRgn* pRgn; CMenu* pMenu; /p>
CState* pState;
CButton* pButton; HWND hCtl; ; CListBox* pListBox;
CComboBox* pComboBox;
CScrollBar* pScrollBar;
p>
POINT pt;
CSize 크기
CRect ect; 사양 접두사 유형 예
C 클래스 또는 구조 CDocument, CPrintInfo
m_ 멤버 변수 m_pDoc, m_nCustomers
변수 명명 사양 접두사 유형 설명 예
ch char 8비트 문자 chGrade
ch TCHAR 16비트 문자 chName _UNICODE가 정의된 경우
b BOOL Boolean bEnable
n int int (해당 크기는 운영 체제에 따라 다름) nLength
n UINT 부호 없는 값(크기는 운영 체제에 따라 다름) nHeight
w WORD 16비트 부호 없는 값 wPos
l LONG 32비트 부호 있는 정수형 lOffset
dw DWORD 32비트 부호 없는 정수형 dwRange
p * 포인터 pDoc
lp FAR* Far 포인터 lpszName
lpsz LPSTR 32비트 문자열 포인터 lpszName
lpsz LPCSTR 32비트 상수 문자열 포인터 lpszName
lpsz LPCTSTR _UNICODE가 정의된 경우 32입니다. -bit 상수 문자 문자열 포인터 lpszName
h Windows 객체 문장 처리
hWnd 처리
LPFn 콜백은 CALLBACK 함수의 원거리 포인터를 가리킵니다.
접두사 기호 유형 인스턴스 범위
IDR_ 다양한 유형의 여러 리소스가 식별자 IDR_MAIINFRAME 1을 공유합니다. ~0x6FFF
IDD_ 대화 상자 리소스 IDD_SPELL_CHECK 1 ~ 0x6FFF
HIDD_ 대화 상자 리소스의 도움말 컨텍스트 HIDD_SPELL_CHECK 0x20001 ~ 0x26FF
IDB_ 비트맵 리소스 IDB_COMPANY_LOGO 1 ~ 0x6FFF
IDC_ 커서 리소스 IDC_PENCIL 1~0x6FFF
IDI_ 아이콘 리소스 IDI_NOTEPAD 1~0x6FFF
ID_ 메뉴 항목 또는 도구 모음의 명령 ID_TOOLS_SPELLING 0x8000~0xDFFF
p>
HID_ 명령 도움말 컨텍스트 HID_TOOLS_SPELLING 0x18000~0x1DFFF
IDP_ 메시지 상자 프롬프트 IDP_INVALID_PARTNO 8~0xDEEF
HIDP_ 메시지 상자 도움말 컨텍스트 HIDP_INVALID_PARTNO 0x30008~0x3DEFF
IDS_ 문자열 리소스 IDS_COPYRIGHT 1~0x7EEF
IDC_ 대화 상자의 제어 IDC_RECALC 8~0xDEEF
Microsoft MFC 매크로 명명 사양 이름 유형
_AFXDLL 고유 동적 동적 링크 라이브러리(DLL) 버전
_ALPHA DEC Alpha 프로세서만 컴파일
_DEBUG 진단을 포함한 디버그 버전
_MBCS 멀티바이트 문자 컴파일 세트
_UNICODE 애플리케이션의 오픈 유니코드
MFC에서 제공하는 AFXAPI 함수
포인터를 통한 콜백 함수 콜백
라이브러리 식별 명명법 식별자 값 및 의미
p>
u ANSI(N) 또는 유니코드(U)
d 디버그 또는 릴리스: D = 디버그 식별자를 무시합니다.
정적 라이브러리 버전 명명 규칙 라이브러리 설명
NAFXCWD.LIB 디버그 버전: MFC 정적 링크 라이브러리
NAFXCW.LIB 릴리스 버전: MFC 정적 링크 라이브러리
p> p>
UAFXCWD.LIB 디버그 버전: 유니코드를 지원하는 MFC 정적 링크 라이브러리
UAFXCW.LIB 릴리스 버전: 유니코드를 지원하는 MFC 정적 링크 라이브러리
동적 링크 라이브러리 명명 사양 이름 유형
_AFXDLL 유일한 동적 링크 라이브러리(DLL) 버전
Windows에서 제공하는 WINAPI 함수
Windows.h의 새로운 명명 사양 유형 정의 설명
WINAPI는 API 선언에서 FAR PASCAL 위치를 사용합니다. 내보낸 API 채우기 지점이 있는 DLL을 작성하는 경우 자체 API에서 이 유형을 사용할 수 있습니다.
CALLBACK 위치 창 및 대화 상자 프로시저와 같은 애플리케이션 콜백 루틴에 사용되는 FAR PASCAL
LPCSTR은 읽기 전용 문자열 포인터에 사용된다는 점을 제외하면 LPSTR과 동일하며 정의도 유사합니다(const char FAR * )
UINT 호스트 환경(Windows NT 및 Windows 9x의 경우 32비트)에 따라 크기가 결정되는 이식 가능한 부호 없는 정수 유형입니다. 이는 unsigned int와 동의어입니다.
LRESULT 윈도우 프로그램의 반환 값 유형
LPARAM은 lParam이 사용하는 유형을 선언하고, lParam은 윈도우 프로그램의 네 번째 매개변수입니다.
WPARAM은 wParam이 사용하는 유형을 선언하고, wParam은 다음과 같습니다. 윈도우 프로그램의 세 번째 매개변수
LPVOID는 일반 포인터 타입으로 (void *)와 동일하며 LPSTR 대신 사용할 수 있다
--------- ------- ----------------- ------- ---------------
헝가리 명명법 비판
헝가리 명명법은 프로그래밍 명명 규칙입니다. 명명 규칙은 프로그램 작성 규칙 중 가장 중요하고 논쟁의 여지가 있는 측면입니다. 이는 고대부터 군사 전략가들 사이의 전쟁터였습니다. 명명 규칙의 용도는 무엇입니까? 네 단어: 정당화 가능. 이분법을 사용하여 명명 규칙은 좋은 명명 규칙과 나쁜 명명 규칙, 즉 정당화되는 명명 규칙과 정당화되지 않는 명명 규칙으로 구분됩니다. 좋은 댄스화는 댄서가 존재감을 느끼게 하는 신발이고, 나쁜 댄스화는 댄서를 족쇄에 차고 춤추게 만드는 신발입니다. 나쁜 명명 규칙은 좋은 명명 규칙이 창의적일 수 있는 것보다 훨씬 더 파괴적일 수 있습니다.
이 기사에서 증명하고 싶은 것은 헝가리 명명법이 나쁜 명명 규칙이라는 것입니다. 이 기사의 범위는 정적으로 강력한 형식의 프로그래밍 언어입니다. 본 글의 분석 템플릿은 C언어와 C언어입니다. 아래 헝가리식 표기법은 헝가리 명명법(Hungarian Nomenclature)의 약어입니다.
헝가리 명명법의 비용
헝가리 명명법은 변수 이름에 유형 이름 접두사를 추가하여 표현됩니다. 예: nFoo, szFoo, pFoo, cpFoo는 각각 정수 변수를 나타냅니다. , 문자열 변수, 포인터 변수 및 상수 포인터 변수. 헝가리 방식은 단일 위치(변수가 선언된 곳)에서 변수의 타입 정보를 여러 위치(변수가 사용되는 곳)로 복사하는 중복 방식임을 알 수 있다. 중복성 비용 중 하나는 복제본의 일관성을 유지하는 것입니다. 이 비용은 코드를 작성하고 유지 관리하기 위해 변수 유형을 변경해야 할 때 발생합니다. 이중화 방법의 두 번째 비용은 차지하는 추가 공간입니다. 좋은 작성자는 의식적으로 코드의 최소 구성 단위 길이가 30줄 미만인 것이 바람직하며, 50줄을 초과하는 경우 재구성해야 합니다.
가변 쓰기 공간은 이 규칙을 불필요하게 어렵게 만듭니다.
2 헝가리 명명법의 이점
여기서 헝가리 명명법의 이점이 모호하고 예측할 수 없다는 것이 입증되었습니다.
템플릿 1: strcpy(pstrFoo, pcstrFoo2) Vs strcpy(foo, foo2)
여기서 헝가리 법의 이점은 무엇입니까? 나는 그것을 볼 수 없다. 어떤 프로그래머도 strcpy 함수의 매개변수 유형을 모른다는 사실을 인정하지 않을 것입니다.
템플릿 2: 알 수 없는_함수(nFoo) 대 알 수 없음_함수(foo)
여기서 헝가리어 방법은 어떤 이점을 얻나요? 나는 그것을 볼 수 없다. 유형을 알 수 없는 함수의 경우 프로그래머는 해당 함수의 문서를 확인해야 하며 이는 비용이 듭니다. 헝가리어 방법을 사용하는 유일한 장점은 코드를 읽는 사람이 이 함수에 정수 매개변수가 필요하다는 것을 알고 있다는 것입니다. 함수는 인터페이스이고, 매개변수의 유형은 인터페이스의 작은 부분일 뿐입니다. 함수 기능, 종료 정보, 스레드 안전성, 예외 안전성, 매개변수 합법성 등과 같은 중요한 정보는 여전히 문서에서 참조해야 합니다.
템플릿 3: nFoo=nBar 대 foo=bar
여기서 헝가리와 프랑스는 어떤 이점을 얻나요? 나는 그것을 볼 수 없다. 헝가리식 방법을 사용하는 유일한 장점은 코드를 읽는 사람들이 여기에 정수 변수의 복사본이 발생한다는 것을 알 수 있다는 것인데, 소리도 괜찮고 편안하게 잠들 수 있습니다. 그가 본 것이 nFoo=szBar라면 그는 달콤한 꿈에서 깨어날 수도 있습니다. 잠깐만요, 정말 그런 일이 일어날까요? 가장 먼저 깨어나야 할 것은 컴파일러가 되어야 한다고 생각합니다. 반면에 nFoo=nBar는 문법적으로만 합법적입니다. 코드를 보는 사람들이 실제로 관심을 갖는 것은 의미적 합법성이며 헝가리 법률은 이에 도움이 되지 않습니다. 반면, 좋은 작성자는 의식적으로 코드의 가장 작은 조직 단위에 임시 변수가 1~2개가 적합하고, 3개 이상이면 재구성해야 한다는 규칙을 의식적으로 따릅니다. 위에서 언급한 첫 번째 규칙과 결합하면 이해하기 쉬운 코드는 그 자체로 이해하기 쉬워야 한다는 결론을 내릴 수 있습니다. 이것이 바로 코드의 품질이 내장되어 있다는 것입니다. 좋은 명명 규칙은 내장 품질에 제한적인 이점을 주는 반면, 잘못된 명명 규칙은 사람들이 생각하는 것보다 내장 품질에 더 많은 해를 끼칩니다.
3 헝가리어 명명법의 구현
여기서 헝가리어 명명법은 C 언어에서는 구현하기 어렵고 C 언어에서는 구현할 수 없다는 점을 증명할 필요가 있습니다. 논리적으로 말하면, 헝가리식 방법의 이점에 대해 부정적인 결론을 내린 후에 헝가리식 방법의 타당성을 입증하는 것은 불필요할 것입니다. 그러나 마 형제님이 이미 죽인 원수를 부활시킨 적이 있다는 점을 생각하면, 제가 한발 더 나아가는 것이 나을 것입니다.
앞서 언급한 것처럼 헝가리 방식은 타입 시스템의 중복성이므로 헝가리 방식 구현의 핵심은 타입 시스템을 정확하게 복사할 수 있는지 여부입니다. 이는 유형 시스템의 복잡성에 따라 다릅니다.
먼저 C 언어를 살펴보겠습니다:
1. 내장 유형: int, char, float, n, ch, f, d? 문제가없는 것 같습니다. 하지만 누가 공허함을 표현하는 방법을 말해 줄 수 있습니까?
2. 조합 유형: 배열, 공용체, 열거형, 구조체를 a, u, e, s? 오히려 어색한 것 같습니다.
여기서 어려운 점은 기본 유형의 이름을 지정하는 것이 아니라 하위 유형의 이름을 지정하는 것입니다. an은 정수 배열을 나타냅니까? sfoo, sbar는 구조 foo, 구조 bar를 의미합니까? ausfoo는 통합 구조 foo 배열을 나타냅니다. 피곤해요?
3. 특수 유형: 포인터. 포인터는 이론적으로 복합 유형이어야 하지만 C 언어에서는 서로 다른 포인터 유형을 엄격하게 구분하지 않기 때문에 C 언어에서는 내장 유형으로 간주할 수 있습니다.
쇼를 시작합시다: pausfoo는 통합 구조 foo 배열 포인터를 나타냅니다. ppp는 포인터 대 포인터를 나타냅니다.
악몽은 아직 끝나지 않았습니다. 더욱 풍부한 유형 시스템을 갖춘 C 언어를 살펴보겠습니다.
1.class: C 언어의 구조체가 여전히 극복될 수 있다면 stru에 따르면, C에서 클래스를 처리하기 위해 cls를 사용하는 것은 꿈도 꾸지 마세요. 엄밀히 말하면 클래스는 전혀 유형이 아니라 유형을 생성하기 위한 도구입니다. C에서 언어에 내장된 유형의 수는 클래스가 생성하는 사용자 정의 유형의 수에 비해 전혀 무시할 수 있습니다. stdVectorFoo는 표준 라이브러리 벡터 유형 변수 Foo?를 나타냅니다. 미친 생각.
2. 네임스페이스: BoostfilesystemiteratorFoo는 부스트 공간 파일 시스템 하위 공간 탐색 디렉터리 유형 변수 Foo?를 나타냅니다. 프로그래머들은 무너질 것입니다.
3. 템플릿: std::maplt; std::stringgt;의 정확한 이름을 기억하십니까? 기억이 안나는데 255자 이상인 것 같으니 양해 부탁드립니다.
4. 템플릿 매개변수: template lt; class BinaryPredicategt; const Tamp; 티. 신은 웃고 있다.
5. 유형 수정: static, extern, mutable,register, 휘발성, const, short, long, unsigned 악몽과 수정이란 무엇입니까? 아직도 악몽이다. 바이두 지도