권력의 헝가리: 헝가리 기호의 근황

전 세계 프로그래밍 사고에서 헝가리 기호처럼 보편적인 비난을 받는 개념은 드물다.모든 사람들이 그것이 전혀 필요없고 심미적으로 불쾌하며 해롭다고 여긴다1.만약 당신이 익숙하지 않다면, 이 생각은 일반적으로 다음과 같이 해석된다.

Hungarian notation is a naming convention that adds a prefix to each variable name, so as to encode its type in its name.

사람들은 보편적으로 이런 예를 받아들인다.

string str_firstName;

int i_ageInYears;

bool b_enabled;

대다수의 사람들은 이 점을 즉각 부정하기를 좋아한다.그것을 GOTO 인터넷 익스플로러 8과 함께 공인된 엉터리 프로그래밍 사상의 쓰레기통에 버려라.언뜻 보면 원인을 알아보기 어렵지 않다.프로그래머는 천성적으로 게으르다.변수의 유형을 이름 인코딩으로 설명하는 것은 믿을 만한 이유가 없다. 이것이 바로 우리가 컴파일러의 목적이다.만약 네가 타자를 칠 수 있을 정도로 멍청하다면, 너는 컴파일러의 어떠한 학대도 받아야 한다.분명히 이 두 일은 같은 일이 아닐 것이다.맞습니까?
너는 이렇게 생각할 수 있지만, 나는 모든 사람이 다 아는 사적이 아니다.자, 우리 함께 생각해 봅시다.

나는 먼저 백서를 인용할 것이다. 왜냐하면 그것은 다른 사람이 읽은 적이 없는 것 같기 때문이다.

...the concept of "type" in this context is determined by the set of operations that can be applied to a quantity. The test for type equivalence is simple: could the same set of operations be meaningfully applied to the quantities in questions? If so, the types are thought to be the same. If there are operations that apply to a quantity in exclusion of others, the type of the quantity is different.

Note that the above definition of type (which, incidentally, is suggested by languages such as SIMULA and Smalltalk) is a superset of the more common definition, which takes only the quantity's representation into account. Naturally, if the representations of x and y are different, there will exist some operations that could be applied to x but not y, or the reverse.²

The whitepaper 공교롭게도 찰스 시몬니가 썼다.너는 아마 그를 들어 본 적이 없을 것이다. 그러나 너는 틀림없이 그의 일을 잘 알고 있을 것이다.그는 마이크로소프트 워드와 마이크로소프트 엑셀3의 배후다.그는 지금 아마도 요트에 있을 것이다. 4 그는 거의 너보다 똑똑할 것이다.
어쨌든, 나는 더욱 정확한 유형 정의를 생각해 내기 어렵다.나와 이야기한 대부분의 소프트웨어 개발자들은'유형'은 하나의'물건'이라고 생각한다. 예를 들어 int result = firstName + ageInYears;,int 또는string은 주어진 값 유형에 대한 조작을 정의한다.비록 그들이 틀리지 않았지만 5, 나도 그들이 옳다고 말할 수 없다. 왜냐하면 이 정의는 너무 광범위하기 때문이다."바다란 무엇인가?""오, 이것은 네가 물에 잠길 수 있는 물건이야."물론 이것은 거짓 진술이 아니다.하지만 그 이유로 내 욕실에는 바다가 있었다.
만약 당신이 왜 이것이 큰 문제인지 이해하지 못한다면, 우리는 간단한 예를 개술합시다.누군가의 나이bool를 저장하는 값과 저장int의 순환 인덱스 값int을 저장하는 값이 다르다는 것을 알고 있다.컴파일러는 이 점을 모른다. 만약 당신이 교체기의 인덱스로 누군가의 나이를 곱하려고 한다면, 그들이 모두 fors라면 컴파일러는 기뻐할 것이다.그런데 프로그램이 정확해요?
단지 수술이 가능하다고 해서 그것이 정확하다는 것은 아니다.
그래서 어쨌든 Simonyi는 프로그래머에게 도구를 제공하여 int와 x의 표시가 다르게 함으로써 효과적이지만 무의미한 조작을 막도록 명명 약정을 계속 제안했다.
Microsoft Excel의 또 다른 예를 살펴보겠습니다.스프레드시트에서 가장 중요한 두 원어는 행 및 열입니다.만약 C 언어로 전자 표를 만들어야 한다면, 먼저 다차원 그룹인 열의 줄을 정의해서 데이터를 저장하고, 줄과 열의 색인 좌표에 데이터를 저장하는 칸을 표시할 수도 있다.색인을 통해 그룹의 항목에 접근할 수 있기 때문에, 이것은 y 서명된 함수를 작성할 수 있음을 의미합니다.이것은 좋은데, 입력을 줄과 열로 바꿀 때 무슨 일이 일어날까요?함수 void clearCellData(int rowIndex, int columnIndex) 를 작성했지만 의외로 열 인덱스로 전송되었을 때 어떤 일이 일어날까요?컴파일러는 항상 만족스러웠고, 실행할 때 오류가 발생하지 않았지만, 오류 줄의 모든 칸을 삭제했다.6
만약 백서에 개술된 헝가리 기호를 자세히 따른다면 이런 실수를 범할 수 없을 것이다.행을 나타내는 각각void clearRow(int rowIndex)이 int을 접두사로 하고, 열을 나타내는 각각row_이 int을 접두사로 하면 호출col_이 훨씬 낮아진다.여러분, 이것이 바로 헝가리 기호 뒤의 실용주의입니다.백서에서 clearRow(col_selected)s가string와 str_s가int를 언급한 곳은 없다. 단지 그것들이 i_s와strings이기 때문이다.
그래, 이것은 당연히 그렇게 나쁘게 들리지는 않지, 그렇지?

