시스템 헝가리어 표기법이 여전히 유용한 방법입니까? [닫은]

포럼을 검색했지만 피해야하는 이유와 은색 총알이 아닌 이유 만 찾을 수 없었습니다. 그래서 나는이 질문이 중복이라고 생각하지 않습니다.

거기 VALID 로 사용 해요 내가 시스템 헝가리어 I을 잊다해야하는 이유 이유는?

지금까지 사용하면 다음과 같은 이점이 있습니다.

• 일관된 변수 이름
• 검색하지 않고 유형을 볼 수 있습니다 (지능형이 죽었거나 색인을 생성하는 절반 시간이므로 여전히 유효한 이유입니다)
• 시맨틱은 여전히 ​​이름의 두 번째 부분으로 압축 될 수 있습니다

그리고 다음과 같은 단점이 있습니다.

• 그것은 어떤 사람들을 귀찮게합니다 (왜 그런지 모릅니다)
• 유형이 변경되면 유형이 변수의 이름과 일치하지 않을 수 있습니다 (유효한 이유는 아니며 유형이 거의 변경되지 않으며 "모두 이름 바꾸기"가 있음)

왜:

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

보다 더 나쁜 :

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

나는 (몇 년 전) 그것을 사용했지만 더 이상 사용하지 않습니다. 주된 이유는 대부분의 경력을 쌓아온 강력한 타이핑 (C ++, Java)으로 OO 언어에 불필요하기 때문입니다. 이 언어들에서, 타입을 잘 정의하면, 컴파일러는 타입 안전성을 강제 할 수 있고 강제 할 것입니다. 따라서 모든 이름 접두사는 이름이 길어 지므로 이름을 더 길고 읽기가 어렵습니다.

잘 작성된 OO 프로그램에서 대부분의 변수는 사용자 정의 유형입니다 (참조). 접두사에 동일한 일반 태그 (예 o: "object"등)를 붙이면 아무런 이점도없고 단점 만 있습니다. 그러나 유형 별 태그로 접두사를 붙이면 종종 비슷한 이름을 가진 수천 가지 유형에 대해 다른 약어를 찾으려고 노력합니다. 잘 관리 된 프로그램에서는 전혀 드물지 않습니다).

물론 이것은 비 OO 언어에는 적용되지 않으며 약하거나 동적으로 유형이 지정된 언어에는 적용되지 않을 수 있습니다 (C와는 별도로 경험이 없습니다). 사용 가능한 IntelliSense (또는 그에 상응하는 로컬)가없는 차선책 편집기 / IDE는 아닙니다. 그리고 이것은 단지 2 센트입니다. 따라서 헝가리어 표기법이 팀과 프로젝트에 효과적이라면 그대로 사용하십시오. 중요한 것은 프로젝트가 시작 되기 전에 ( 일관된 코딩 스타일뿐만 아니라) 이것에 동의 하고 항상 일관성을 유지하는 것입니다.

* _{우리의 현재 프로젝트에서 짧은 목록 : 우리가 Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePair와 ChargeType, 다른 사람의 사이에서. 게다가 우리는 또한 Contracts, Countries, Checkouts, Checkins ...를 가지고 있으며 이것은 OP에 의해 "합리적인 크기"라고 부르지 않는 프로젝트에서 단지 문자 C입니다.}

면책 조항 : 저는 실제로 헝가리 인이므로 권한을 가지고이 문제에 대해 말할 수 있다고 생각합니다. ;-)

왜 std::vector<string> vecCityNames;나쁜가요?

프로파일 링에서 도시 이름이 오히려로 유지되어야한다고 표시하면 std::deque해당 유형의 오브젝트를 참조하는 모든 변수 이름이 갑자기 오해의 소지가 있다는 헝가리 표기법의 문제점은 일반적으로 사용됩니다 .

그런 다음 모든 변수의 이름을 바꾸시겠습니까? 큰 프로젝트에서 그렇게 해 본 적이 있습니까? 머피의 도움으로 (그리고 그 사람은 거기에 엄청나게 도움이됩니다.) 어딘가에서 누군가와 같은 변수를 사용했을 것입니다. deqCityNames변경 사항으로 인해 빌드가 깨져서 30 년 동안 코드를 사용하여 수십 년 동안 앉아있는 사람은 아무도 없었습니다. 유독 한 짐승에게 물린 것에 대한 두려움 때문에.

