왜 "헝가리 표기법"을 사용하면 안 되나요?
https://stackoverflow.com/questions/111933
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는 헝가리어가 무엇을 가리키는지 알고 있습니다. 변수, 매개변수 또는 유형에 대한 정보를 이름 앞에 접두사로 제공하는 것입니다.어떤 경우에는 그것이 좋은 생각인 것처럼 보이지만 모두가 그것에 대해 격렬하게 반대하는 것 같습니다.유용한 정보가 전달되고 있다고 생각되면 바로 사용할 수 있는 곳에 놓아두면 안되는 이유는 무엇입니까?
또한보십시오: 사람들이 실제 세계에서 헝가리어 명명 규칙을 사용합니까?
해결책
대부분의 사람들은 헝가리어 표기법을 잘못된 방식으로 사용하여 잘못된 결과를 얻고 있습니다.
Joel Spolsky의 훌륭한 기사를 읽어보세요. 잘못된 코드를 잘못된 것처럼 보이게 만들기.
간단히 말해서 변수 이름 앞에 변수 이름을 붙인 헝가리어 표기법입니다. type (문자열) (헝가리어 시스템)은 쓸모가 없기 때문에 좋지 않습니다.
헝가리어 표기법은 작성자가 의도한 대로 변수 이름 앞에 변수 이름을 붙입니다. kind (Joel의 예를 사용하여:안전한 문자열 또는 안전하지 않은 문자열), 소위 Apps 헝가리어는 용도가 있으며 여전히 가치가 있습니다.
다른 팁
vadj헝가리어 표기법을 사용하면 vmakes ncode adj읽기가 어려워집니다.
조엘은 틀렸고 그 이유는 다음과 같습니다.
그가 말하는 '신청' 정보 유형 시스템으로 인코딩되어야 합니다..안전한 데이터가 필요한 함수에 안전하지 않은 데이터를 전달하지 않도록 변수 이름을 바꾸는 데 의존해서는 안 됩니다.유형 오류로 만들어야 합니다. 불가능한 그렇게 하려면.안전하지 않은 데이터는 안전하지 않은 것으로 표시된 유형을 가져야 하므로 단순히 안전한 함수에 전달될 수 없습니다.안전하지 않은 상태에서 안전한 상태로 변환하려면 일종의 삭제 기능을 사용한 처리가 필요합니다.
조엘이 "종류"라고 말하는 많은 것들은 종류가 아닙니다.사실 그것들은 유형입니다.
그러나 대부분의 언어에는 이러한 종류의 구별을 적용할 수 있을 만큼 표현력이 풍부한 유형 시스템이 부족합니다.예를 들어, C에 일종의 "강력한 typedef"(typedef 이름에 기본 유형의 모든 작업이 포함되어 있지만 변환할 수 없는 경우)가 있는 경우 이러한 문제는 많이 사라질 것입니다.예를 들어, 다음과 같이 말할 수 있다면 strong typedef std::string unsafe_string; 새로운 유형을 소개하기 위해 unsafe_string std::string으로 변환할 수 없으므로 과부하 해결 등에 참여할 수 있습니다.등) 그러면 어리석은 접두사가 필요하지 않습니다.
따라서 헝가리어가 유형이 아닌 것에 대한 것이라는 중심 주장은 잘못된 것입니다.유형 정보에 사용됩니다.확실히 전통적인 C 유형 정보보다 더 풍부한 유형 정보가 있습니다.객체의 목적을 나타내기 위해 일종의 의미론적 세부 사항을 인코딩하는 유형 정보입니다.그러나 이는 여전히 유형 정보이며 적절한 솔루션은 항상 이를 유형 시스템으로 인코딩하는 것이었습니다.이를 유형 시스템으로 인코딩하는 것은 규칙의 적절한 유효성 검사 및 시행을 얻는 가장 좋은 방법입니다.변수 이름은 단순히 겨자를 자르지 않습니다.
즉, "잘못된 코드를 개발자에게 잘못된 것처럼 보이게 만드는 것"이 목표가 되어서는 안 됩니다."잘못된 코드를 잘못된 것처럼 보이게 만들어야 합니다. 컴파일러에게".
내 생각에는 소스 코드가 엄청나게 복잡해집니다.
또한 강력한 형식의 언어에서는 많은 이점을 얻지 못합니다.어떤 형태로든 유형 불일치 어리석은 짓을 하면 컴파일러가 이에 대해 알려줄 것입니다.
헝가리어 표기법은 언어에서만 의미가 있습니다. 사용자 정의 유형 없이.최신 함수형 또는 OO 언어에서는 값의 "종류"에 대한 정보를 변수 이름이 아닌 데이터 유형이나 클래스로 인코딩합니다.
여러 답변 참조 조엘스 기사.그러나 그의 예는 (적어도 오랫동안) 사용자 정의 클래스를 지원하지 않은 VBScript에 있다는 점에 유의하십시오.사용자 정의 유형이 있는 언어에서는 HtmlEncodedString 유형을 생성한 다음 Write 메서드가 해당 유형만 허용하도록 하여 동일한 문제를 해결합니다.정적으로 유형이 지정된 언어에서 컴파일러는 모든 인코딩 오류를 포착하고, 동적으로 유형이 지정된 언어에서는 런타임 예외가 발생하지만 어떤 경우에도 인코딩되지 않은 문자열을 작성하지 않도록 보호됩니다.헝가리어 표기법은 프로그래머를 인간 유형 검사기로 바꾸어 일반적으로 소프트웨어가 더 잘 처리하는 작업입니다.
Joel은 "systems hangarian"과 "apps hangarian"을 구별합니다. 여기서 "systems hangarian"은 int, float 등과 같은 내장 유형을 인코딩하고 "apps hangarian"은 더 높은 수준의 메타 정보인 "kinds"를 인코딩합니다. 머신 유형을 넘어서는 변수에 대해 OO 또는 최신 기능 언어에서는 사용자 정의 유형을 만들 수 있으므로 이러한 의미에서 유형과 "종류" 사이에는 구분이 없습니다. 둘 다 유형 시스템과 "앱"으로 표시될 수 있습니다. 헝가리어는 "시스템" 헝가리어만큼 중복됩니다.
따라서 귀하의 질문에 대답하려면 다음을 수행하십시오. 시스템 헝가리어 안전하지 않고 유형이 약한 언어에서만 유용합니다.int 변수에 float 값을 할당하면 시스템이 중단됩니다.헝가리어 표기법은 60년대에 특별히 고안되었습니다. BCPL, 유형 검사를 전혀 수행하지 않는 매우 낮은 수준의 언어입니다.나는 오늘날 일반적으로 사용되는 어떤 언어에도 이 문제가 있다고 생각하지 않습니다. 화물 컬트 프로그래밍.
헝가리어 앱 레거시 VBScript 또는 VB 초기 버전과 같이 사용자 정의 유형이 없는 언어로 작업하는 경우 적합합니다.아마도 Perl과 PHP의 초기 버전일 수도 있습니다.다시 말하지만, 현대 언어에서 이 단어를 사용하는 것은 순수한 화물 숭배입니다.
다른 언어에서 헝가리어는 추악하고 중복되며 취약합니다.유형 시스템에서 이미 알려진 정보를 반복합니다. 반복하면 안 된다.해당 유형의 특정 인스턴스의 의도를 설명하는 변수에 대해 설명이 포함된 이름을 사용하십시오.유형 시스템을 사용하여 변수의 "종류" 또는 "클래스"에 대한 불변성과 메타 정보를 인코딩합니다.유형.
Joels 기사의 일반적인 요점(잘못된 코드가 잘못 보이도록 하는 것)은 매우 좋은 원칙입니다.그러나 버그에 대한 더 나은 보호는 가능한 경우 컴파일러가 자동으로 잘못된 코드를 감지하도록 하는 것입니다.
저는 모든 프로젝트에 항상 헝가리어 표기법을 사용합니다.수백 가지의 서로 다른 식별자 이름을 처리할 때 이것이 정말 도움이 된다는 것을 알았습니다.
예를 들어, 문자열이 필요한 함수를 호출할 때 's'를 입력하고 control-space를 누르면 IDE에서 's' 접두사가 붙은 변수 이름을 정확하게 표시합니다.
또 다른 이점은 unsigned에 u 접두어를 붙이고 signed int에 i를 붙일 때 잠재적으로 위험한 방식으로 signed와 unsigned를 혼합하고 있는 위치를 즉시 알 수 있다는 것입니다.
나는 거대한 75000줄의 코드베이스에서 해당 클래스의 기존 멤버 변수와 동일한 지역 변수 이름을 지정하여 (나와 다른 사람들에 의해) 버그가 발생한 횟수를 기억할 수 없습니다.그 이후로 저는 항상 멤버 앞에 'm_'을 붙입니다.
맛과 경험의 문제입니다.시도해 볼 때까지 두드리지 마십시오.
이 정보를 포함해야 하는 가장 큰 이유를 잊고 계십니다.프로그래머인 당신과는 아무런 관련이 없습니다.그것은 회사를 떠난 후 2~3년 후에 그 내용을 읽어야 하는 사람과 관련이 있습니다.
예, IDE는 유형을 신속하게 식별합니다.그러나 '비즈니스 규칙' 코드의 긴 배치를 읽을 때 각 변수가 어떤 유형인지 알아보기 위해 잠시 멈출 필요가 없는 것이 좋습니다.strUserID, intProduct 또는 guiProductID와 같은 것을 보면 다음과 같습니다. 많이 '램프 업' 시간이 더 쉬워졌습니다.
나는 MS가 일부 명명 규칙을 너무 멀리 적용했다는 데 동의합니다. 나는 그것을 "너무 좋은 것" 더미로 분류합니다.
명명 규칙을 고수한다면 좋은 것입니다.나는 "낙타 케이싱"(이전 작업에서 불렀던 것처럼)을 밀어붙일 정도로 비슷한 이름의 변수에 대한 정의를 보기 위해 끊임없이 되돌아가게 만드는 오래된 코드를 충분히 검토했습니다.지금 저는 VBScript를 사용하여 완전히 주석 처리되지 않은 수천 줄의 기존 ASP 코드를 처리하는 작업을 하고 있으며 문제를 해결하려고 노력하는 것은 악몽입니다.
각 변수 이름의 시작 부분에 암호 문자를 추가하는 것은 불필요하며 변수 이름 자체로는 설명이 충분하지 않음을 나타냅니다.어쨌든 대부분의 언어에서는 선언 시 변수 유형이 필요하므로 해당 정보는 이미 사용 가능합니다.
유지 관리 중에 변수 유형을 변경해야 하는 상황도 있습니다.예:"uint_16 u16foo"로 선언된 변수가 64비트 부호 없는 변수가 되어야 하는 경우 다음 두 가지 중 하나가 발생합니다.
- 각 변수 이름을 살펴보고 변경합니다(같은 이름을 가진 관련 없는 변수를 사용하지 않도록 주의).
- 유형만 변경하고 이름은 변경하지 마십시오. 그러면 혼란만 야기됩니다.
Joel Spolsky는 이에 대해 좋은 블로그 게시물을 작성했습니다.http://www.joelonsoftware.com/articles/Wrong.html기본적으로 괜찮은 IDE가 기억할 수 없는 경우 변수 유형을 원한다고 말할 때 코드를 읽기 어렵게 만들지 않는 것으로 귀결됩니다.또한 코드를 충분히 구획화하면 세 페이지 위로 어떤 변수가 선언되었는지 기억할 필요가 없습니다.
요즘에는 유형보다 범위가 더 중요하지 않습니까?
* l for local
* a for argument
* m for member
* g for global
* etc
오래된 코드를 리팩토링하는 최신 기술을 사용하면 유형을 변경했기 때문에 기호를 검색하고 바꾸는 것이 지루합니다. 컴파일러는 유형 변경을 포착하지만 범위의 잘못된 사용을 포착하지 못하는 경우가 많습니다. 여기서는 합리적인 명명 규칙이 도움이 됩니다.
만들지 말아야 할 이유가 없다 옳은 헝가리 표기법을 사용합니다.인기가 없는 이유는 오랫동안 지속된 반발 때문이다. 오용 특히 Windows API에서 헝가리어 표기법을 사용합니다.
DOS용 IDE와 유사한 것이 존재하기 전인 옛날에는(Windows에서 컴파일러를 실행할 충분한 여유 메모리가 없었기 때문에 개발이 DOS에서 이루어졌을 가능성이 높습니다), 어떤 도움도 받지 못했습니다. 변수 이름 위에 마우스를 올려보세요.(마우스가 있다고 가정합니다.) 처리해야 했던 것은 모든 것이 16비트 int(WORD) 또는 32비트 int(LONG WORD)로 전달되는 이벤트 콜백 함수였습니다.그런 다음 해당 매개변수를 지정된 이벤트 유형에 적합한 유형으로 캐스팅해야 했습니다.실제로 API의 대부분은 사실상 유형이 없었습니다.
결과적으로 다음과 같은 매개변수 이름을 가진 API가 생성됩니다.
LRESULT CALLBACK WindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam);
wParam과 lParam이라는 이름은 꽤 끔찍하기는 하지만 param1과 param2라고 명명하는 것보다 나쁘지는 않습니다.
설상가상으로 Window 3.0/3.1에는 근거리 포인터와 원거리 포인터의 두 가지 유형이 있었습니다.예를 들어, 메모리 관리 함수 LocalLock의 반환 값은 PVOID였지만 GlobalLock의 반환 값은 LPVOID('L'은 길다)였습니다.그 끔찍한 표기법은 확장되어 엘옹 피ointer 문자열이 앞에 붙었습니다 LP, 단순히 malloc된 문자열과 구별하기 위해.
이런 종류의 일에 반발이 있었다는 것은 놀라운 일이 아닙니다.
헝가리어 표기법은 개발자가 특정 변수가 사용되는 방식을 빠르게 상기할 수 있도록 해주기 때문에 컴파일 시간 유형 검사가 없는 언어에서 유용할 수 있습니다.성능이나 행동에는 아무런 영향을 미치지 않습니다.코드 가독성을 향상시키는 것으로 예상되며 대부분 취향과 코딩 스타일의 문제입니다.바로 이러한 이유로 많은 개발자들로부터 비판을 받고 있습니다. 모든 사람의 두뇌 배선이 동일하지는 않습니다.
컴파일 타임 유형 검사 언어의 경우 이는 대부분 쓸모가 없습니다. 몇 줄 위로 스크롤하면 선언과 유형이 드러날 것입니다.전역 변수나 코드 블록이 둘 이상의 화면에 걸쳐 있는 경우 심각한 디자인 및 재사용성 문제가 있습니다.따라서 헝가리 표기법을 사용하면 개발자가 잘못된 디자인을 쉽게 벗어날 수 있다는 비판이 있습니다.이것이 아마도 미워하는 이유 중 하나 일 것입니다.
반면에 컴파일 타임 유형 검사 언어에도 헝가리 표기법이 도움이 되는 경우가 있을 수 있습니다. 무효의 포인터 또는 핸들win32 API에 있습니다.이는 실제 데이터 유형을 난독화하므로 거기에서 헝가리어 표기법을 사용하는 것이 장점이 될 수 있습니다.그러나 빌드 시 데이터 유형을 알 수 있다면 적절한 데이터 유형을 사용하는 것은 어떨까요?
일반적으로 헝가리 표기법을 사용하지 않을 이유가 없습니다.이는 좋아요, 정책 및 코딩 스타일의 문제입니다.
Python 프로그래머로서 헝가리어 표기법은 꽤 빨리 무너집니다.Python에서는 무엇이든 상관하지 않습니다. ~이다 문자열 - 가능하다면 상관없어요 처럼 행동하다 문자열(예:만약 그것이 있다면 ___str___() 문자열을 반환하는 메소드).
예를 들어 정수 12인 foo가 있다고 가정해 보겠습니다.
foo = 12
헝가리어 표기법에 따르면 나중에 그것이 무엇인지 알 수 있도록 정수임을 나타내기 위해 iFoo 또는 다른 이름으로 불러야 합니다.Python을 제외하고는 작동하지 않거나 오히려 말이 되지 않습니다.Python에서는 사용할 때 어떤 유형을 원하는지 결정합니다.나는 문자열을 원합니까?글쎄, 내가 이런 짓을 하면:
print "The current value of foo is %s" % foo
참고하세요 %s - 끈.Foo는 문자열이 아니지만 % 교환원이 전화할 거야 foo.___str___() 결과를 사용합니다(존재한다고 가정). foo 은 여전히 정수이지만 문자열을 원하면 문자열로 처리합니다.부동 소수점을 원하면 이를 부동 소수점으로 처리합니다.Python과 같이 동적으로 유형이 지정되는 언어에서 헝가리어 표기법은 의미가 없습니다. 사용하기 전까지는 어떤 유형인지는 중요하지 않으며, 특정 유형이 필요한 경우 해당 유형으로 변환해야 하기 때문입니다(예: float(foo)) 사용 시.
PHP와 같은 동적 언어에는 이러한 이점이 없습니다. PHP는 거의 아무도 기억하지 않는 모호한 규칙 집합을 기반으로 백그라운드에서 '올바른 일'을 수행하려고 시도하며, 이는 종종 예기치 않게 치명적인 혼란을 초래합니다.이 경우 다음과 같은 일종의 이름 지정 메커니즘이 사용됩니다. $files_count 또는 $file_name, 편리할 수 있습니다.
제가 보기에 헝가리 표기법은 거머리와 같습니다.아마도 과거에는 유용했거나 적어도 유용해 보였을 것입니다. 그러나 요즘에는 많은 이점이 없는 추가 입력만 많이 할 뿐입니다.
IDE는 유용한 정보를 전달해야 합니다.헝가리어는 IDE가 훨씬 덜 발전했을 때 일종의(전적으로는 아니지만 일종의) 의미를 부여했을 수 있습니다.
나에게 헝가리어는 좋은 의미로 그리스어입니다.
프로그래머가 아닌 엔지니어로서 저는 즉시 Apps 헝가리어의 장점에 대한 Joel의 기사를 읽었습니다. "잘못된 코드를 잘못된 것처럼 보이게 만들기".저는 Apps 헝가리어를 좋아합니다. 엔지니어링, 과학, 수학이 하위 및 상위 스크립트 기호를 사용하여 방정식과 공식을 표현하는 방법을 모방합니다. (예: 그리스 문자, 수학 연산자 등)구체적인 예를 들어보자 뉴턴의 만유인력 법칙:먼저 표준 수학 표기법으로, 그 다음에는 Apps 헝가리어 의사 코드로:
frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)
수학 표기법에서 가장 눈에 띄는 기호는 다음을 나타내는 기호입니다. 친절한 변수에 저장된 정보:힘, 질량, 위치 벡터 등아래 첨자는 명확히 하기 위해 두 번째 바이올린을 연주합니다.무슨 입장?이것이 바로 Apps 헝가리어가 하는 일입니다.그것은 당신에게 말하고 있습니다 친절한 변수에 먼저 저장된 다음 구체적인 내용을 살펴봅니다. 가장 가까운 코드는 수학적 표기법에 도달할 수 있습니다.
확실히 강한 타이핑을 사용하면 안전 대 안전 문제를 해결할 수 있습니다.Joel의 에세이에서 나온 안전하지 않은 문자열 예이지만 위치 및 속도 벡터에 대해 별도의 유형을 정의하지 않습니다.둘 다 크기가 3인 이중 배열이며 한 쪽에서 수행할 수 있는 모든 작업이 다른 쪽에도 적용될 수 있습니다.게다가 위치와 속도를 연결하거나(상태 벡터를 만들기 위해) 내적을 취하는 것은 완벽하지만 아마도 추가하지 않는 것이 합리적입니다.타이핑은 어떻게 처음 두 개는 허용하고 두 번째는 금지하며, 이러한 시스템은 보호하려는 모든 가능한 작업으로 어떻게 확장됩니까?타이핑 시스템에서 모든 수학과 물리학을 기꺼이 인코딩하지 않는 한.
무엇보다도 Matlab과 같은 약한 유형의 고급 언어나 Fortran 77 또는 Ada와 같은 오래된 언어로 많은 엔지니어링이 수행됩니다.
따라서 멋진 언어를 가지고 있고 IDE와 헝가리어 앱이 도움이 되지 않는다면 그것을 잊어버리세요. 많은 사람들이 분명히 그랬을 것입니다.하지만 약한 유형의 언어나 동적인 유형의 언어로 작업하는 초보 프로그래머보다 못한 저에게는 Apps 헝가리어를 사용하면 없을 때보다 더 나은 코드를 더 빨리 작성할 수 있습니다.
대부분의 최신 IDE는 유형을 명확하게 만드는 데 매우 효과적이며 믿을 수 없을 정도로 중복되고 쓸모가 없습니다.
게다가 -- 나에게는 -- intI, strUserName 등을 보는 것이 짜증스럽습니다.:)
유용한 정보가 전달되고 있다고 생각되면 바로 사용할 수 있는 곳에 놓아두면 안되는 이유는 무엇입니까?
그렇다면 다른 사람이 어떻게 생각하든 누가 신경 쓰나요?유용하다고 생각되면 표기법을 사용하십시오.
내 경험상 다음과 같은 이유로 좋지 않습니다.
1 - 변수 유형을 변경해야 하는 경우 모든 코드를 중단합니다(예:32비트 정수를 64비트 정수로 확장해야 하는 경우)
2 - 유형이 이미 선언에 있거나 실제 유형이 처음부터 그다지 중요하지 않은 동적 언어를 사용하므로 이는 쓸모 없는 정보입니다.
또한, 일반 프로그래밍을 허용하는 언어(예:함수를 작성할 때 일부 변수의 유형이 결정되지 않는 함수) 또는 동적 타이핑 시스템(예:유형이 컴파일 타임에 결정되지 않은 경우) 변수 이름을 어떻게 지정하시겠습니까?그리고 대부분의 현대 언어는 제한된 형식이라 할지라도 둘 중 하나를 지원합니다.
~ 안에 Joel Spolsky의 잘못된 코드를 잘못된 것처럼 보이게 만들기 그는 모든 사람들이 헝가리 표기법(그는 시스템 헝가리어라고 함)이라고 생각하는 것이 원래 의도했던 것과는 다르다고 설명합니다(그는 앱 헝가리어라고 함).아래로 스크롤하여 저는 헝가리예요 이 토론을 보러 가겠습니다.
기본적으로 시스템 헝가리어는 쓸모가 없습니다.이는 컴파일러 및/또는 IDE가 알려주는 것과 동일한 내용을 알려줍니다.
Apps 헝가리어는 변수가 무엇을 의미하는지 알려 주며 실제로 유용할 수 있습니다.
나는 올바른 위치에 접두사 한두 개를 붙이는 것이 문제가 되지 않을 것이라고 항상 생각했습니다.IEnumerable에서와 같이 "이건 인터페이스입니다. 특정 동작에 의존하지 마세요"와 같은 유용한 내용을 바로 전달할 수 있다면 그렇게 해야 한다고 생각합니다.주석은 한두 개의 문자 기호보다 훨씬 더 많은 것을 복잡하게 만들 수 있습니다.
컨트롤 목록이 IDE의 알파벳순 풀다운 목록에 표시되는 경우 양식(btnOK, txtLastName 등)에서 컨트롤 이름을 지정하는 데 유용한 규칙입니다.
저는 ASP.NET 서버 컨트롤에 헝가리어 표기법을 사용하는 경향이 있습니다. 오직, 그렇지 않으면 어떤 컨트롤이 양식에 있는지 알아내는 것이 너무 어렵다는 것을 알았습니다.
다음 코드 조각을 사용하세요.
<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />
누군가가 헝가리어 없이 해당 컨트롤 이름 집합을 갖는 더 나은 방법을 보여줄 수 있다면 나는 그 컨트롤 이름으로 이동하고 싶을 것입니다.
Joel의 기사는 훌륭하지만 한 가지 주요 사항이 누락된 것 같습니다.
헝가리 인은 코드베이스에서 특정 '아이디어'(Kind + Identifier 이름)를 독특하거나 거의 유니 키를 만듭니다.
코드 유지 관리에 있어서는 엄청난 양입니다.그것은 당신이 좋은 ol '단일 라인 텍스트 검색 (grep, findstr,'모든 파일 찾기 ')을 사용하여 해당'아이디어 '에 대한 모든 언급을 찾을 수 있음을 의미합니다.
코드를 읽는 방법을 아는 IDE가 있는데 이것이 왜 중요한가요?왜냐면 그들은 아직 잘하지 못하기 때문이죠.작은 코드베이스에서는보기가 어렵지만 큰 코드베이스에서는 댓글, XML 파일, PERL 스크립트 및 소스 컨트롤 외부 (문서, Wikis, 버그 데이터베이스)에 언급 될 수 있습니다.
여기서도 약간 조심해야 합니다.C/C ++ 매크로의 토큰을 파악하면 식별자의 언급을 숨길 수 있습니다.이러한 사례는 코딩 규칙을 사용하는 것을 처리 할 수 있으며 어쨌든 코드베이스의 소수의 식별자에만 영향을 미치는 경향이 있습니다.
추신유형 시스템과 유형 시스템 사용에 대한 요점헝가리어 - 둘 다 사용하는 것이 가장 좋습니다.컴파일러가 이를 포착하지 못할 경우 잘못된 코드만 있으면 잘못된 것처럼 보입니다.컴파일러가 이를 포착하도록 하는 것이 불가능한 경우가 많이 있습니다.하지만 가능하다면, 대신 그렇게 해주세요!
그러나 타당성을 고려할 때 유형 분할의 부정적인 영향을 고려하십시오.예를 들어C#에서 'int'를 내장되지 않은 유형으로 래핑하면 큰 결과가 발생합니다.따라서 일부 상황에서는 의미가 있지만 모든 상황에서는 그렇지 않습니다.
헝가리 표기법의 이점 폭로
- 변수를 구별하는 방법을 제공합니다.
유형이 한 값을 다른 값과 구별하는 모든 것이라면 이는 한 유형을 다른 유형으로 변환하는 데만 사용될 수 있습니다.유형 간에 변환되는 동일한 값이 있는 경우 변환 전용 함수에서 이 작업을 수행해야 할 가능성이 높습니다. (저는 헝가리어 VB6 남은 항목이 JSON 개체를 역직렬화하는 방법을 알 수 없거나 nullable 유형을 선언하거나 사용하는 방법을 제대로 이해할 수 없기 때문에 모든 메서드 매개 변수에 문자열을 사용하는 것을 보았습니다.) 헝가리어 접두사로만 구별되는 두 개의 변수가 있고 하나에서 다른 것으로의 변환이 아닌 경우 해당 변수를 사용하여 의도를 자세히 설명해야 합니다.
- 코드를 더 읽기 쉽게 만듭니다.
나는 헝가리어 표기법이 사람들을 변수 이름 때문에 게으르게 만든다는 것을 발견했습니다.그들은 그것을 구별할 수 있는 어떤 것이 있고 그 목적을 자세히 설명할 필요를 느끼지 않습니다.이는 헝가리 표기 코드와 헝가리어 표기 코드에서 일반적으로 찾을 수 있는 것입니다.현대의:SQL과 비교groupSelectSql(또는 일반적으로 이전 개발자가 삽입한 ORM을 사용한다고 가정하기 때문에 sSQL이 전혀 없습니다.), sValue 대formCollection값(또는 일반적으로 sValue가 없습니다. MVC에 있고 모델 바인딩 기능을 사용해야 하기 때문입니다.), sType 대게시 소스 등
가독성이 될 수 없습니다.sTemp1, sTemp2가 더 많이 보입니다...다른 모든 사람들이 합친 것보다 남은 헝가리 VB6의 sTempN.
- 오류를 방지합니다.
이것은 거짓인 숫자 2에 의한 것입니다.
주인의 말에 따르면:
http://www.joelonsoftware.com/articles/Wrong.html
평소와 같이 흥미로운 독서입니다.
추출물:
"누군가가 Simonyi의 논문을 읽고 "유형"이라는 단어를 사용했고 그가 유형, 클래스, 유형 시스템, 컴파일러가 수행하는 유형 검사 등을 의미한다고 생각했습니다.그는하지 않았다.그는 "유형"이라는 단어가 무엇을 의미하는지 매우 주의 깊게 설명했지만 도움이 되지 않았습니다.피해가 발생했습니다."
"그러나 Apps 헝가리어에는 여전히 엄청난 가치가 있습니다. 코드의 배열을 증가시켜 코드를 더 쉽게 읽고, 쓰고, 디버깅하고 유지 관리할 수 있게 하며, 가장 중요한 것은 잘못된 코드를 잘못된 것처럼 보이게 한다는 점입니다."
Joel On Software를 읽기 전에 시간을 좀 갖고 읽어보세요.:)
몇 가지 이유:
- 모든 최신 IDE는 변수 위에 마우스를 올리기만 하면 변수 유형을 제공합니다.
- 대부분의 유형 이름은 너무 깁니다. HttpClientRequestProvider)을 접두사로 합리적으로 사용합니다.
- 유형 정보에는 오른쪽 정보의 개요를 설명하는 대신 변수 선언을 다른 말로 표현한 것뿐입니다. 목적 변수의 (생각 myInteger 대 페이지 크기).
나는 모든 사람이 그것에 대해 열광적으로 반대한다고 생각하지 않습니다.정적 유형이 없는 언어에서는 매우 유용합니다.나는 그것이 아직 유형에 없는 정보를 제공하는 데 사용될 때 그것을 선호합니다.C에서처럼, char * sz이름 변수가 null로 끝나는 문자열을 참조한다고 말합니다. 이는 char*에 암시적이지 않습니다. 물론 typedef도 도움이 될 것입니다.
Joel은 헝가리어를 사용하여 변수가 HTML로 인코딩되었는지 여부를 알려주는 훌륭한 기사를 가졌습니다.
http://www.joelonsoftware.com/articles/Wrong.html
어쨌든, 나는 내가 이미 알고 있는 정보를 전달하는 데 사용되는 헝가리어를 싫어하는 경향이 있습니다.
물론 99%의 프로그래머가 어떤 것에 동의한다면 뭔가 잘못된 것입니다.여기에 동의하는 이유는 대부분이 헝가리 표기법을 정확하게 사용해 본 적이 없기 때문입니다.
자세한 논의를 위해 해당 주제에 대해 제가 작성한 블로그 게시물을 참조하시기 바랍니다.
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html
나는 헝가리어 표기법이 발명되었을 무렵 코딩을 시작했고, 프로젝트에서 처음으로 헝가리어 표기법을 사용하도록 강요받았을 때 나는 그것을 싫어했습니다.
얼마 후에 나는 그것이 제대로 이루어졌을 때 실제로 도움이 되었다는 것을 깨달았고 요즘 나는 그것을 좋아합니다.
하지만 모든 좋은 일이 그렇듯, 배우고 이해해야 하며 제대로 수행하려면 시간이 걸립니다.
헝가리어 표기법은 특히 Microsoft에서 남용되어 변수 이름보다 접두사가 길어지고 특히 유형(Win16에서는 다른 유형/크기, Win32에서는 동일한 악명 높은 lparam/wparam)을 변경할 때 매우 엄격하다는 것을 보여줍니다. ).
따라서 이러한 남용과 M$의 사용으로 인해 쓸모없는 것으로 간주되었습니다.
내 작업에서는 Java로 코딩하지만 창립자는 MFC 세계 출신이므로 비슷한 코드 스타일을 사용합니다(중괄호 정렬, 좋아요!, 메소드 이름에 대문자, 클래스 멤버에 m_ 같은 접두사(필드) ), s_를 정적 멤버 등으로).
그리고 그들은 모든 변수에 그 유형을 나타내는 접두사가 있어야 한다고 말했습니다(예:BufferedReader의 이름은 brData입니다.유형은 변경될 수 있지만 이름이 따르지 않거나 코더가 이러한 접두사 사용에 일관성이 없기 때문에 나쁜 생각인 것으로 나타났습니다(심지어 aBuffer, theProxy 등도 보입니다!).
개인적으로 저는 유용하다고 생각되는 몇 가지 접두사를 선택했습니다. 가장 중요한 것은 부울 변수 접두사인 b입니다. 왜냐하면 다음과 같은 구문을 허용하는 유일한 접두사이기 때문입니다. if (bVar) (일부 값을 true 또는 false로 자동 변환하는 기능을 사용하지 않음)C로 코딩할 때, 나중에 해제해야 한다는 점을 상기시키기 위해 malloc으로 할당된 변수에 접두사를 사용했습니다.등.
그래서 기본적으로 나는 이 표기법을 전체적으로 거부하는 것이 아니라 내 필요에 적합해 보이는 것을 취했습니다.
물론 일부 프로젝트(작업, 오픈 소스)에 기여할 때 저는 단지 정해진 규칙을 사용합니다!