문제는 다른 사람들이 모두 잘못한 것 같다.

헝가리 기호를 연구하는 데 충분한 시간7이 걸리면 찰스 페조르드라는 이름을 발견할 수 있다.이 특별한 찰스도 마이크로소프트의 중요한 프로그래머이다. 그는 이라는 책에서 이렇게 설명했다.

Many Windows programmers use a variable-naming convention known as "Hungarian Notation," in honor of the
legendary Microsoft programmer Charles Simonyi. Very simply, the variable name begins with a lowercase letter or letters that denote the data type of the variable. For example, the sz prefix in szCmdLine stands for "string terminated by zero." The h prefix in hInstance and hPrevInstance stands for "handle;" the i prefix in iCmdShow stands for "integer."⁸

이렇게!이것이 바로 그가 이 화제에 관한 모든 진술이다.허허.나는 다른 찰스가 백서를 읽지 않았다고 추측한다.불행히도 이런 관점은 이미 광범위하게 채택되었다.여기서 중요한 차이점은 헝가리 기호 뒤에 있는 사상이 의미를 주목하는 것이지 컴파일러나 출력 처리 데이터가 아닌 의미를 주목하는 것이다.
만약 네가 계속 관심을 가지고 있다면, 나는 일찍이 "명명 관례가 헝가리 기호의 배후 원인이다"라고 말하지 않았다는 것을 알게 될 것이다.이것은 단지 그것의 실용주의를 추진하는 것일 뿐이다.헝가리 기호의 배후 원인은 에서 강제로 주입된 모든 Elm 개발자들에게 익숙해져야 한다.
목표는 영원히 네가 알고 있는 것을 확보하는 것이 아니다int는int.이것은 프로그램이 의미상의 효과적인 계산만 할 수 있도록 더 좋은 도구를 제공하기 위해서이다.

9 잠깐만, 그러니까 건의하는 거 아닐 거야...