그러나 내가 아는 것에서 Charles Simonyi가 헝가리어를 생각해 낸 방식에서 접두어는 구문 유형이 아닌 변수 의미 론적 사용법을 나타냅니다 . 즉, 도시 이름 목록의 올바른 접두어는 도시 유형에 관계없이 (또는 , 암호가 충분하지 않은 경우 )있을 수 있습니다.listCityNameslstCityNameslist

그러나 복수 ( "이름")이 이미 도시의 무리라는 것을 전달하기 때문에이 접두어는 매우 불필요한 것으로 생각합니다. 결론 :주의해서 식별자를 선택할 때 헝가리어 표기법은 거의 필요하지 않습니다. OTOH, 일반적으로 사용되는 방식은 장기적으로 실제로 코드를 손상시키는 것입니다.

어떤 이유로 든, 여기에있는 기존의 대답은 헝가리 표기법에 대한 근거를 똑바로 밝히지 않고 춤추는 것처럼 보입니다. 헝가리어 표기법은 언어 자체에서 수행하기 어려운 유형 정보 ( 유형 이론적 의미로 ) 를 추가하는 데 유용 합니다 . 일반적으로 헝가리어 표기법 (일반적으로 설명 된대로)이 완전히 불필요한 방식으로 C ++ 또는 Java 유형 시스템을 사용하는 것은 어렵지 않습니다. 이는 아마도 반발을 일으킨 것입니다. 모든 주석에서 이러한 주석을 유지하지만 추가 값이 거의 없거나 전혀 없습니다 (코드가 더 복잡 해져서 해를 입힐 수도 있습니다).

반면에 헝가리어 표기법의 사용을 제한하여 정보를 입력하는 경우 유형 (이론적으로 이론적 인 유형으로 )으로 제한하는 경우 아닌언어에 의해 자연스럽게 캡슐화되면 매우 유용 할 수 있습니다. 예를 들어, C와 C ++는 배열 참조를 포인터 유형으로 전달하지만 배열 참조와 포인터는 서로 다른 연산을 수행해야합니다. 배열은 첫 번째 요소를 넘어서 색인 될 수 있지만 포인터는 그렇지 않아야합니다. 이것은 배열이 인수로 함수에 전달되는 즉시 유형 시스템에 손실되는 유용한 정보입니다. 따라서 우리 그룹에서는 C 및 C ++ 코드에서 변수 이름 주석을 채택하여 포인터 변수가 실제로 단일 요소에 대한 포인터인지 또는 배열에 대한 포인터인지를 구분했습니다. 이 규칙을 채택하면 코드 기반에서 메모리 손상 문제 발생이 크게 줄어 들었습니다.

그것은 어떤 사람들을 귀찮게합니다 (왜 그런지 모릅니다)

그것이 짜증나는 이유는 코드의 시각적 스캔 속도를 늦추는 모든 단일 식별자에 약간의 속도 충돌이 있기 때문입니다. 그것은 mAs입니다.

증오 가 너무 강해 IMO 원하는 방식으로 코드를 작성할 수 있습니다. 나는 단순히 내 코드에서 헝가리어 표기법을 사용하지 않는 것을 선호하며, 다른 사람들의 코드에서 읽거나 작업하지 않아도되는 선택을 선호합니다.

당신은 왜 어떤 사람들이 헝가리어 표기법을 성가 시게하는지 물었습니다. 나는 다른 사람들을 위해 말할 수 없지만 그것이 나를 괴롭힌 이유는 다음과 같습니다.

1. 못 생겼어 헝가리어는 완벽하게 합리적인 이름을 취하고 코드에 해당하는 것을 앞에 붙입니다. 이 코드를 내면화하면 완벽하게 이해할 수 있지만 처음에는 누군가 내 소스 코드에서 C ++ 이름 mangler를 풀어 놓은 것처럼 보입니다.

2. 중복입니다. 변수 선언은 유형을 설정합니다. 변수 이름으로 해당 정보를 반복 할 필요가 없다고 생각합니다. 이는 모든 언어에 해당되는 것은 아닙니다. 예를 들어, Perl 에서 변수 이름 앞에 @ 또는 $ 와 같은 sigils 는 기본적으로 변수 유형을 정의하므로 사용할 수밖에 없습니다.

