사람들이 실제 세계에서 헝가리어 명명 규칙을 사용합니까?[닫은]

Question

규칙을 배우는 것이 가치가 있습니까? 아니면 가독성과 유지 관리에 해가 됩니까?

Answer 1

사용하는 대부분의 사람들이 헝가리어 표기법 그것은 오해된 버전을 따르고 있는데, 나는 그것이 꽤 무의미하다고 말하고 싶습니다.

원래 정의를 사용하고 싶다면 더 의미가 있을 수 있지만 그 외에는 대부분 구문 설탕입니다.

당신이 읽으면 위키피디아 기사 이 주제에 관해 두 가지 상충되는 표기법을 발견하게 될 것입니다. 시스템 헝가리어 표기법 그리고 헝가리어 표기법.

원래의 좋은 정의는 다음과 같습니다. 헝가리어 표기법, 하지만 대부분의 사람들은 시스템 헝가리어 표기법.

두 가지의 예로서 변수 앞에 길이를 뜻하는 l, 면적을 뜻하는 a, 부피를 뜻하는 v를 붙이는 것을 고려해보세요.

이러한 표기법을 사용하면 다음 표현이 의미가 있습니다.

int vBox = aBottom * lVerticalSide;

하지만 그렇지 않습니다:

int aBottom = lSide1;

접두사를 혼합하는 경우 방정식의 일부로 간주되며 볼륨 = 면적 * 길이는 상자에 적합하지만 길이 값을 면적 변수에 복사하면 몇 가지 위험 신호가 발생합니다.

불행하게도 다른 표기법은 덜 유용합니다. 사람들은 다음과 같이 변수 이름 앞에 값 유형을 붙입니다.

int iLength;
int iVolume;
int iArea;

어떤 사람들은 숫자에 n을 사용하거나 정수에 i, 부동 소수점에 f, 문자열에 s 등을 사용합니다.

원래 접두사는 방정식의 문제를 찾는 데 사용되었지만 변수 선언을 찾을 필요가 없기 때문에 코드를 약간 더 쉽게 읽을 수 있게 되었습니다.단순히 변수 위로 마우스를 가져가면 약어뿐만 아니라 전체 유형을 찾을 수 있는 오늘날의 스마트 편집기에서는 이러한 유형의 헝가리어 표기법이 많은 의미를 잃었습니다.

하지만, 스스로 결정해야 합니다.내가 말할 수 있는 것은 나도 사용하지 않는다는 것이다.

---

편집하다 제가 사용하지 않는 동안 간단히 말씀드리자면 헝가리어 표기법, 저는 접두사를 사용하는데 그것은 밑줄입니다.클래스의 모든 비공개 필드 앞에는 _를 붙이고 그렇지 않으면 속성과 마찬가지로 이름의 철자를 지정합니다. 제목에는 첫 글자가 대문자입니다.

Answer 2

헝가리어 명명 규칙은 올바르게 사용하면 유용할 수 있지만 불행히도 오용되는 경우가 더 많습니다.

Joel Spolsky의 기사 읽기 잘못된 코드를 잘못된 것처럼 보이게 만들기 적절한 관점과 정당화를 위해.

기본적으로 유형 기반 헝가리어 표기법으로, 변수 앞에 해당 유형에 대한 정보가 붙습니다(예:객체가 문자열, 핸들, int 등인지 여부)는 대부분 쓸모가 없으며 일반적으로 이점이 거의 없이 오버헤드만 추가할 뿐입니다.안타깝게도 이는 대부분의 사람들에게 친숙한 헝가리 표기법입니다.그러나 계획된 헝가리 표기법의 목적은 변수에 포함된 데이터의 "종류"에 대한 정보를 추가하는 것입니다.이를 통해 일부 변환 프로세스를 통하는 경우를 제외하고는 함께 혼합할 수 없는 다른 종류의 데이터와 여러 종류의 데이터를 분할할 수 있습니다.예를 들어 픽셀 기반 좌표와다른 단위의 좌표 또는 안전하지 않은 사용자 입력 대 안전한 소스의 데이터 등

이런 식으로 살펴보세요. 변수에 대한 정보를 찾기 위해 코드를 샅샅이 뒤지고 있다면 아마도 해당 정보를 포함하도록 명명 체계를 조정해야 할 것입니다. 이것이 헝가리 규칙의 핵심입니다.