... 너는 나가서 의미 정보로 모든 프로그램의 값에 접두사를 붙였니?그래, 물론 나쁠 것은 없지만, 이러한 생각들이 도입된 지 40여 년 동안, 우리는 더 좋은 도구를 세우고, 이 문제들에 대해 더 많은 생각을 해 왔다.우리는 더 낫다. 우리는 더 잘할 수 있다.
우리는 Elm이 있고, Elm에는 사용자 정의 유형이 있으며, 사용자 정의 유형을 통해 우리는 도메인에 특정한 유형을 쉽게 실현할 수 있다.Elm Patterns라는 책은 유형맹 에 관한 장에서 이 점을 간략하게 요약했다. Joel Quenneville는 이 각주의 링크10에서 응용 모델에 대해 뛰어난 시범을 보였지만 나는 여기서 총괄할 것이다.
앞의 예에서 우리가 2차원 그룹을 가지고 있다고 가정하면 색인11을 통해 이 그룹에 접근해야 한다. 우리는 사용자 정의 형식 포장int 값을 다음과 같이 사용할 수 있다.

type RowIndex = RowIndex Int

type ColIndex = ColIndex Int

갑자기 우리는 프로그램의 의미를 컴파일할 때 검증했다.
우리는 계속할 수 있어!포장 원어는 우리가 원어 값을 사용해야 할 때 그것을 전개해야 한다는 것을 의미한다. (즉 어떤 형식의 Int. 이것은 별도의 작업이다. 그러나 이것은 가치가 있다. 왜냐하면 지금 우리는 값에 대해 어떤 조작을 해야 하는지를 더욱 자세하게 고려해야 하기 때문이다.우리는 이미 프로그램의 의미를 고려하는 영역에 들어갔다. 이것은 우리가 현재 우리의 값을 사용할 수 있는 동력을 가지고 있다는 것을 의미한다.고려 사항:

nextRowIndex : RowIndex -> RowIndex
nextRowIndex (RowIndex index) =
    RowIndex (index + 1)

prevRowIndex : RowIndex -> RowIndex
prevRowIndex (RowIndex index)
    RowIndex (index - 1)

현재, 만약 우리가 의외로 (\(RowIndex index) -> index)을 ColIndex에 전달한다면, 우리는 의미가 정확하지 않은 값을 되돌려 주지 않을 것이다. 우리의 코드는 컴파일할 수 없을 것이다.만약 함수 서명이 모든 원어를 사용했다면 nextRowIndex 이런 결과를 얻지 못했을 것이다.
이것은 매우 강대하다.값의 의미를 이 값을 저장하고 인용하는 유형의 정의에 포함시키면 컴파일러를 사용하여 프로그램의 정확성을 검증할 수 있다. Elm을 사용하면 이를 실현할 수 있는 도구가 있다.이것은 확실히 헝가리 기호가 발전하고 나타난 정신이다.Elm 개발자가 작성nextRowIndex : Int -> Int할 때마다 이런 정신은 계속 존재한다.

12 어쨌든 엘엠은 헝가리 부호다.시간 내주셔서 감사합니다.아니, 그만, 어디로 가려고?나는 우리가 친구인 줄 알았다

읊다, 읊조리다언제든지 전화해.
  http://catb.org/jargon/html/C/considered-harmful.html
↩   https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa260976(v=vs.60)#type-calculus
↩   https://en.wikipedia.org/wiki/Charles_Simonyi#Microsoft
↩   https://en.wikipedia.org/wiki/Charles_Simonyi#Personal_life
↩   https://rationalwiki.org/wiki/Not_even_wrong
조어는 여기서 이 점을 이야기했다. 그의 산문은 나보다 훨씬 좋았다. ↩. 그러나 그는 여전히 내가 이 글에서 논술하고자 하는 요점을 잡지 못했다.나는 곧 도착할 것이라고 장담한다.  https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/
최대 5분↩
"charles petzold programming windows online"의 가장 핫한 검색 결과는 이 대략적인 공공 Google Drive 링크입니다. 다운로드 가능: ↩https://docs.google.com/file/d/0B73JwvIHVHaiSFdpekJCOUdoeE0/view?resourcekey=0-JFez95uS9jETJQdFGKY_1w
  ↩
↩   https://sporto.github.io/elm-patterns/basic/type-blindness.html
↩   https://thoughtbot.com/upcase/videos/domain-specific-types-in-elm
나는 색인을 통해 그룹에 접근하는 값이 간단하지 않다는 것을 알고 있지만, 그것은 설명에 부합된다.만약 그것이 더러운 낡은 자바스크립트와 상호작용을 하기 위해서라면 ↩