헝가리어 표기법을 사용하지 않으면 어떤 이점이 있습니까?

내가 고투하는 것 중 하나는 헝가리어 표기법을 사용하지 않는 것입니다. 나는 하지 않습니다 단지 그것이 어떤 종류의 볼 수있는 변수 정의로 이동하고 싶지. 프로젝트가 광범위 해지면 'bool'이라는 접두사가 붙은 변수를보고 0/1 값 대신 true / false 를 찾고 있다는 것을 알면 좋습니다 .

또한 SQL Server에서 많은 작업을 수행합니다. 저장 프로 시저 앞에 'sp'를 붙이고 테이블에 'tbl'을 붙여서 데이터베이스의 모든 변수를 언급하지는 않습니다.

나는 아무도 헝가리어 표기법을 사용하고 싶지 않다는 것을 어디에서나 볼 수 있습니다. 내 질문은 헝가리어 표기법을 사용 하지 않으면 어떤 이점 이 있으며, 대다수 개발자가 전염병처럼 피하는 이유는 무엇입니까?

원래 의도 ( http://www.joelonsoftware.com/articles/Wrong.html 및 http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids 참조 )가 잘못 이해되어 왔기 때문에 ( ab) 사람들이 사용하는 언어가 정적으로 입력되지 않은 경우 변수의 유형을 기억하는 데 도움이됩니다. 정적으로 유형이 지정된 언어에서는 변수의 유형을 알려주기 위해 접두사를 추가 할 필요가 없습니다. 형식화되지 않은 많은 스크립트 언어에서는 도움이 될 수 있지만 종종 다루기 어려워 질 정도로 악용되었습니다. 불행하게도, 헝가리 표기법의 원래 의도로 돌아가는 대신 사람들은 그것을 피해야 할 "악한"것들 중 하나로 만들었습니다.

간단히 말해서 헝가리어 표기법은 변수에 일부 의미론을 붙였습니다. 예를 들어 화면 좌표 (왼쪽, 위쪽, 오른쪽, 아래쪽)가있는 경우 절대 화면 위치가 " abs"인 변수와 " "이있는 창에 상대적인 위치가있는 변수를 접두어로 사용합니다 rel. 그렇게하면 상대 좌표를 절대 위치를 요구하는 메소드에 전달했을 때 모든 독자에게 분명 할 것입니다.

업데이트 (delnan의 의견에 대한 답변으로)

IMHO 악용 된 버전은 다음과 같은 이유로 전염병처럼 피해야합니다.

• 명명이 복잡해집니다. 헝가리어 표기법을 사용하는 경우 접두사가 얼마나 구체적이어야하는지 항상 토론해야합니다. 예를 들면 다음 listboxXYZ과 같습니다. 또는 MyParticularFlavourListBoxXYZ.
• 변수가 무엇인지 이해하지 않고도 변수 이름을 더 길게 만듭니다.
• 긴 접두사를 피하기 위해 약어로 단축되고 각 약어가 무엇을 의미하는지 알기 위해서는 사전이 필요합니다. A는 ui부호없는 정수? 참조되지 않은 계산 된 인터페이스? 사용자 인터페이스와 관련이 있습니까? 그리고 그 것들이 길어질 수 있습니다 . 나는 정확한 유형의 var를 전달해야하지만 실제로는 미스터리 인 것으로 보이는 무작위로 보이는 15 개 이상의 임의의 문자 접두어를 보았습니다.
• 그것은 빨리 구식입니다. 변수의 유형을 변경할 때 사람들은 항상 (lol) 변경 사항을 반영하기 위해 접두사를 업데이트하는 것을 잊거나 var가 사용되는 모든 곳에서 코드 변경을 트리거하기 때문에 의도적으로 업데이트하지 마십시오 ...
• "@g"로 인해 코드에 대해 이야기하는 것이 복잡합니다. 헝가리어 표기법이있는 변수 이름은 일반적으로 발음하기 어려운 알파벳 수프입니다. 이름을 '말할'수 없기 때문에 가독성과 토론 코드가 금지됩니다.
• ... 지금 당장 기억할 수없는 것 이상. 어쩌면 내가 학대당한 헝가리 표기법을 오랫동안 다루지 않아도되어서 기뻤을 수도 있습니다 ...

헝가리어 표기법은 현대의 프로그래밍 환경과 타우 톨 로지 형태의 명명 반 패턴입니다 .

이점과 추가 유지 관리 오버 헤드없이 정보를 쓸모없이 반복합니다. int와 같은 다른 유형으로 변경하면 어떻게됩니까? long이제 모든 변수의 이름을 바꾸기 위해 전체 코드베이스를 검색하고 바꿔야합니다.

DRY 원칙을 위반합니다. 테이블이 테이블임을 상기시키기 위해 약어로 데이터베이스 테이블의 접두어를 붙여야하는 경우, 테이블을 의미 적으로 설명 적으로 충분하게 명명하지 않아도됩니다. 이 작업을 수행하는 다른 모든 작업에도 동일하게 적용됩니다. 그것은 단지 추가 타이핑이며 현대적인 개발 환경에서 이득을 얻거나 이익을 얻지 않습니다.

Wikipedia 에는 헝가리 표기법의 장단점이 있으므로이 질문에 대한 가장 포괄적 인 답변을 제공 할 수 있습니다. 주목할만한 opinons는 또한 매우 흥미로운 읽기입니다.

헝가리 표기법을 사용 하지 않는 이점 은 기본적으로 단점을 피하는 것입니다.

• 컴파일러에서 형식 검사를 수행하면 헝가리어 표기법이 중복됩니다. 유형 검사를 제공하는 언어 용 컴파일러는 변수 사용이 해당 유형과 자동으로 일치하는지 확인합니다. 육안 검사는 중복되며 사람의 실수에 따라 달라질 수 있습니다.

• 모든 최신 통합 개발 환경은 요청시 가변 유형을 표시하고 호환되지 않는 유형을 사용하는 작업에 자동으로 플래그를 지정하여 표기법을 크게 사용하지 않습니다.

• 헝가리 표기법은 테이블의 기본 키의 일부인 a_crszkvc30LastNameCol데이터베이스 열 LastName형식 의 내용을 보유하는 상수 참조 인수와 같이 여러 속성을 나타내는 데 사용되는 경우 혼동됩니다 varchar(30).

• 코드를 수정하거나 이식 할 때 불일치가 발생할 수 있습니다. 변수 유형이 변경되면 변수 이름의 장식이 새 유형과 일치하지 않거나 변수 이름을 변경해야합니다. 특히 잘 알려진 예는 표준 WPARAM유형이며 wParam많은 Windows 시스템 함수 선언에서 수반되는 형식 매개 변수입니다. 'w'는 'word'를 나타내며, 여기서 'word'는 플랫폼 하드웨어 아키텍처의 기본 단어 크기입니다. 원래 16 비트 워드 아키텍처에서는 16 비트 유형이지만 운영 체제의 최신 버전에서는 32 비트 워드 아키텍처에서는 32 비트로, 64 비트 워드 아키텍처에서는 64 비트로 변경되었습니다. 원래 이름 (실제 기본 유형은UINT_PTR즉, 포인터를 보유하기에 충분히 큰 부호없는 정수). 시맨틱 임피던스, 따라서 플랫폼 간 플랫폼에서 프로그래머의 혼란과 불일치는 'w'가 서로 다른 환경에서 16 비트를 의미한다고 가정합니다.

• 대부분의 경우 변수의 사용을 아는 것은 그 유형을 아는 것을 의미합니다. 또한 변수의 사용법을 알 수없는 경우 변수 유형에서 추론 할 수 없습니다.

• 헝가리어 표기법은 프로그래머가 전체 유형 지정자를 먼저 입력해야하기 때문에 변수 이름 완성을 지원하는 풍부한 기능의 코드 편집기를 사용하는 이점을 크게 줄입니다.

• 불필요 한 유형 및 범위 접두사로 변수의 목적을 난독 화함으로써 코드를 읽기 어렵게 만듭니다.

• 추가 유형 정보가 더 설명적인 이름을 대체하지 못할 수 있습니다. 예를 들어 sDatabase독자에게 그것이 무엇인지 말하지 않습니다. databaseName더 설명적인 이름 일 수 있습니다.

• 이름이 충분히 설명적인 경우 추가 유형 정보가 중복 될 수 있습니다. 예를 들어 firstName문자열 일 가능성이 높습니다. 따라서 이름을 지정 sFirstName하면 코드가 복잡해집니다.

나는 불필요한 기술적 소음을 싫어하기 때문에이 표기법을 사용하지 않습니다. 나는 항상 어떤 유형을 다루는 지 알고 있으며 도메인 모델에서 깨끗한 언어를 원하지만 주로 정적이고 강력한 유형의 언어로 작성합니다.

MS SQL Server 관련 문제 :

접두사가 'sp_'인 저장 프로시 저는 생성 된 것이 아닌 마스터 데이터베이스에서 먼저 검색됩니다. 이로 인해 저장 프로 시저 실행이 지연 될 수 있습니다.

헝가리어를 사용하지 않는 IMO의 가장 큰 장점은 의미있는 이름 을 사용해야한다는 사실 입니다. 변수의 이름을 올바르게 지정하는 경우 어떤 유형의 변수인지 즉시 알고 있거나 잘 설계된 시스템에서 상당히 빨리 추론 할 수 있어야합니다. 당신에 의존해야하는 경우 str또는 bln전부 또는 더 나쁜 obj가난한 변수 일반적으로 이름이나 의미를 전달하는 것이 너무 일반적인 중 하나 - 변수가 어떤 타입을 알고 접두사, 나는 그것이 명명 문제를 나타냅니다 주장 할 것이다.

아이러니하게도, 개인적 경험에서 헝가리어가 사용한 주요 시나리오는 "카고 컬트 (cargo-cult)"프로그래밍 (즉, 다른 코드에서 사용하기 때문에 계속 사용하자) 또는 VB.NET에서 언어가 대소 문자를 구분 (예를 들어, Person oPerson = new Person당신이 사용할 수 없기 때문에 Person person = new Person그리고 Person p = new Person너무 모호); 또한 "는"또는 "내"대신 (에서와 같이 접두사를 본 적이 Person thePerson = new Person또는 추악한 Person myPerson = new Person)에서 특정 사건을.

헝가리어를 사용 하는 유일한 시간은 ASP.NET 컨트롤에 대한 경향이 있으며 실제로 선택의 문제입니다. 나는 타이핑 TextBoxCustomerName하거나 CustomerNameTextBox간단한 것보다 매우 추악 txtCustomerName하지만, 심지어 "더러운"느낌이 든다. 기분 일부 동일한 데이터를 표시하는 여러 컨트롤이있을 수있는 명명 규칙의 종류 제어에 사용되어야한다.

SQL Server를 언급 한 이후로 SQL Server에 집중하겠습니다. 테이블 앞에 'tbl'을 넣을 이유가 없습니다. 모든 tSQL 코드를보고 사용 방법으로 테이블을 구별 할 수 있습니다. 당신은 않을 것이다 Select from stored_procedure.또는 Select from table(with_param)당신은 UDF 것 또는 같은 Execute tblTableOrViewName저장 프로 시저있다.

테이블은 뷰와 혼동 될 수 있지만 테이블이 사용되는 방식과 관련하여; 차이점이 없으므로 요점은 무엇입니까? 헝가리어 표기법을 사용하면 SSMS (테이블 또는 뷰 아래)에서 조회 시간을 절약 할 수 있지만 그게 전부입니다.

변수는 문제를 일으킬 수 있지만 선언해야하며 실제로 변수를 사용하여 선언문에서 얼마나 멀리 떨어져 있습니까? 매우 긴 프로 시저를 작성하지 않는 한 몇 줄을 스크롤하면 큰 문제가되지 않습니다. 긴 코드를 약간 나누는 것이 좋습니다.

당신이 설명하는 것은 고통이지만, 헝가리 표기법 솔루션은 실제로 문제를 해결하지 못합니다. 다른 사람의 코드를보고 변수 유형이 변경 될 수 있으며 이제 변수 이름을 변경해야합니다. 한 가지만 더 잊어 버리십시오. 그리고 VarChar를 사용하면 어쨌든 선언문을보고 크기를 알아야합니다. 설명적인 이름은 아마도 더 나아질 것입니다. @PayPeriodStartDate는 그 자체를 설명합니다.

추가해야 할 또 다른 사항은 .NET과 같은 전체 프레임 워크에 어떤 약어를 사용 하시겠습니까? 예, btn버튼을 txt나타내고 텍스트 상자 를 나타내는 것은 매우 간단합니다 . 그러나 당신은 무엇을 염두에두고 StringBuilder있습니까? strbld? 무엇에 대해 CompositeWebControl? 다음과 같은 것을 사용하십니까?

CompositeWebControl comWCMyControl = new CompositeWebControl();

헝가리 표기법의 비 효율성 중 하나는 더 크고 더 큰 프레임 워크를 가짐으로써 이제는 비표준 접두사를 점점 더 많이 배워야했기 때문에 추가 혜택을 제공 할뿐만 아니라 개발자에게 더 많은 복잡성을 추가한다는 것이 입증되었습니다.

헝가리어 표기법은 사물을 보는 방식으로 불충분하게 강력한 유형 시스템을 돌아 다니는 데 도움이됩니다. 자신 만의 형식을 정의 할 수있는 언어에서는 예상되는 동작을 인코딩하는 새 형식을 만드는 것이 비교적 간단합니다. Joel Spolsky의 헝가리 표기법 (Hungarian Notation)에 대한 글에서 그는 변수 나 함수가 안전하지 않은 (us) 또는 안전하지만 (s) 시각적으로 확인하는 프로그래머에 의존한다는 것을 표시함으로써 가능한 XSS 공격을 탐지하기 위해이를 사용하는 예를 제공합니다. 대신 확장 가능한 형식 시스템을 사용하는 경우 UnsafeString과 SafeString의 두 가지 새 형식을 만든 다음 적절하게 사용할 수 있습니다. 보너스로, 인코딩 유형은 다음과 같습니다.

SafeString encode(UnsafeString)

UnsafeString의 내부에 액세스하지 못하거나 다른 변환 함수를 사용하는 것이 UnsafeString에서 SafeString으로가는 유일한 방법이됩니다. 모든 출력 함수가 SafeString의 인스턴스 만 가져 오면 이스케이프되지 않은 문자열 [StringingSafeString (someUnsafeString.ToString ())]과 같은 변환을 사용하여 이스케이프 처리되지 않은 문자열을 출력하는 것이 불가능 해집니다.

타입 시스템이 코드를 제대로 검사 할 수있게하는 것이 왜 직접 시도하는 것보다 우월한 지 또는이 경우에는 눈에 띄는 지 분명해야합니다.

물론 C와 같은 언어에서는 int가 int라는 것이 int이고 int가 int라는 것을 망쳤습니다. 항상 구조체로 게임을 할 수는 있지만 개선 여부에 대해서는 논란의 여지가 있습니다.

헝가리어 표기법에 대한 다른 해석과 마찬가지로 IE는 변수 유형을 접두어로 사용하는 것은 어리석은 일이며 countOfPeople과 같은 의미있는 변수 대신 uivxwFoo 이름 지정 변수와 같은 게으른 관행을 권장합니다.

헝가리어 표기법은 정적으로 타이핑 된 언어에서는 거의 쓸모가 없습니다. 마우스를 변수 위에 놓거나 다른 방법으로 변수 유형을 표시하는 것은 기본 IDE 기능입니다. 또한 형식 유추가없는 경우 선언 된 위치에서 몇 줄을 보면 형식이 무엇인지 확인할 수 있습니다. 유형 추론의 요점은 유형의 소음이 모든 곳에서 반복되지 않도록하는 것이므로 헝가리어 표기법은 일반적으로 유형 추론이있는 언어에서 나쁜 것으로 간주됩니다.

동적으로 입력되는 언어에서는 때로는 도움이 될 수 있지만 나에게는 단조로운 느낌이 듭니다. 당신은 이미 정확한 도메인 / 코 도메인으로 제한되는 기능을 포기했습니다. 모든 변수가 헝가리 표기법으로 명명 된 경우 유형 시스템이 제공 한 것을 재현하는 것입니다. 헝가리어 표기법에서 정수 또는 문자열이 될 수있는 다형성 변수를 어떻게 표현합니까? "IntStringX"? "IntOrStringX"? 헝가리어 표기법을 사용한 유일한 장소는 어셈블리 코드였습니다. 유형 시스템이있는 경우 얻을 수있는 것을 되 찾으려고 노력했기 때문에 처음으로 코딩 한 것입니다.

어쨌든, 사람들이 변수 이름을 짓는 것을 덜 신경 쓰면 코드는 여전히 이해할 수 없을 것입니다. 개발자는 스타일 및 변수 이름과 같은 작업에 너무 많은 시간을 낭비하며 하루 종일 언어에 따라 완전히 다른 규칙을 가진 수많은 라이브러리를 얻을 수 있습니다. 변수 이름이없고 고유 식별자 만 있고 변수에 제안 된 이름이있는 상징적 인 (예 : 텍스트 기반이 아닌) 언어를 개발하고 있습니다 (그러나 대부분의 변수에는 여전히 합리적인 이름 이 없기 때문에 제안 된 이름 이 없습니다) 그들); 신뢰할 수없는 코드를 감사 할 때는 변수 이름에 의존 할 수 없습니다.