3. 내가 가지고 있지 않은 문제를 해결합니다. 메서드와 함수는 너무 길어서 로컬 변수 또는 매개 변수의 선언을 찾기가 어려워 야하며 너무 많은 변수를 포함해서는 안되며 무엇이 무엇인지 추적하는 데 어려움이 있습니다. 지역 변수를 사용하는 코드에 가까운 지역 변수를 선언하면이 점에서도 도움이됩니다. 과거의 C 컴파일러는 함수의 시작 부분에 모든 지역 변수를 선언해야하지만 그 한계는 오래 전에 제거되었습니다.

4. 불완전합니다. 헝가리어 표기법은 유형 시스템이없는 언어 (BCPL)를 위해 발명되었으며 나중에 상당히 제한된 수의 기본 유형을 가진 언어 (C)에서 널리 사용되었습니다. IMO는 광범위한 유형 시스템을 가진 C ++ 또는 Java와 같은 언어에서는 제대로 작동하지 않습니다. char []와 같은 기본 유형이지만 클래스는 아닌 변수의 유형을 나타 내기 위해 접두사를 사용하고 싶은 이유는 무엇입니까? 또는 vec클래스 와 같은 접두사를 발명하기 시작하면 클래스 계층 구조와 평행 한 접두사 계층 구조로 끝납니다. 그것이 당신에게 호소한다면, 당신은 그것을 환영합니다. 그것에 대해 생각하면 두통이 생깁니다.

5. 적어도 내가 이해하는 것처럼 모호 합니다. 차이 무엇 szFoo과 pszFoo? 첫 번째는 0으로 끝나는 문자열이고 두 번째는 0으로 끝나는 문자열에 대한 포인터입니다. 그러나 C 또는 C ++에서 내가 아는 한 문자열 변수는 실제로 포인터이므로 동일합니까? 어느 것을 사용해야합니까? 실제 답변은 실제로 중요하지 않습니다. 요점은 이러한 종류의 질문을 피하는 데 도움이되는 표기법을 사용하여 답변을 식별 할 수 없다는 것입니다. 반면 변수의 선언은 컴파일러가 사용하는 것이므로 분명해야합니다.

이것들은 헝가리 표기법에 대해 나를 괴롭히는 것들입니다 . 그럼에도 불구하고 나는 비록 헝가리 인들이 왜 크게 포기되었는지를 충분히 설명하지는 않는다고 생각합니다. 대부분의 프로그래머가 헝가리어를 사용하지 않는 세 가지 가장 큰 이유는 다음과 같습니다.

1. 그것을 사용해야 할 강력한 이유가 없습니다. 위의 항목 3과 4를 참조하십시오. 헝가리어가 헝가리어를 사용하지 않는 것보다 큰 이점을 제공한다면 성가심으로 살 수는 있지만, 보지 못하고 다른 대부분의 사람들도 그렇지 않습니다. 아마도 헝가리어에 대한 가장 좋은 점은 널리 사용되는 규칙 이었기 때문에 표준 사용을 고수하면 비슷한 기술을 가진 다른 프로그래머가 표기법을 이해할 수 있다고 합리적으로 기대할 수 있습니다.

2. Microsoft가 아닌 회사의 영향력 증가. 헝가리 표기법을 채택한 대부분의 프로그래머가 그렇게했다고 말하는 것이 타당 할 것입니다. 이것이 마이크로 소프트가 코드를 작성하는 방식이기 때문에 종종 흐름에 따라 가기가 더 쉽기 때문입니다. 구글이나 애플과 같은 회사는 과거보다 훨씬 더 큰 영향력을 행사하고 있으며, 그 어느 때보 다 많은 프로그래머가 헝가리와 거의 같은 회사와 다른 회사의 스타일을 채택하고 있습니다. (여전히 구글과 애플 모두 상수 이름에 'k'접두사를 사용하는 것과 같은 일부 잔존물이 여전히 표시되어 있음을 알면 공평합니다.)

3. 마이크로 소프트 자체는 헝가리를 포기했다. 코딩 지침에서 Microsoft의 일반 명명 규칙 섹션 을 확인 하면 헝가리 표기법을 사용하지 마십시오.

따라서 헝가리어 표기법 사용을 중지해야하는 한 가지 유효한 이유는 다음과 같습니다.

헝가리 표기법의 인기는 컨벤션이 더 이상 도움이되지 않을 정도로 줄어 들었습니다. 요즘 헝가리어를 사용하거나 이해하는 프로그래머가 훨씬 적기 때문에 컨벤션은 정보를 전달하는 데 훨씬 덜 효과적입니다. 자신의 개인 프로젝트에서 코드를 작성하는 유용한 방법을 찾으면 그만 둘 이유가 없습니다. 그러나 헝가리어를 사용하지 않는 팀의 일원으로 코드를 작성하는 경우 성공적인 의사 소통 전략이 아니라 사용자와 다른 팀 사이의 벽이 될 수 있습니다.

