나는 헝가리어가 무엇을 의미하는지 알고 있습니다-변수, 매개 변수 또는 유형에 대한 정보를 이름의 접두어로 제공합니다. 어떤 경우에는 좋은 생각 인 것처럼 보이지만 모두가 그것에 대해 광적으로 반대하는 것 같습니다. 유용한 정보가 전달되고 있다고 느낀다면 그 정보가있는 곳에 바로 배치하면 안되는 이유는 무엇입니까?
답변:
대부분의 사람들은 헝가리 표기법을 잘못된 방식으로 사용하여 잘못된 결과를 얻고 있습니다.
Joel Spolsky의이 훌륭한 기사를 읽으십시오 : Make Wrong Code Look Wrong .
요컨대, 변수 이름 앞에 type(문자열) (시스템 헝가리어) 를 접두사로 붙이는 헝가리 표기법 은 쓸모가 없기 때문에 나쁩니다.
Hungarian Notation은 작성자가 의도 한대로 변수 이름 앞에 변수 이름을 붙입니다 kind(Joel의 예 : 안전한 문자열 또는 안전하지 않은 문자열 사용). 소위 Apps Hungarian은 용도가 있으며 여전히 유용합니다.
vadjHungarian nnotation을 사용하면 ncode를 읽기가 어려워집니다.
Joel은 틀렸고 여기에 그 이유가 있습니다.
그가 말하는 "응용 프로그램"정보 는 유형 시스템으로 인코딩되어야합니다 . 안전한 데이터가 필요한 함수에 안전하지 않은 데이터를 전달하지 않도록 변수 이름을 뒤집는 것에 의존해서는 안됩니다. 유형 오류로 만들면 불가능 합니다. 안전하지 않은 데이터는 안전하지 않은 것으로 표시된 유형을 가져야 안전 함수로 전달할 수 없습니다. 안전하지 않은 상태에서 안전 함으로 변환하려면 일종의 살균 기능으로 처리해야합니다.
Joel이 "종류"라고 말하는 많은 것들은 종류가 아닙니다. 그들은 실제로 유형입니다.
그러나 대부분의 언어가 부족한 것은 이러한 종류의 구별을 강화할 수있을만큼 표현력이 뛰어난 유형 시스템입니다. 예를 들어 C에 "strong typedef"(typedef 이름에 기본 유형의 모든 작업이 포함되어 있지만 변환 할 수 없음)의 종류가 있으면 이러한 문제가 많이 사라집니다. 예를 들어, std :: string으로 변환 할 수없는 strong typedef std::string unsafe_string;새로운 유형을 도입 한다고 말할 수 있다면 unsafe_string(따라서 오버로드 해결 등에 참여할 수 있습니다.) 바보 같은 접두사가 필요하지 않습니다.
따라서 헝가리어가 유형이 아닌 것을위한 것이라는 핵심 주장은 잘못된 것입니다. 유형 정보에 사용되고 있습니다. 확실히 전통적인 C 유형 정보보다 더 풍부한 유형 정보; 객체의 목적을 나타 내기 위해 일종의 의미 론적 세부 사항을 인코딩하는 유형 정보입니다. 그러나 여전히 유형 정보이며 적절한 해결책은 항상 유형 시스템으로 인코딩하는 것입니다. 형식 시스템으로 인코딩하는 것은 규칙의 적절한 유효성 검사 및 적용을 얻는 가장 좋은 방법입니다. 변수 이름은 단순히 겨자를 자르지 않습니다.
즉, "개발자에게 잘못된 코드를 잘못 보이게하는 것"이 목표가되어서는 안됩니다. " 컴파일러에게 잘못된 코드를 잘못 보이게하는 것"이어야합니다 .
Joel is wrong, 그리고 What most languages lack, however, is a type system that's expressive enough to enforce these kind of distinctions.대부분의 언어 는 이러한 종류의 구별을 강요 할만큼 표현력 이 부족하기 때문에 Joel 이 옳습니다. 권리?
소스 코드가 엄청나게 복잡하다고 생각합니다.
또한 강력한 유형의 언어에서는 많은 것을 얻지 못합니다. 형식 불일치 tomfoolery를 수행하면 컴파일러가 이에 대해 알려줍니다.
헝가리어 표기법은 사용자 정의 유형이없는 언어에서만 의미가 있습니다 . 현대 함수 또는 OO 언어에서 값의 "종류"에 대한 정보를 변수 이름이 아닌 데이터 유형 또는 클래스로 인코딩합니다.
여러 답변이 Joels 기사를 참조 합니다. 그러나 그의 예제는 사용자 정의 클래스를 지원하지 않는 VBScript에 있습니다 (적어도 오랫동안). 사용자 정의 형식을 사용하는 언어에서는 HtmlEncodedString 형식을 만든 다음 Write 메서드가 해당 형식 만 허용하도록하여 동일한 문제를 해결합니다. 정적으로 형식화 된 언어에서 컴파일러는 모든 인코딩 오류를 포착합니다. 동적 형식에서는 런타임 예외가 발생하지만 어떤 경우에도 인코딩되지 않은 문자열 작성으로부터 보호됩니다. 헝가리어 표기법은 프로그래머를 인간 유형 검사기로 바꾸고 일반적으로 소프트웨어가 더 잘 처리하는 작업입니다.
Joel은 "systems hungarian"과 "apps hungarian"을 구분합니다. 여기서 "systems hungarian"은 int, float 등의 내장 유형을 인코딩하고 "apps hungarian"은 상위 수준의 메타 정보 인 "kinds"를 인코딩합니다. 기계 유형에 따른 변수에 대해 OO 또는 현대적인 기능 언어에서는 사용자 정의 유형을 만들 수 있으므로 이러한 의미에서 유형과 "종류"를 구분하지 않습니다. 둘 다 유형 시스템과 "앱"으로 나타낼 수 있습니다. 헝가리어는 "시스템"헝가리어만큼 중복됩니다.
따라서 귀하의 질문에 답하기 위해 : 시스템 헝가리어 는 안전하지 않고 약한 유형의 언어에서만 유용합니다. 예를 들어 int 변수에 float 값을 할당하면 시스템이 중단됩니다. 헝가리 표기법은 BCPL 에서 사용하기 위해 60 년대에 특별히 발명되었습니다. 유형 검사를 전혀 수행하지 않는 꽤 낮은 수준의 언어 인 에서 . 나는 오늘날 일반적으로 사용되는 어떤 언어에도이 문제가 있다고 생각하지 않지만, 표기법은 일종의 화물 컬트 프로그래밍 으로 살았습니다 .
앱 헝가리어레거시 VBScript 또는 VB의 초기 버전과 같이 사용자 정의 유형이없는 언어로 작업하는 경우 이 의미가 있습니다. Perl과 PHP의 초기 버전 일 수도 있습니다. 다시 말하지만 현대 언어에서 사용하는 것은 순수한화물 숭배입니다.
다른 언어에서 헝가리어는 추악하고 중복되며 취약합니다. 유형 시스템에서 이미 알려진 정보를 반복하고 자신을 반복해서는 안됩니다 . 이 특정 유형 인스턴스의 의도를 설명하는 변수에 대해 설명이 포함 된 이름을 사용하십시오. 타입 시스템을 사용하여 변수의 "종류"또는 "클래스"에 대한 불변 및 메타 정보를 인코딩합니다. 유형.
Joels 기사의 일반적인 요점-잘못된 코드를 잘못 보이게하는 것-은 매우 좋은 원칙입니다. 그러나 버그에 대한 더 나은 보호는 가능한 경우 컴파일러에서 잘못된 코드를 자동으로 감지하는 것입니다.
저는 항상 모든 프로젝트에 헝가리어 표기법을 사용합니다. 수백 개의 서로 다른 식별자 이름을 다룰 때 정말 도움이됩니다.
예를 들어 문자열이 필요한 함수를 호출 할 때 's'를 입력하고 control-space를 누르면 IDE가 's'접두사가 붙은 변수 이름을 정확하게 표시합니다.
또 다른 장점은 서명되지 않은 경우 u 접두사를 사용하고 서명 된 정수인 경우 i를 접두사로 사용하면 잠재적으로 위험한 방식으로 서명 된 것과 서명되지 않은 것을 혼합하는 위치를 즉시 알 수 있습니다.
거대한 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
오래된 코드를 리팩토링하는 현대적인 기술을 사용하면 유형을 변경했기 때문에 기호를 검색하고 교체하는 것이 지루하므로 컴파일러는 유형 변경을 포착하지만 종종 잘못된 범위 사용을 포착하지 않으며 합리적인 명명 규칙이 도움이됩니다.
헝가리 표기법을 올바르게 사용 하지 말아야 할 이유가 없습니다 . 그것은의 인기 없음으로 인해에 대한 장기 실행 백 채찍질하는 것입니다 잘못 사용 , 특히 윈도우의 API에서 헝가리어 표기법.
예전에는 DOS 용 IDE와 유사한 것이 존재하기 전에 (이상하게도 Windows에서 컴파일러를 실행할 수있는 충분한 여유 메모리가 없었기 때문에 DOS에서 개발이 이루어졌습니다) 도움을받지 못했습니다. 변수 이름 위로 마우스를 가져갑니다. (마우스가 있다고 가정합니다.) 처리해야했던 것은 모든 것이 16 비트 정수 (WORD) 또는 32 비트 정수 (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'표시). 그 끔찍한 표기법이 확장되어 리터 사연 P 문자열 ointer이 접두사 된 LP를 , 간단하고 malloc이 있었다 문자열 구별 할 수 있습니다.
이런 종류의 반발이 있었다는 것은 놀라운 일이 아닙니다.
헝가리 표기법은 컴파일 타임 유형 검사없이 언어에서 유용 할 수 있습니다. 이는 개발자가 특정 변수가 사용되는 방식을 신속하게 기억할 수 있도록하기 때문입니다. 성능이나 동작에는 영향을주지 않습니다. 코드 가독성을 향상시키기위한 것이며 대부분 취향과 코딩 스타일의 문제입니다. 바로 이런 이유로 많은 개발자들에 의해 비판을 받고 있습니다. 모든 사람이 뇌에 동일한 배선을 가지고있는 것은 아닙니다.
컴파일 타임 유형 검사 언어의 경우 대부분 쓸모가 없습니다. 몇 줄 위로 스크롤하면 선언과 유형이 표시됩니다. 전역 변수 또는 코드 블록이 둘 이상의 화면에 걸쳐있는 경우 심각한 디자인 및 재사용 성 문제가 있습니다. 따라서 비판 중 하나는 헝가리 표기법을 사용하면 개발자가 잘못된 디자인을 사용하고 쉽게 벗어날 수 있다는 것입니다. 이것은 아마도 미움을받는 이유 중 하나 일 것입니다.
반면에 컴파일 타임 유형 검사 언어조차도 헝가리 표기법 ( void 포인터 또는 win32 API의 HANDLE) 의 . 이것들은 실제 데이터 유형을 난독 화하고 거기에서 헝가리 표기법을 사용하는 장점이있을 수 있습니다. 그러나 빌드시 데이터 유형을 알 수 있다면 적절한 데이터 유형을 사용하지 않는 것이 좋습니다.
일반적으로 헝가리 표기법을 사용하지 않는 어려운 이유는 없습니다. 좋아요, 정책 및 코딩 스타일의 문제입니다.
Python 프로그래머로서 Hungarian Notation은 매우 빠르게 분리됩니다. 파이썬에서는 어떤 것이 문자열 인지 상관하지 않습니다 . 문자열 처럼 작동 할 수 있는지 (즉 ___str___(), 문자열을 반환하는 메서드가 있는지) 관심이 있습니다.
예를 들어, foo가 정수 12라고 가정 해 보겠습니다.
foo = 12
헝가리 표기법은 정수를 나타 내기 위해 iFoo 또는 다른 이름으로 호출해야한다는 것을 알려줍니다. 그래서 나중에 그것이 무엇인지 알 수 있습니다. Python을 제외하고는 작동하지 않거나 오히려 의미가 없습니다. Python에서는 사용할 때 원하는 유형을 결정합니다. 문자열을 원합니까? 다음과 같이하면 :
print "The current value of foo is %s" % foo
%s-문자열에 유의하십시오 . Foo는 문자열이 아니지만 %연산자는 foo.___str___()결과를 호출 하고 사용합니다 (존재한다고 가정). foo여전히 정수이지만 문자열을 원하면 문자열로 취급합니다. 플로트를 원하면 플로트로 취급합니다. Python과 같이 동적으로 유형이 지정된 언어에서 Hungarian Notation은 의미가 없습니다. 사용하기 전까지는 어떤 유형이 무엇인지는 중요하지 않기 때문에 특정 유형이 필요한 경우 해당 유형으로 캐스트해야합니다 (예 :float(foo) ) 때를 그걸 써.
PHP와 같은 동적 언어에는 이러한 이점이 없습니다. PHP는 거의 아무도 기억하지 않은 모호한 규칙 집합을 기반으로 백그라운드에서 '올바른 일'을 수행하려고하므로 예기치 않게 치명적인 혼란이 발생하는 경우가 많습니다. 이 경우, $files_count또는 같은 일종의 명명 메커니즘$file_name , 편리 할 수 있습니다.
제 생각에 헝가리 표기법은 거머리와 같습니다. 과거에는 유용했거나 적어도 유용 해 보였을 수도 있지만, 요즘에는 많은 이점을 얻기 위해 많은 추가 타이핑 일뿐입니다.
.ToString()모든 것을 인쇄 할 수 있도록 구현합니다
IDE는 유용한 정보를 제공해야합니다. 헝가리어는 IDE가 훨씬 덜 발전했을 때 어떤 종류의 (많지는 않지만 일종의) 의미를 만들었을 수 있습니다.
프로그래머가 아닌 엔지니어로서 저는 Apps Hungarian의 장점에 대한 Joel의 기사 "Making Wrong Code Look Wrong"을 즉시 읽었습니다 . 공학, 과학 및 수학이 하위 및 위 첨자 기호 (예 : 그리스 문자, 수학 연산자 등)를 사용하여 방정식과 공식을 나타내는 방식 을 모방 하기 때문에 Apps Hungarian을 좋아합니다. Newton 's Law of Universal Gravity의 특정 예를 살펴 보겠습니다 . 먼저 표준 수학적 표기법에서 다음으로 Apps Hungarian 의사 코드에서 :
frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)
수학적 표기법에서 가장 눈에 띄는 기호는 변수에 저장된 정보 의 종류 를 나타내는 것 입니다 : 힘, 질량, 위치 벡터 등. 아래 첨자는 두 번째 바이올린을 연주하여 명확히합니다. 위치가 무엇입니까? 이것이 바로 Apps Hungarian이하는 일입니다. 먼저 변수에 저장된 종류 를 말한 다음 세부 사항에 대해 알려줍니다. 가장 가까운 코드에 대해 수학적 표기법을 얻을 수 있습니다.
명확하게 강력한 타이핑은 Joel의 에세이에서 안전 대 안전하지 않은 문자열 예제를 해결할 수 있지만 위치 및 속도 벡터에 대해 별도의 유형을 정의하지는 않습니다. 둘 다 크기가 3 인 이중 배열이며 한쪽에하려는 모든 것이 다른 쪽에도 적용될 수 있습니다. 또한 위치와 속도를 연결하거나 (상태 벡터를 만들기 위해) 내적을 취하는 것이 완벽하지만 아마도 추가하지 않는 것이 좋습니다. 타이핑이 처음 두 개를 허용하고 두 번째를 금지하는 방법은 무엇이며 이러한 시스템은 보호하려는 모든 가능한 작업으로 어떻게 확장됩니까? 타이핑 시스템에서 모든 수학 및 물리학을 기꺼이 인코딩하지 않는 한.
무엇보다도 Matlab과 같은 약한 유형의 고수준 언어 나 Fortran 77 또는 Ada와 같은 오래된 언어로 많은 엔지니어링이 수행됩니다.
따라서 멋진 언어가 있고 IDE와 Apps Hungarian이 도움이되지 않는다면 잊어 버리는 사람들이 많을 것입니다. 하지만 저에게는 약하거나 동적으로 입력되는 언어로 작업하는 초보 프로그래머보다 나쁘기 때문에 Apps Hungarian을 사용하면없는 것보다 더 나은 코드를 더 빨리 작성할 수 있습니다.
대부분의 최신 IDE는 엄청나게 중복되고 쓸모가 없으며 유형을 명확하게 만드는 작업을 잘 수행합니다.
게다가-나에게-intI, strUserName 등을 보는 것은 성가신 일입니다. :)
Im 내 경험으로는 다음과 같은 이유로 나쁩니다.
1-변수의 유형을 변경해야하는 경우 (즉, 32 비트 정수를 64 비트 정수로 확장해야하는 경우) 모든 코드를 중단합니다.
2-유형이 이미 선언에 있거나 실제 유형이 처음에 그렇게 중요하지 않아야하는 동적 언어를 사용하기 때문에 이것은 쓸모없는 정보입니다.
또한 일반 프로그래밍 (즉, 함수를 작성할 때 일부 변수의 유형이 결정되지 않는 함수)을 허용하는 언어 또는 동적 유형 지정 시스템 (즉, 컴파일 시간에 유형이 결정되지 않는 경우)을 사용하는 경우 이름을 어떻게 지정 하시겠습니까? 변수? 그리고 대부분의 현대 언어는 제한된 형식이더라도 둘 중 하나를 지원합니다.
에서 Spolsky 조엘의 제작 잘못된 코드 룩 잘못된 그는 무엇을 모두하는 것은 (그 시스템 헝가리어를 호출) 헝가리어 표기법이 정말 (그는 애플 리케이션 헝가리어를 부르는)로 의도 된 것이 아닙니다으로 생각한다고 설명한다. 이 토론을 보려면 헝가리입니다 제목까지 아래로 스크롤합니다 .
기본적으로 Systems Hungarian은 쓸모가 없습니다. 컴파일러 및 / 또는 IDE가 알려주는 것과 동일한 내용을 알려줍니다.
Apps Hungarian은 변수가 의미하는 바를 알려주며 실제로 유용 할 수 있습니다.
컨트롤 목록이 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의 기사는 훌륭하지만 한 가지 중요한 점을 생략 한 것 같습니다.
헝가리어는 코드베이스 전체에서 특정 '아이디어'(종류 + 식별자 이름)를 고유하거나 거의 고유하게 만듭니다.
코드 유지 관리를 위해 엄청납니다. 이는 '아이디어'에 대한 모든 언급을 찾기 위해 좋은 ol '한 줄 텍스트 검색 (grep, findstr,'모든 파일에서 찾기 ')을 사용할 수 있음을 의미합니다.
코드를 읽는 방법을 아는 IDE가 있는데 왜 이것이 중요할까요? 그들은 아직 잘하지 못하기 때문입니다. 이것은 작은 코드베이스에서는보기 어렵지만 큰 코드에서는 분명합니다. '아이디어'가 주석, XML 파일, Perl 스크립트 및 소스 제어 외부 (문서, 위키, 버그 데이터베이스)에서 언급 될 수있는 경우입니다.
여기에서도 약간주의해야합니다. 예를 들어 C / C ++ 매크로에서 토큰 붙여 넣기는 식별자에 대한 언급을 숨길 수 있습니다. 이러한 경우는 코딩 규칙을 사용하여 처리 할 수 있으며 어쨌든 코드베이스에서 소수의 식별자에만 영향을 미치는 경향이 있습니다.
추신 : 유형 시스템과 헝가리어 사용에 대한 요점-둘 다 사용하는 것이 가장 좋습니다. 컴파일러가 당신을 위해 그것을 잡을 수 없다면 잘못된 코드가 필요합니다. 컴파일러가 그것을 잡도록 만드는 것이 불가능한 경우가 많이 있습니다. 그러나 가능한 경우-네, 대신하십시오!
그러나 타당성을 고려할 때 유형 분할의 부정적인 영향을 고려하십시오. 예를 들어 C #에서 'int'를 내장되지 않은 유형으로 래핑하면 큰 결과가 발생합니다. 따라서 일부 상황에서는 의미가 있지만 전부는 아닙니다.
유형이 한 값을 다른 값과 구별하는 모든 것이라면 한 유형을 다른 유형으로 변환하기위한 것일 수 있습니다. 유형간에 변환되는 동일한 값이있는 경우 변환 전용 함수에서이 작업을 수행해야합니다. (헝가리 인 VB6 남은 사람들은 단순히 JSON 개체를 역 직렬화하는 방법을 알아낼 수 없거나 nullable 형식을 선언하거나 사용하는 방법을 제대로 이해할 수 없기 때문에 모든 메서드 매개 변수에 문자열을 사용하는 것을 보았습니다. ) 헝가리어 접두사이며 하나에서 다른 것으로의 변환이 아닙니다. 그러면 의도를 자세히 설명해야합니다.
나는 헝가리 표기법이 사람들을 변수 이름으로 게으르게 만든다는 것을 발견했습니다. 그들은 그것을 구별 할 무언가가 있고 그 목적에 대해 자세히 설명 할 필요가 없다고 느낍니다. 이것은 일반적으로 헝가리 표기 코드 대 현대에서 찾을 수있는 것입니다. sSQL 대 groupSelectSql ( 또는 이전 개발자가 입력 한 ORM을 사용하기 때문에 일반적으로 sSQL이 전혀 없습니다. ), sValue 대 formCollectionValue ( 또는 일반적으로 sValue가 없습니다. MVC에 있고 모델 바인딩 기능을 사용해야하기 때문입니다 ), sType 대 publishSource 등.
가독성이 될 수 없습니다. 나는 다른 사람들을 합친 것보다 더 많은 sTemp1, sTemp2 ... sTempN이 주어진 헝가리 VB6에서 남은 것을 본다.
이것은 2 번의 덕택이며 이는 거짓입니다.
주인의 말 :
http://www.joelonsoftware.com/articles/Wrong.html
평소처럼 흥미로운 독서.
추출물 :
"누군가, 어디 선가 Simonyi의 논문에서"type "이라는 단어를 사용했고, 컴파일러가 수행하는 유형 검사처럼 유형 시스템 에서처럼 클래스와 같은 유형을 의미한다고 생각했습니다. 그는 그렇게하지 않았습니다. 그는 매우 신중하게 설명했습니다. "유형"이라는 단어가 정확히 의미했지만 도움이되지 않았습니다. 손상이 발생했습니다. "
"하지만 Apps Hungarian에는 여전히 막대한 가치가 있습니다. 코드의 배열을 증가시켜 코드를 더 쉽게 읽고, 쓰고, 디버그하고, 유지 관리 할 수 있으며, 가장 중요한 것은 잘못된 코드를 잘못 보이게 만든다는 점입니다."
Joel On Software를 읽기 전에 시간이 있는지 확인하십시오. :)
몇 가지 이유:
나는 모든 사람들이 그것에 대해 광적으로 반대한다고 생각하지 않습니다. 정적 유형이없는 언어에서는 매우 유용합니다. 유형에 아직없는 정보를 제공하는 데 사용되는 경우 확실히 선호합니다. C에서와 마찬가지로 char * szName 은 변수가 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에서 다른 유형 / 크기의 악명 높은 lparam / wparam, Win32에서 동일) ).
따라서 이러한 남용과 M $의 사용으로 인해 쓸모없는 것으로 간주되었습니다.
제 작업에서 우리는 Java로 코딩하지만 창립자는 MFC 세계에서 왔기 때문에 비슷한 코드 스타일을 사용합니다 (중괄호 정렬,이게 좋아요!, 메쏘드 이름에 대문자, 익숙합니다. m_와 같은 접두사를 클래스 멤버 (필드 ), s_에서 정적 멤버 등).
그리고 그들은 모든 변수에 그 유형을 보여주는 접두사가 있어야한다고 말했습니다 (예 : BufferedReader의 이름은 brData입니다). 유형이 변경 될 수 있지만 이름이 뒤 따르지 않거나 코더가 이러한 접두사를 사용하는 데 일관성이 없기 때문에 나쁜 생각으로 표시됩니다 (저는 aBuffer, theProxy 등도 볼 수 있습니다!).
개인적으로 유용하다고 생각되는 몇 가지 접두사를 선택했습니다. 가장 중요한 것은 b가 부울 변수 접두사로 사용하는 것입니다. if (bVar) 입니다 (일부 값을 true 또는 false로 자동 변환하지 않음). C로 코딩 할 때 malloc으로 할당 된 변수에 접두사를 사용했습니다. 기타.
그래서 기본적으로 저는이 표기법 전체를 거부하지 않고 제 필요에 맞는 것을 취했습니다.
물론 어떤 프로젝트 (작업, 오픈 소스)에 기여할 때, 저는 그저 규칙을 그대로 사용합니다!