이 경우 평소처럼 다른 참가자의 답변을 읽기 전에 답변을 게시합니다. 

나는 당신의 비전에서 세 가지 "버그"를 본다 : 

1) 변수 / 매개 변수 / 속성 / 열의 유형을 알고 싶다면 마우스를 가져 가거나 클릭하면 가장 현대적인 IDE에서 표시됩니다. 어떤 도구를 사용하고 있는지 모르겠지만 지난번에이 기능을 제공하지 않은 환경에서 20 세기에 근무해야했던 언어는 COBOL, 죄송합니다. 내가 왜 떠 났는지 이해하지 못했습니다. 

2 / 개발주기 동안 유형이 변경 될 수 있습니다. 32 비트 정수는 어떤 시점에서 64 비트 정수가 될 수 있습니다. 프로젝트 시작시 감지되지 않은 좋은 이유가 있습니다. 따라서 intX의 이름을 longX로 바꾸거나 잘못된 유형을 가리키는 이름으로 남겨 두는 것은 업장이 아닙니다. 

3) 당신이 요구하는 것은 실제로 중복입니다. 중복성은 디자인 패턴이나 습관이 그리 좋지 않습니다. 인간조차도 너무 많은 중복성을 꺼려합니다. 인간조차도 너무 많은 중복성을 꺼려합니다. 