지금까지 사용하면 다음과 같은 이점이 있습니다.

• 일관된 변수 이름

The Simpsons의 문자 뒤에 모든 변수의 이름을 지정하면 일관성이 있지만 이점이 있습니까?

• 검색하지 않고 유형을 볼 수 있습니다 (지능형이 죽었거나 색인을 생성하는 절반 시간이므로 여전히 유효한 이유입니다)

이것이 특정 도구의 약점을 기반으로 한 유일한 이유입니다 ...

• 시맨틱은 여전히 ​​이름의 두 번째 부분으로 압축 될 수 있습니다

그것은 이점이 아닙니다. 당신은 단지 ( 거대한 ) 단점 이 없다고 주장하고 있습니다.

IDE는 변수 위에 마우스를 놓으면 변수 유형이 무엇인지 간단하게 알려줍니다. 그렇다면 왜 그 정보를 복제해야합니까? 기본적으로 Systems Hungarian Notation은 DRY를 위반하며 이와 관련된 모든 함정이 있습니다. 현대 환경에서 해당 정보에 쉽게 액세스 할 수 있으면 그 가격을 지불 할 이유가 없습니다.

일관성은 그 자체로는 이점이 아닙니다. 유형으로 이름을 지정하지 않으면 일관성 이 있습니다 . 일부 변수에만 이름에 유형이있는 경우에만 불일치가 발생합니다. 그리고 의미를 두 번째 부분으로 포장하는 것은 단순히 "글쎄, 그렇게 나쁘지는 않습니다.", 다른 모든 사람들은 의미 의 전체 이름 을 사용해야합니다 . 실제 장점은 없습니다.

전통적인 헝가리 표기법의 또 다른 요점은 일반적으로 접두사입니다. 여기에 두 가지 문제가 있습니다.

1) 인간 독자는 일반적으로 가장 중요한 정보를 가장 먼저 원합니다. 대부분의 헝가리어 양식에서 인코딩 된 정보는 이름 자체보다 덜 중요합니다.

2) 접두어는 어휘 정렬에 영향을 미치므로 예를 들어 접두사를 사용하여 인터페이스 또는 클래스를 표시하고 IDE가 정렬 된 목록을 제공하는 경우 관련 클래스 / 인터페이스가이 목록에서 분리됩니다.

분명히 이것은 의견에 달려 있으므로 여기서 사실을 다루는 것은 어려울 것입니다. 개인적으로, 나는 인수 것을 발견 에 대한 헝가리어 표기법은 강력한 형식의 객체 지향 언어에서 약간 얇은 실행됩니다. 내 경험상 OO 응용 프로그램은 클래스를 일관되고 간결하게 유지하여 복잡성을 처리하는 경향이 있으며 함수에 대해서도 마찬가지입니다. 이것은 다른 모든 것들이 평등하다는 것을 의미합니다.

• 더 많은 수업 / 유형
• 더 짧은 방법

이제 헝가리어 표기법을 사용하려면 보드 전체에 적용 할 것인지 아니면 특정 특권 유형 및 클래스 (예 : 핵심 라이브러리 클래스)에 사용할지를 결정해야합니다. 후자는 나에게 의미가 없으며, 전자는 Péter Török이 언급 한 "수천 가지 유형으로 다른 약어를 찾으려는 미로"로 이어집니다. 즉, 약어 목록을 유지 관리하는 데 상당한 오버 헤드가 있으며 일반적으로 "일관된 변수 이름 지정"이 적용됩니다.

더 짧은 메소드에 대한 두 번째 요점은 대부분의 경우 변수의 유형을 확인하기 위해 수백 줄의 코드를 거치지 않아도된다는 것을 의미합니다. 변수 이름을 조금 더 신중하게 지정하면 다른 질문 (예 cityName: 그냥)을 제거 할 수 있습니다 city. 나는 그것이 cityNamefloat가 아니라고 희망한다 :)

