헝가리 표기법

Hungarian notation

헝가리 표기법은 컴퓨터 프로그래밍에서 식별자 명명 규칙을 말하며, 변수나 함수의 이름이 의도나 종류를 나타내고, 일부 방언에서는 그 유형을 나타낸다.원래 헝가리의 표기법은 이름짓기 규약에 의도나 종류를 사용하며, 워드, 엑셀 및 기타 앱 개발에서 마이크로소프트 앱스 부문에서 인기를 끌면서 앱 헝가리어로 부르기도 한다.마이크로소프트 윈도 부서가 명명 규칙을 채택함에 따라, 그들은 실제 데이터 유형을 명명하는데 사용하였고, 이 협약은 윈도 API를 통해 널리 퍼지게 되었다. 이것을 시스템 헝가리 표기법이라고 부르기도 한다.

시모니: ...BCPL은 16비트 단어인 단일 유형을 가지고 있었다...그것이 문제라는 것은 아니다.

부치: 헝가리의 표기법을 계속하지 않는 한.

시모니:물론이지...우리는 너무 늦게 타이프된 언어들로 넘어갔다...하지만...우리는 하나의 이름을 보고 당신에게 그것에 대해 많은 것을 말해줄 것이다...[1]

헝가리 표기법은 언어에 독립적인 것으로 설계되었으며, BCPL 프로그래밍 언어와 함께 첫 번째 주요 용도를 찾았다.BCPL은 기계어 외에 데이터 유형이 없기 때문에 언어 자체에서 프로그래머가 변수의 유형을 기억하는 데 도움이 되는 것은 없다.헝가리 표기법은 프로그래머에게 각 변수의 데이터 유형에 대한 명시적 지식을 제공함으로써 이를 교정하는 것을 목적으로 한다.

헝가리어 표기법에서 변수 이름은 해당 변수의 유형이나 목적에 대한 연상키인 소문자 그룹으로 시작하고, 프로그래머가 선택한 이름이 무엇이든지 그 뒤에 온다. 이 마지막 부분은 때때로 주어진 이름으로 구분된다.주어진 이름의 첫 번째 문자는 대문자로 바꾸어 형식 표시기와 구분할 수 있다(CamelCase도 참조).그렇지 않으면 이 문자의 경우는 범위를 나타낸다.

역사

이제 앱스 헝가리어로 불릴 원래의 헝가리 표기법은 제록스 PARC circa 1972–1981년에 일했던 프로그래머 찰스 시모니에 의해 발명되었고, 후에 마이크로소프트의 수석 설계자가 되었다.

표기법 이름은 시모니의 원산지를 가리키는 말이다; 헝가리 사람들의 이름은 대부분의 다른 유럽 이름들과 비교해서 "역행"된다; 성은 주어진 이름 앞에 있다.예를 들어 헝가리어로 "Charles Simonyi"라는 영어식 이름은 원래 "Simonyi Karoly"였다.같은 방법으로 타입명은 스몰토크 "타입 라스트" 명명 스타일(예: aPoint 및 lastPoint)이 아니라 헝가리 표기법에서 "주어진 이름" 앞에 붙는다.이 후자의 명명 방식은 제록스 PARC에서 시모니가 그곳에서 재임하는 동안 가장 흔했다.

앱스 헝가리라는 이름은 이 협약이 마이크로소프트의 애플리케이션 부서에서 사용되었기 때문에 생겨났다.시스템 헝가리는 후에 마이크로소프트 윈도우 개발 팀에서 개발되었다.Simonyi의 논문은 저장되는 정보의 "유형"을 나타내기 위해 사용되는 접두사를 언급하였다.그의 제안은 앱 헝가리와 일치하는, 그들이 저장하는 것(즉, 변수의 목적)의 의미 정보를 바탕으로 식별자 이름을 장식하는 것에 크게 신경을 썼다.그러나, 그의 제안된 접두사 중 일부는 의미 정보를 거의 포함하지 않거나 전혀 포함하지 않기 때문에(예는 아래 참조) 그의 제안은 Systems Herganious로 알려지게 된 것과 완전히 구별되지 않았다.

시스템 헝가리어 vs.앱 헝가리어

시스템 표기법과 앱 표기법이 다른 경우 접두사의 목적이다.