헝가리어가 절실히 필요한 것은 증상 이라고 생각 합니다. 너무 많은 전역 변수
의 증상 . 또는 너무 길어서 기능을 수행 할 수없는 증상 .

변수 정의가 보이지 않으면 일반적으로 문제가 있습니다.
그리고 함수가 기억에 남는 규칙을 따르지 않으면 다시 큰 문제가 발생합니다.

그게 .. 많은 직장이 그 이유를 설명하는 이유가 될 것 같아요.

그것은 그것을 필요 로 하는 언어 에서 시작되었습니다 . 글로벌 변수의 시간에 보난자 . (대안이 없기 때문에) 그것은 우리를 잘 섬겼습니다.

우리가 오늘을 위해이 유일한 사용은입니다 Spolsky 조엘의 하나 . 안전성 과 같은 변수의 특정 속성
을 추적 합니다.

( 예 : “변수 safeFoobar에 SQL 쿼리에 주입되는 녹색 표시등이 있습니까?
— 호출 될 safe때 예)

다른 답변은 변수에 마우스를 올려 놓을 때 변수 유형을 보는 데 도움이되는 편집기 기능에 대해 이야기했습니다. 내 생각에, 이것들도 코드 위생 에 문제가 있습니다 . 나는 그것들이 다른 많은 기능들과 마찬가지로 리팩토링 만을 위한 곳이라고 생각합니다 (함수 접기와 같은). 새로운 코드에는 사용해서는 안됩니다.