헝가리어 표기법의 대안은 모든 곳에서 기본 유형에 의존하는 대신 변수 사용 의도를 표시하기 위해 더 많은 클래스를 사용하는 것입니다.예를 들어 안전하지 않은 사용자 입력에 대한 변수 접두사를 사용하는 대신 안전하지 않은 사용자 입력에 대한 간단한 문자열 래퍼 클래스와 안전한 데이터에 대한 별도의 래퍼 클래스를 사용할 수 있습니다.이는 강력한 유형의 언어에서 컴파일러에 의해 분할을 강제하는 이점이 있지만(심지어 덜 강력한 유형의 언어에서도 일반적으로 자체 트립와이어 코드를 추가할 수 있음) 상당한 양의 오버헤드를 추가합니다.

Answer 3

나는 여러 UI 요소가 특정 개체/값과 관련된 UI 요소와 관련하여 여전히 헝가리 표기법을 사용합니다.

레이블 개체의 경우 lblFirstName, 텍스트 상자의 경우 txtFirstName입니다.두 사람의 이름을 모두 "FirstName"으로 지정할 수는 없습니다. 저것 두 개체의 관심/책임입니다.

다른 사람들은 UI 요소 이름 지정에 어떻게 접근합니까?

Answer 4

그것은 무의미하고 산만하지만 우리 회사에서는 적어도 int, 문자열, 부울 및 복식과 같은 유형에 대해 상대적으로 많이 사용됩니다.

같은 것들 sValue, iCount, dAmount 또는 fAmount, 그리고 bFlag 어디에나 있습니다.

옛날 옛적에 이 대회에는 타당한 이유가 있었습니다.이제 암입니다.

Answer 5

나는 헝가리어 표기법이 더 읽기 쉬운 코드로 향하는 '경로'에 있는 흥미로운 각주라고 생각하며, 적절하게 사용된다면 사용하지 않는 것보다 더 낫다고 생각합니다.

하지만 그렇게 말하면서 나는 그것을 없애고 싶습니다. 대신 다음과 같습니다.

int vBox = aBottom * lVerticalSide;

이것을 쓰세요:

int boxVolume = bottomArea * verticalHeight;

2008년이에요.더 이상 80자의 고정 너비 화면이 없습니다!

또한, 그보다 훨씬 긴 변수 이름을 작성하는 경우 어쨌든 객체나 함수로의 리팩토링을 살펴봐야 합니다.

Answer 6

후속 질문을 드려 죄송합니다. 인터페이스에 "I"라는 접두어를 붙이는 것이 헝가리어 표기법에 해당합니까?그렇다면 실제로 많은 사람들이 이를 사용하고 있습니다.그렇지 않다면 이것을 무시하십시오.

Answer 7

나는 헝가리어 표기법이 우리의 단기 기억 능력을 우회하는 방법이라고 생각합니다.심리학자들에 따르면 우리는 대략적으로 저장할 수 있습니다. 7 플러스 마이너스 2 청크 정보의.접두사를 포함하여 추가된 추가 정보는 다른 컨텍스트가 없어도 식별자의 의미에 대한 자세한 내용을 제공함으로써 도움이 됩니다.즉, 변수가 어떻게 사용되거나 선언되는지 보지 않고도 변수의 용도를 추측할 수 있습니다.이는 다음과 같은 기술을 적용하여 피할 수 있습니다. 캡슐화 그리고 단일 책임 원칙.

나는 이것이 경험적으로 연구되었는지 여부를 알지 못합니다.인스턴스 변수가 9개 이상인 클래스나 지역 변수가 9개 이상인 메서드를 이해하려고 하면 노력의 양이 극적으로 증가한다는 가설을 세웁니다.

Answer 8

요즘에는 유형보다 범위가 더 중요하지 않습니까?

• l 지역의 경우
• 인수에 대한
• m은 회원용
• g(글로벌)
• 등

오래된 코드를 리팩토링하는 최신 기술을 사용하면 유형을 변경했기 때문에 기호를 검색하고 바꾸는 것이 지루합니다. 컴파일러는 유형 변경을 포착하지만 범위의 잘못된 사용을 포착하지 못하는 경우가 많습니다. 여기서는 합리적인 명명 규칙이 도움이 됩니다.

Answer 9

헝가리어 토론을 볼 때 사람들이 코드를 더 명확하게 만드는 방법과 실수를 더 눈에 띄게 만드는 방법에 대해 열심히 생각하는 모습을 보게 되어 기쁩니다.그것이 바로 우리 모두가 해야 할 일입니다!

하지만 이름 지정 외에도 사용할 수 있는 몇 가지 강력한 도구가 있다는 사실을 잊지 마십시오.

추출방법 메소드가 너무 길어서 변수 선언이 화면 상단에서 스크롤되지 않은 경우 메소드를 더 작게 만드는 것이 좋습니다.(메소드가 너무 많으면 새로운 클래스를 고려해보세요.)