그것이 사람들을 괴롭히는 이유에 관해서는, 다시 말하지만, 아마도 익숙하지 않을 것입니다. 그러나 익숙하지 않은 사람으로서 헝가리어 표기법을 사용하면 내 눈의 코드 흐름이 깨져서 빨리 읽는 것이 어려워집니다. 요컨대, 나는 그것이 리팩토링 등의 관점에서 그 단점에 대해 논의하지는 않았지만 장점 이 없다고 말하지는 않지만 강력하게 유형화 된 OO 언어에 대한 노력은 가치가 없다고 말하고 있습니다.

나는 C ++의 맥락에서 모른다. 그러나 Java / C # 세계에서 나는 그것이 문자열 이라는 것을 말하는 것보다 도메인 언어 나 문맥을 전달하는 의미있는 이름을 갖는 것을 선호한다 strFirstName. 그것은 문자열이거나 더 나은 의도를 전달하기 위해 이름을 리팩토링해야한다는 것이 명백해야합니다. 작업하는 유형을 알기 위해 접두사가 필요한 경우 이름이 불일치하거나 설명이 충분하지 않거나 완전히 잘못되었다고 주장합니다. 현대 언어에서는 항상 모호하거나 모호한 이름보다 모호하지 않은 더 긴 이름을 선호합니다.

내가 헝가리어 사용하는 유일한 시간은 ASP.NET 컨트롤입니다, 정말 긴과 같이 입력 할 필요가 없습니다의 이상) IA 그래서 CustomerFirstNameTextBox대 txtCustomerFirstName, 및 B)를 그래서 인텔리는 컨트롤 형식의 모든 정렬합니다. 그래도 "더러운"느낌이 들지만 아직 더 좋은 방법을 찾지 못했습니다.

Meh-선택을 합리화하기 위해 얼마나 열심히 노력하든 그것은 개인 취향에 관한 것입니다. 저는 개인적으로 "When in Rome ..."규칙을 고수하고 Windows API를 많이 호출하는 코드에서 헝가리어를 사용합니다. 플랫폼 독립적 인 코드의 경우 C ++ 표준 라이브러리 스타일을 따르는 경향이 있습니다.

대답은이 질문에 있습니다. 다음 변수의 이름을 지정하는 방법을 알려주십시오.

char * nullTerminatedString;
wchar * nullTerminatedWideString;
문자열 stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

이 상수 문자열에 이것에 대한 포인터와 이것에 대한 상수 포인터를 추가하십시오.

나는 당신이 묘사하는 헝가리어 표기법의 형태를 강력하게 싫어합니다. 이유? 시간의 90 %를 차지하지 않습니다.

예를 들어, 견뎌야 할 레거시 프로젝트의 약간의 (실제로 델파이로 작성된 C ++ 코드) 코드는 다음과 같습니다.

pRecords[0]->FooMember=10;

... pRecord는 변수이며 TRecordList 유형입니다. TRecordList *pRecords[10];

"필드"또는 "멤버"인지 여부에 따라 fFooMember ... 또는 mFooMember를 가리키는 FooMember라는 오리 너티로 구성된 클래스입니다 (힌트 : 동일한 것임)

문제? fFooMemberFooMember_와 같은 것일 수 있습니다. FooMember 공개 속성을 통해 항상 액세스 할 수 있기 때문입니다. p 레코드? 그것은 당신이 모든 곳에서 그것을 역 참조한다는 사실로부터의 포인터임을 분명히 알 수 있습니다. TRecordList? 언제 유형 이름과 해당 유형의 객체를 혼동 할 수 있습니까? 컴파일러는 사용자에게 소리를 지르며 객체가있는 곳은 거의 없습니다 (정적 속성 / 메소드 제외)

이제 헝가리어 표기법을 사용하는 곳이 있습니다. 다른 UI 변수 또는 일반 변수와 이름이 같은 많은 UI 변수를 처리 할 때입니다.

예를 들어, 당신의 이름에 대한 양식이 있다면.

FirstNameForm이라는 클래스가 있습니다. 그 안에 레이블과 텍스트 상자에 대한 lblFirstName 및 txtFirstName이 각각 있습니다. 텍스트 상자에서 이름을 가져오고 설정하기위한 공용 FirstName 속성입니다.

FirstNameLabel 및 FirstNameTextBox를 사용하여 해결할 수도 있지만 입력하는 데 시간이 오래 걸립니다. 특히 GenderDropDownList와 같은 것.

따라서 기본적으로 헝가리 표기법은 체계적인 수준에서 성 가시고 최악의 경우 유해합니다 (다른 답변은 리팩토링 및 일관성에 문제가 있음).