헝가리어 표기법을 사용하지 않는 이유는 다른 포스터에서 잘 다루고 있다고 생각합니다. 나는 그들의 의견에 동의합니다.

데이터베이스에서는 코드에서 거의 사용되지 않지만 네임 스페이스에서 충돌하는 DDL 객체에 헝가리어 표기법을 사용합니다. 주로 이것은 접두어 인덱스와 명명 된 제약 조건 유형 (PK, UK, FK 및 IN)으로 내려갑니다. 일관된 방법을 사용하여 이러한 개체의 이름을 지정하면 메타 데이터를 쿼리하여 일부 유효성 검사를 실행할 수 있습니다.

이것이 피하는 이유는 DRY를 위반하는 헝가리어 시스템 때문입니다 (접두사는 정확히 컴파일러와 (좋은) IDE가 파생 할 수있는 유형입니다)

앱 헝가리어 OTOH 접두어 는 변수를 사용 합니다 (예 : scrxMouse는 화면의 도끼 좌표로 int, short, long 또는 사용자 정의 유형일 수 있습니다 (typedefs를 사용하면 쉽게 변경할 수 있습니다)).

시스템에 대한 오해는 헝가리 인을 모범 사례로 파괴 한 것입니다

C #에서 이와 같은 방법이 있다고 가정 해 봅시다.