강력한 타이핑 복용하고 있는 것으로 확인되면 우편 번호s는 정수 변수에 저장되고 이를 신발 사이즈 정수 변수인 경우 우편번호에 대한 클래스와 신발 사이즈에 대한 클래스를 만드는 것을 고려해 보세요.그러면 사람이 주의 깊게 검사할 필요 없이 컴파일 타임에 버그가 발견됩니다.이 작업을 수행할 때 일반적으로 코드 주변에 삽입한 우편번호 및 신발 사이즈별 논리를 찾아 새 클래스로 이동할 수 있습니다.갑자기 모든 코드가 더 명확해지고 단순해지며 특정 종류의 버그로부터 보호됩니다.우와.

요약하자면:예, 아이디어를 명확하게 표현하기 위해 코드에서 이름을 사용하는 방법에 대해 열심히 생각해 보세요. 또한 호출할 수 있는 다른 강력한 OO 도구도 찾아보세요.

Answer 10

나는 매우 엄격한 헝가리 표기법을 사용하지 않지만 식별을 돕기 위해 몇 가지 일반적인 사용자 정의 개체를 제외하고 이를 사용하고 있으며 GUI 컨트롤 개체 앞에 컨트롤 유형을 접두사로 붙이는 경향이 있습니다.예를 들어 labelFirstName, textFirstName 및 ButtonSubmit이 있습니다.

Answer 11

저는 버튼, 텍스트 상자, 라벨과 같은 UI 요소에 헝가리식 이름 지정을 사용합니다.주요 이점은 Visual Studio Intellisense 팝업에서 그룹화하는 것입니다.내 lables에 액세스하려면 lbl을 입력하기만 하면 됩니다....Visual Studio에서는 nicley가 함께 그룹화된 모든 레이블을 제안합니다.

그러나 점점 더 많은 Silverlight 및 WPF 작업을 수행하고 데이터 바인딩을 활용한 후에는 코드 숨김에서 참조할 필요가 없기 때문에 더 이상 모든 컨트롤의 이름을 지정하지도 않습니다. ;)

Answer 12

문제는 표준을 혼합하는 것입니다.

올바른 것은 모든 사람이 같은 일을 하도록 하는 것입니다.

int Box = iBottom * nVerticleSide

Answer 13

원래의 접두사는 방정식에서 문제를 발견하는 데 사용되었지만 변수 선언을 찾을 필요가 없기 때문에 코드를 약간 쉽게 읽을 수 있도록하는 데 도움이되었습니다.오늘날의 스마트 편집자는 단순히 변수를 가공하여 전체 유형을 찾을 수있는 경우에 대한 약어를 찾을 수있는이 유형의 헝가리 표기법은 그 의미를 많이 잃어 버렸습니다.

나는 습관을 조금 깨고 있지만 유형 앞에 접두사를 붙이는 것은 강력한 변수 유형 지정이 없는 JavaScript에서 유용할 수 있습니다.

Answer 14

동적 유형 언어를 사용할 때 가끔 Apps 헝가리어를 사용합니다.정적으로 유형이 지정된 언어의 경우에는 그렇지 않습니다.내 설명을 참조하세요 다른 스레드에서.

Answer 15

유형이 안전한 언어에서는 헝가리어 표기법이 의미가 없습니다.예를 들어이전 Microsoft 코드에서 볼 수 있는 일반적인 접두사는 "0으로 끝나는 문자열에 대한 긴 포인터"를 의미하는 "lpsz"입니다.1700년대 초반부터 우리는 짧은 포인터와 긴 포인터가 존재하는 분할된 아키텍처를 사용하지 않았습니다. C++의 일반적인 문자열 표현은 항상 0으로 종료되며 컴파일러는 유형이 안전하므로 문자열이 아닌 연산을 끈.따라서 이 정보 중 어느 것도 프로그래머에게 실제로 유용하지 않습니다. 단지 입력만 더 하는 것일 뿐입니다.

그러나 나는 비슷한 아이디어를 사용합니다.명확하게 해주는 접두사 용법 변수의.주요 내용은 다음과 같습니다.

• m = 회원
• c = 불변
• s = 정적
• v = 휘발성
• p = 포인터(그리고 pp=포인터에 대한 포인터 등)
• i = 인덱스 또는 반복자

이들은 결합될 수 있으므로 포인터인 정적 멤버 변수는 "mspName"이 됩니다.

이것들은 어디에 유용합니까?