Systems Hergan 표기법에서 접두사는 변수의 실제 데이터 유형을 인코딩한다.예를 들면 다음과 같다.

  • lAccountNum: 변수는 긴 정수 ("l");
  • arru8NumberList: variable은 서명되지 않은 8비트 정수의 배열이다."arru8");
  • bReadLine(bPort,&arru8NumberList): 바이트 값 반환 코드로 기능한다.
  • strName: 변수는 문자열을 나타낸다("str"이름을 포함하지만 해당 문자열이 구현되는 방법은 지정하지 않는다.

앱 헝가리 표기법은 물리적 데이터 형식이 아닌 논리적 데이터 유형을 인코딩하기 위해 노력한다. 이러한 방식으로 변수의 목적이 무엇인지, 또는 그것이 나타내는 것이 무엇인지 힌트를 준다.

  • rwPosition: 변수는 행을 나타낸다("rw");
  • usName: 변수는 안전하지 않은 문자열을 나타낸다("us"() 사용 전에 "소거"해야 하는 (예를 들어 원시 사용자 입력을 사용하여 발생할 수 있는 공격의 예는 코드 주입 및 사이트 간 스크립팅 참조)
  • szName: 변수는 영점 조정 문자열("sz"); 이것은 시모니가 원래 제안했던 접두사 중 하나였다.

시모니가 제시한 접두사의 대부분은, 그러나 전부는 아니다.현대의 눈에는 다음과 같은 물리적 데이터 유형을 나타내는 접두사가 있다.sz현악기용의그러나 시모니가 현대 언어가 당연하게 여기는 일부 데이터 유형을 구분할 수 없는 언어에 대해 헝가리어 표기법을 의도했기 때문에 그러한 접두어는 여전히 의미심장했다.

원문의 예는 다음과 같다.[2]

  • pX다른 타입 X에 대한 포인터로, 이것은 의미 정보를 거의 포함하지 않는다.
  • d예를 들어, dY는 그래프의 Y축을 따라 거리를 나타내는 반면 y라고 하는 변수는 절대 위치일 수 있다.이것은 본질적으로 완전히 의미심장하다.
  • sznull 또는 0-mero-message 문자열.C에서 이것은 type char*의 변수가 단일 문자에 대한 포인터인지, 문자의 배열인지, 아니면 영종말 문자열에 대한 포인터인지 명확하지 않기 때문에 일부 의미 정보를 포함하고 있다.
  • w단어인 변수를 표시하다이것은 본질적으로 의미 정보를 전혀 포함하지 않으며 아마도 시스템 헝가리어로 간주될 것이다.
  • b바이트를 표시하는데, 이는 의미 정보를 가질 수 있는 w와는 대조적으로, C에서 유일한 바이트 크기의 데이터 유형은 char이기 때문에 이러한 데이터 유형은 때때로 숫자 값을 보유하는 데 사용되기 때문이다.이 접두사는 변수가 문자로 간주해야 하는 값을 보유하는지 또는 숫자로 간주해야 하는지 간에 모호함을 해소할 수 있다.

표기법은 항상 초기 소문자를 니모닉으로 사용하지만, 니모닉 자체를 규정하지는 않는다.널리 사용되는 규약이 몇 가지 있지만(아래 예 참조), 주어진 코드 본문 내에서 일관성이 있는 한 모든 문자 집합을 사용할 수 있다.

앱 헝가리어 표기법을 사용하는 코드는 형식으로만 정의되는 변수를 설명할 때 Systems Herganic을 포함하기도 한다.

시그널과의 관계

일부 프로그래밍 언어에서는 현재 시그닐이라고 불리는 유사한 표기법이 언어에 내장되어 컴파일러에 의해 시행된다.예를 들어, BASIC의 어떤 형태에서는name$끈의 이름을 짓다count%정수의 이름을 붙이다헝가리 표기법과 시그닐의 주요 차이점은 시글이 언어로 변수의 유형을 선언한다는 점인데 반해, 헝가리 표기법은 프로그램 텍스트의 기계 해석에 영향을 미치지 않는 순전히 명명 체계라는 점이다.

예

  • bBusy: 부울
  • chInitial: char
  • cApples: 품목수
  • dwLightYears: 이중 단어(시스템)
  • fBusy: 플래그(또는 플로트)
  • nSize: 정수(시스템) 또는 개수(앱)
  • iSize: 정수(시스템) 또는 색인(앱)
  • fpPrice: 부동 소수점
  • dbPi: 이중(시스템)
  • pFoo: 포인터
  • rgStudents: 배열 또는 범위
  • szLastName: 영점 조정 문자열
  • u16Identifier: 서명되지 않은 16비트 정수(시스템)
  • u32Identifier: 서명되지 않은 32비트 정수(시스템)
  • stTime: 시계 시간 구조
  • fnFunction: 함수 이름

실제 데이터 유형이 아닌 포인터와 어레이에 대한 연상키에는 대개 데이터 요소 자체의 유형이 따른다.

  • pszOwner: 영점 조정 문자열에 대한 포인터
  • rgfpBalances: 부동 소수점 값의 배열
  • aulColors: 서명되지 않은 길이의 배열(시스템)

헝가리 표기법은 어떤 프로그래밍 언어와 환경에도 적용할 수 있지만, 마이크로소프트에 의해 C언어와 함께 사용하기 위해 널리 채택되었고, 특히 마이크로소프트 윈도에서는 그 사용이 대부분 그 영역에 국한되어 있다.특히 헝가리 표기법의 사용은 (그리고 많은 독자들에게는) 윈도우 API 프로그래밍에 관한 최초의 책인 찰스 페트졸드의 "Programming Windows"에 의해 널리 전파되었다.따라서 헝가리 표기법에서 흔히 볼 수 있는 많은 구성물은 윈도우에 특유하다.

  • C에서 Windows 프로그래밍을 배운 프로그래머들에게 가장 기억에 남는 예는 아마도wParam(단어 크기 매개 변수) 및lParam(긴 정수 매개변수) WindowProc() 함수의 경우
  • hwndFoo: 창문에 손잡이
  • lpszBar: 영점 조정 문자열에 대한 긴 포인터

표기법은 C++로 확장되어 변수의 범위를 포함하며, 선택적으로 밑줄로 구분한다.[3][4]이 확장자는 헝가리어 형식 지정 없이 사용되는 경우가 많다.

  • g_nWheels: 글로벌 네임스페이스의 멤버, 정수
  • m_nWheels: 구조물/종류의 구성원, 정수
  • m_wheels,_wheels: 구조물/계급의 구성원
  • s_wheels: 클래스의 정적 멤버
  • c_wheels: 함수의 정적 부재

jQuery를 사용하는 JavaScript 코드에서,$접두사는 종종 변수가 jQuery 객체를 보유한다는 것을 나타내기 위해 사용된다(일반적인 DOM 객체 또는 일부 다른 값과는 반대).[5]

이점

(이 중 일부는 Systems Herganian에만 해당됨)

지지자들은 헝가리 표기법의 이점에는 [2]다음이 포함되어 있다고 주장한다.

  • 기호형은 이름에서 볼 수 있다.이것은 코드 검토나 출력물과 같이 통합 개발 환경 외부의 코드를 볼 때 또는 기호 선언이 기능과 같은 사용 지점에서 다른 파일에 있을 때 유용하다.
  • 동적 타이핑을 사용하거나 타이핑이 해제된 언어에서, 유형을 참조하는 장식은 더 이상 중복되지 않는다.그러한 언어에서 변수들은 일반적으로 특정 유형의 데이터를 보유한다고 선언되지 않기 때문에, 이에 대해 어떤 작업을 수행할 수 있는지에 대한 유일한 단서는 변수 이름 지정 체계, 문서화 및 주석과 같은 프로그래머가 제공하는 힌트들이다.위에서 언급했듯이 헝가리 표기법은 그러한 언어(BCPL)로 확장되었다.
  • 변수 이름의 형식은 코드 리팩토링의 일부 측면을 단순화할 수 있다(다른 측면은 오류 발생 가능성이 더 높다).
  • dwWidth, iWidth, fWidth, dWidth 등의 코드 블록에서 유사한 의미론을 가진 여러 변수를 사용할 수 있다.
  • 변수 이름은 유형만 알면 쉽게 기억할 수 있다.
  • 그것은 더욱 일관된 변수 이름으로 이어진다.
  • 부적합한 타입의 주조 및 조작은 코드를 판독하는 동안 쉽게 검출할 수 있다.
  • 글로벌 오브젝트(VB/Delphi Forms)가 많은 복잡한 프로그램에서는 기본 접두사 표기법을 사용하면 편집자 내부에서 구성요소를 찾는 작업을 용이하게 할 수 있다.예를 들어, 문자열 검색btn모든 버튼 객체를 찾을 수 있을 것이다.
  • 멤버 변수에 대해서만 적용하는 등 헝가리 표기법을 좁게 적용하면 명명 충돌을 피하는 데 도움이 된다.
  • 데이터 유형, 유형 변환, 할당, 잘라내기 등의 경우 인쇄된 코드가 판독기에 더 명확하다.

단점들

헝가리 표기법에 반대하는 대부분의 주장은 앱 헝가리 표기법이 아니라 시스템 헝가리 표기법에 반대한다.잠재적 문제로는 다음과 같은 것들이 있다.

  • 컴파일러가 형식 확인을 할 때 헝가리 표기법은 중복된다.Pascal과 같이 엄격한 유형 검사를 제공하는 언어에 대한 컴파일러는 변수의 사용이 그 유형과 자동으로 일치하도록 보장한다. 눈으로 확인하는 것은 중복되어 사람의 실수를 유발한다.
  • 대부분의 현대적인 통합 개발 환경은 요구 시 가변형태를 표시하고, 양립할 수 없는 유형을 사용하는 작업에 자동으로 플래그를 지정하여 표기법이 거의 사용되지 않게 된다.
  • 헝가리 표기법은 다음과 같이 여러 특성을 나타내기 위해 사용될 때 혼동된다.a_crszkvc30LastNameCol : 데이터베이스 컬럼의 내용을 보관하는 지속적인 참조론LastName테이블의 기본 키의 일부인 varchar(30) 유형의
  • 코드를 수정하거나 포팅할 때 불일치로 이어질 수 있다.변수의 유형을 변경할 경우 변수 이름의 장식이 새 유형과 일치하지 않거나 변수의 이름을 변경해야 한다.특히 잘 알려진 예로는 표준 WPARAM 유형과 많은 윈도우즈 시스템 함수 선언에 수반되는 wParam 공식 매개변수가 있다.'w'는 'word'를 의미하며, 여기서 'word'는 플랫폼 하드웨어 아키텍처의 고유 단어 크기이다.원래는 16비트 워드 아키텍처에서 16비트 유형이었으나, 원래 이름을 유지하면서 32비트 워드 아키텍처에서는 32비트 워드 아키텍처에서는 32비트, 64비트 워드 아키텍처에서는 64비트 유형으로 변경되었다(진정한 기본 유형은 UINT_PTR, 즉 포인터를 잡을 만큼 큰 부호 없는 정수).의미론적 임피던스, 그리고 따라서 플랫폼 간 프로그래머 혼동 및 불일치는 'w'가 그러한 다른 환경에서 2바이트, 16비트 단어를 의미한다고 가정한다.
  • 대부분의 경우 변수의 사용을 아는 것은 변수의 유형을 아는 것을 의미한다.나아가 변수의 용도를 알 수 없는 경우에는 그 유형에서 추론할 수 없다.
  • 헝가리 표기법은 프로그래머가 먼저 형식 지정자를 입력해야 하므로, 다른 이름 지정 체계를 사용할 때보다 다른 변수와 충돌할 가능성이 더 높기 때문에 가변 이름에 대한 완료를 지원하는 코드 편집기 사용의 장점을 줄인다.
  • 변수의 목적을 유형 및 범위 지정 접두사로 난독화하여 코드를 판독할 수 없게 한다.[6]
  • 추가 유형 정보는 더 많은 설명적인 이름을 충분히 대체할 수 없다.예: sDatabase는 독자에게 그것이 무엇인지 알려주지 않는다. databaseName은 더 설명적인 이름일 수 있다.
  • 이름이 충분히 기술되어 있는 경우, 추가 유형 정보는 중복될 수 있다.예: firstName은 문자열일 가능성이 가장 높다.따라서 이름을 sFirstName으로 지정하면 코드에 더 복잡해질 뿐이다.
  • 이름을 기억하기가 더 어렵다.
  • dwTmp, iTmp, fTmp, dTmp 등 비슷한 이름의 코드 블록에 의미론적 여러 변수를 사용할 수 있다.
  • 데이터 유형 또는 의도 문자 식별자를 필드 또는 변수의 지정된 이름의 접두사로 배치하면 사용자가 이름을 입력하기 시작할 때 필드 또는 변수 이름으로 알파벳 순으로 이동할 수 있는 기능이 하위된다.예를 들어 파일메이커는 그러한 프로그래밍 환경 중 하나이다.이러한 프로그래밍 환경 중 하나를 사용할 때는 식별 문자가 있는 지정된 이름에 접미사를 붙이는 것이 더 나을 수 있다.

주목할 만한 의견

  • 로버트 세실 마틴(헝가리 표기법 및 기타 모든 형태의 인코딩):

    ...요즘 HN과 다른 형태의 인코딩은 단순히 장애물이다.변수, 함수, 멤버 또는 클래스의 이름이나 유형을 변경하기가 더 어려워진다.그들은 코드를 읽는 것을 더 어렵게 만든다.그리고 그들은 인코딩 시스템이 독자를 오도할 가능성을 만들어낸다.[8]

  • Linus Torvalds(헝가리 시스템 반대):

    함수의 유형을 이름에 부호화하면(일명 헝가리 표기법) 뇌가 손상된다. 컴파일러는 그 유형을 어쨌든 알고 있고 확인할 수 있으며,[9] 프로그래머를 혼란스럽게 할 뿐이다.

  • Steve McConnell(앱 헝가리어용):

    헝가리식 명명법은 더 이상 널리 사용되지 않지만, terse, 정밀한 약어로 표준화하는 기본 개념은 계속 가치를 가진다.표준화된 접두사를 사용하면 컴파일러에서 확인할 수 없는 추상 데이터 유형을 사용할 때 유형을 정확하게 확인할 수 있다.[10]

  • Bjarne Stroustrup(C++용 헝가리어 시스템 반대):

    아니 나는 '헝가리 사람'을 추천하지 않는다.나는 '헝가리어'(변수 이름에 한 유형의 축약 버전을 내장)를 형식화되지 않은 언어에서는 유용할 수 있지만, 일반 프로그래밍과 객체 지향 프로그래밍을 지원하는 언어로는 전혀 부적합하다고 본다. 이 두 언어 모두 유형과 인수에 기초한 연산 선택(la에 알려져 있음)을 강조한다.nguage 또는 런타임 지원).이 경우 '물체의 유형을 이름으로 구축한다'는 것은 단순히 추상화를 복잡하게 만들고 최소화한다.[11]

  • Joel Spolsky(앱 헝가리어용):

    시모니의 논문을 자세히 읽어보면, 그가 얻고 있는 것은 내가 위의 예에서 사용했던 것과 같은 종류의 명명규칙이었다.us안전하지 않은 문자열과s안전한 끈을 의미했다.그들은 둘 다 타입이다.string. 컴파일러는 당신이 하나를 다른 것에 할당하면 당신을 돕지 않을 것이고 인텔리센스 [지능형 코드 완성 시스템]는 당신에게 buckis를 알려주지 않을 것이다.그러나 그들은 의미론적으로 다르다.그것들은 다르게 해석되고 다르게 취급되어야 하며 만약 당신이 다른 것에 하나를 할당하거나 런타임 버그를 갖게 된다면 어떤 종류의 변환 기능이 호출될 필요가 있을 것이다.운이 좋으면.앱 헝가리어에게는 여전히 엄청난 가치가 있는데, 코드의 정렬을 증가시켜 코드의 읽기, 쓰기, 디버그 및 유지보수를 용이하게 하고, 가장 중요한 것은 잘못된 코드를 잘못 보이게 만든다는 점에서....(시스템즈 헝가리어)는 시모니의 의도와 실천에 대한 미묘하지만 완전한 오해였다.[12]

  • Microsoft의 설계 지침은[13] 개발자가 의 요소 이름을 선택할 때 Systems Hergan 표기법을 사용하는 것을 방해한다.NET급 라이브러리는 Visual Basic 6 및 이전 버전과 같은 이전 Microsoft 개발 플랫폼에서 공통적으로 사용되었지만,이 설계 지침은 기능 내부 변수에 대한 명명 규칙에 대해 언급하지 않는다.

참고 항목

참조

  1. ^ "Oral History of Charles Simonyi" (PDF). Archive.computerhistory.org\accessdate=5 August 2018.
  2. ^ a b Charles Simonyi (November 1999). "Hungarian Notation". MSDN Library. Microsoft Corp.
  3. ^ "Mozilla Coding Style". Developer.mozilla.org. Retrieved 17 March 2015.
  4. ^ "Webkit Coding Style Guidelines". Webkit.org. Retrieved 17 March 2015.
  5. ^ "Why would a JavaScript variable start with a dollar sign?". Stack Overflow. Retrieved 12 February 2016.
  6. ^ Jones, Derek M. (2009). The New C Standard: A Cultural and Economic Commentary (PDF). Addison-Wesley. p. 727. ISBN 978-0-201-70917-9.
  7. ^ "Make an app for any task - FileMaker — An Apple Subsidiary". Filemaker.com. Retrieved 5 August 2018.
  8. ^ Martin, Robert Cecil (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Redmond, WA: Prentice Hall PTR. ISBN 978-0-13-235088-4.
  9. ^ "Linux kernel coding style". Linux kernel documentation. Retrieved 9 March 2018.
  10. ^ McConnell, Steve (2004). Code Complete (2nd ed.). Redmond, WA: Microsoft Press. ISBN 0-7356-1967-0.
  11. ^ Stroustrup, Bjarne (2007). "Bjarne Stroustrup's C++ Style and Technique FAQ". Retrieved 15 February 2015.
  12. ^ Spolsky, Joel (2005-05-11). "Making Wrong Code Look Wrong". Joel on Software. Retrieved 2005-12-13.
  13. ^ "Design Guidelines for Developing Class Libraries: General Naming Conventions". Retrieved 2008-01-03.

외부 링크