int GetCustomerCount()
{
    // some code
}

이제 코드에서 다음과 같이 호출합니다.

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

INT는 우리에게 매우 말하지 않습니다. 무언가가 int라는 단순한 사실은 그 안에 무엇이 들어 있는지 알려주지 않습니다. 이제 대신 다음과 같이 호출한다고 가정 해 봅시다.

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

이제 변수의 목적이 무엇인지 알 수 있습니다. 우리가 그것이 int인지 아는 것이 중요할까요?

그러나 헝가리어의 원래 목적은 다음과 같이하는 것입니다.

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

c 가 무엇을 의미 하는지 아는 한 괜찮 습니다. 그러나 표준 접두사 테이블이 있어야하고 모든 사람이 접두사를 알아야하며 새로운 사람들은 코드를 이해하기 위해이를 알아야합니다. 반면 customerCount또는 countOfCustomers첫눈에 매우 분명하다.

Option Strict OnVB6과 이전 (및 VB .NET이있는 VB Option Strict Off)에서 VB가 유형을 강제 하기 때문에 헝가리어는 VB에 어떤 목적이 있었 으므로 다음과 같이 할 수 있습니다.

Dim someText As String = "5"
customerCount = customerCount + someText

이것은 나쁘지만 컴파일러는 그렇게 말하지 않습니다. 따라서 헝가리어를 사용했다면 적어도 무슨 일이 있었는지에 대한 지표가있을 것입니다.

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