• 사용법이 중요한 경우, 변수가 휘발성 또는 포인터라는 사실을 프로그래머에게 지속적으로 상기시키는 것이 좋습니다.
• p 접두사를 사용할 때까지 포인터 역참조를 사용했습니다.이제 개체(Orange)가 개체에 대한 포인터(pOrange)인지 또는 개체에 대한 포인터에 대한 포인터(ppOrange)가 있는지 아는 것이 정말 쉽습니다.객체를 역참조하려면 객체 이름의 각 p에 대해 객체 앞에 별표를 붙이면 됩니다.사례가 해결되었습니다. 더 이상 참조 취소 버그가 없습니다!
• 생성자에서 나는 일반적으로 매개변수 이름이 멤버 변수의 이름과 동일하다는 것을 발견합니다(예:크기)."msize = size;"를 선호합니다. "size = thesize"또는 "this.size = size"보다.또한 훨씬 더 안전합니다."mSize = 1"(멤버 설정)이라고 말하려고 했을 때 실수로 "size = 1"(매개변수 설정)을 사용하지 않습니다.
• 루프에서 내 반복자 변수는 모두 의미 있는 이름입니다.대부분의 프로그래머는 "i" 또는 "index"를 사용한 다음 내부 루프를 원할 때 새로운 의미 없는 이름("j", "index2")을 만들어야 합니다.i 접두사가 붙은 의미 있는 이름(iHospital, iWard, iPatient)을 사용하므로 반복자가 무엇을 반복하는지 항상 알 수 있습니다.
• 루프에서는 동일한 기본 이름과 다른 접두사를 사용하여 여러 관련 변수를 혼합할 수 있습니다.주황색 주황색 = pOrange[iOrange];이는 또한 배열 인덱싱 오류가 발생하지 않음을 의미합니다(pApple[i]는 괜찮아 보이지만 pApple[iOrange]로 작성하면 오류가 즉시 명백해집니다).
• 많은 프로그래머들이 내 시스템을 모르고 사용할 것입니다."Index" 또는 "Ptr"과 같은 긴 접미사를 추가합니다. 단일 문자 IMHO보다 긴 형식을 사용할 이유가 없으므로 "i" 및 "p"를 사용합니다.타이핑 횟수가 줄어들고 일관성이 높아지며 읽기 쉬워집니다.

이는 의미 있고 유용한 정보를 코드에 추가하고 단순하지만 일반적인 프로그래밍 실수의 가능성을 제거하는 간단한 시스템입니다.

Answer 16

나는 지난 6개월 동안 IBM에서 일했는데 어디에서도 본 적이 없습니다. (제가 그것을 싫어하기 때문에 하느님께 감사드립니다.) CamelCase 또는 c_style이 보입니다.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Answer 17

언어와 환경에 따라 다릅니다.일반적으로 현재 사용 중인 개발 환경에서 변수 유형을 찾기가 어려운 경우를 제외하고는 이 변수를 사용하지 않습니다.

헝가리어 표기법에는 두 가지 유형이 있습니다.조엘 문서를 참고하세요.찾을 수 없습니다. (그 사람 이름 때문에 찾기가 쉽지 않습니다.) 제가 말하는 사람에 대한 링크가 있는 사람이 있나요?

편집하다:Wedge의 게시물에는 내가 의미하는 기사가 있습니다.

Answer 18

원래 형식(오른쪽 헝가리어 표기법 :)) 여기서 접두사는 유형을 의미합니다(예:길이, 수량) 변수에 저장된 값은 괜찮지만 모든 유형의 응용 프로그램에 필요한 것은 아닙니다.

접두사가 유형(String, int)을 의미하는 널리 사용되는 형식(잘못된 헝가리어 표기법)은 대부분의 현대 프로그래밍 언어에서는 쓸모가 없습니다.

특히 strA와 같은 의미 없는 이름의 경우에는 더욱 그렇습니다.나는 우리 사람들이 아무 것도 주지 않는 긴 접두어를 붙인 무의미한 이름을 사용한다는 것을 이해할 수 없습니다.

Answer 19

자동 완성 기능이 더 잘 작동하도록 구성 요소(예: editFirstName, lblStatus 등)에 대해 유형 기반(Systems HN)을 사용합니다.

나는 때때로 유형 정보가 충분한 변수에 대해 App HN을 사용합니다.즉, fpX는 고정 지적 변수(int 유형이지만 int와 혼합 및 일치할 수 없음), 검증되지 않은 사용자 문자열에 대한 rawInput 등을 나타냅니다.

Answer 20

매우 느슨하게 입력된 PHP 프로그래머로서 나는 그것을 사용할 이유가 없습니다.그러나 때때로 시스템의 크기와 변수의 범위에 따라 무언가를 배열이나 객체로 식별할 것입니다.