정적 입력을 사용하는 .NET에서는 필요하지 않습니다. 그리고 헝가리는 좋은 이름을 대신하기 위해 너무 자주 사용되었습니다. 헝가리어를 잊고 대신 좋은 이름을 선택하십시오.

나는 많은 좋은 주장을 발견했지만 인간 공학은 보지 못했습니다.

예전에는 문자열, int, bool 및 float 만 있으면 sibf 문자로 충분했을 것입니다. 그러나 문자열 + 짧음으로 문제가 시작됩니다. 접두사에 전체 이름을 사용하거나 문자열에 str_name을 사용합니까? (이름은 거의 항상 문자열이지만 그렇지 않습니까?) Street 클래스는 무엇입니까? 이름이 점점 길어지고 CamelCase를 사용하더라도 유형 접두어가 끝나는 위치와 변수 이름이 시작되는 위치를 구분하기는 어렵습니다.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

좋아요-이미 밑줄을 사용하지 않으면 밑줄을 사용하거나 밑줄을 너무 오래 사용한 경우 CamelCase를 사용할 수 있습니다.

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

그것은 괴물이며 결과적으로 그렇게하면

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

loop-variables 또는와 같은 사소한 경우에는 쓸모없는 접두사를 사용하게됩니다 count. 최근에 카운터에 짧거나 긴 것을 언제 사용 했습니까? 예외를하면 접두사가 필요한지 여부를 생각하면서 시간을 허비하게됩니다.

많은 변수가있는 경우 일반적으로 IDE의 일부인 객체 브라우저에 그룹화됩니다. 이제 40 %가 int의 경우 i_로 시작하고 문자열의 경우 s_의 40 %가 알파벳순으로 정렬되어 이름의 중요한 부분을 찾기가 어렵습니다.

헝가리어 또는 유사한 접미사를 계속 사용하는 한 곳은 동일한 의미 데이터가 데이터 변환과 같은 두 가지 다른 형식으로 존재하는 상황입니다. 여러 측정 단위가 있거나 여러 형식 (예 : 문자열 "123"및 정수 123)이있는 경우 일 수 있습니다.

나는 헝가리어를 다른 사람들에게 강요 하지 않고 강제적으로 사용하지 않는 이유를 발견 했지만 자신의 연습을 결정하기 위해 약간 암시합니다.

프로그램의 소스 코드는 자체적 으로 사용자 인터페이스 이며 알고리즘과 메타 데이터를 관리자에게 표시합니다 . 사용자 인터페이스의 중복성은 죄가 아닌 미덕 입니다. 예를 들어 " The Everyday Things의 디자인 "에있는 그림을 보고, "Push"라고 표시된 문을 잡아 당기는 것처럼 보이고 맥주를 보면 작업자가 중요한 원자로 제어 장치에 해킹 된 것입니다. IDE에서 그것들은 충분하지 않았다.

는 "단지 IDE에 가져가"입니다 하지 만 이유 - 헝가리어를 사용하지 않는 이유 몇몇 사람들이 유용하지 않을 수 있습니다. 마일리지가 다를 수 있습니다.

변수 유형 변경이 어리석은 경우 헝가리어가 유지 관리 부담이 크다는 생각은 얼마나 자주 변수 유형을 변경합니까? 게다가 변수 이름 바꾸기가 쉽습니다.

IDE를 사용하여 모든 발생의 이름을 바꾸십시오. 거위에 대한 답변

헝가리어가 실제로 코드를 신속하게 파악하고 안정적으로 유지 관리하는 데 도움이된다면 사용하십시오. 그렇지 않다면하지 마십시오. 다른 사람들이 당신이 자신의 경험에 대해 틀렸다고 말하면, 아마도 그들이 틀렸을 가능성이 있다고 제안합니다.