변수 이름 앞에 변수 유형의 약어를 사용합니까? (헝가리어 표기법) [닫힘]

현재 직장에는 코딩 지침이 없습니다. 모든 사람이 원하는 방식으로 코딩합니다. 회사가 작기 때문에 괜찮습니다.

그러나 최근 한 명의 새로운 남자가 항상 헝가리 표기법을 사용하도록 제안했습니다. 지금까지 우리 중 일부는 일종의 헝가리 표기법을 사용했지만 일부는 그렇지 않았습니다. 아시다시피 엔지니어링 회사이므로 알고리즘이 올바른 한 코딩 스타일은 실제로 중요하지 않습니다.

개인적으로, 나는이 작은 유형 약어가 일종의 중복이라고 생각합니다. 잘 생각한 이름은 대개 같은 메시지를 전달합니다. 또한, 대부분의 코드는 개념 이 존재 bool하거나 float존재하지 않는 이상한 DSP에서 실행되어야합니다 .

헝가리어 표기법에 대해 어떻게 생각하십니까? 당신은 그것을 사용합니까? 왜?

대부분의 사람들이 "헝가리어 표기법"이라고 할 때 실제로 " 시스템 헝가리어 " 에 대해 말하는 것 입니다.

시스템 헝가리어는 완전히 쓸모가 없으므로 피해야합니다. 변수의 이름에 변수 유형 을 인코딩 할 필요가 없습니다 . 그러나 시스템 헝가리어는 실제로 원래 "실제"헝가리어 인 Apps Hungarian에 대한 오해입니다 .

Apps Hungarian에서는 변수 이름에 "유형"을 인코딩하지 않고 변수의 "종류"를 인코딩합니다. 그래서하지 nWidth하지만 pxWidth또는 emWidth( "EMS 폭", "픽셀 폭"또는 각각의 경우). 아니 strName하지만 sName나 usName(각각 "안전 이름"또는 "안전하지 않은 이름"에 대한 - 사용자의 유용한 받아들이는 입력 : 안전하지 않은 문자열).

개인적으로, 나는 보통 어느 쪽도 귀찮게하지 않습니다. 값의 "종류"를 명시 적으로 변환하는 작업을 수행하지 않는 한 (예를 들어, 과거에는 "px"및 "em"접두어를 사용했습니다 pxArea = emWidth * emHeight. 실수는 분명해 보입니다 .)

Joel의 기사 " 잘못된 코드를 잘못 보이게 만들기 "도 참조하십시오 .

대명사 당신은 동사를 부사하지 않아야한다 동사는 형용사를 쓰지 않는다

먼저 :

아시다시피 엔지니어링 회사이므로 알고리즘이 올바른 한 코딩 스타일은 실제로 중요하지 않습니다.

코딩 스타일은 회사와 상관없이 중요합니다. 그렇습니다. 알고리즘 은 견고 해야 하지만 코드 는 원래 개발자뿐만 아니라 모든 사람이 관리 할 수 있어야합니다 . 스타일 요소를 포함하는 코딩 표준을 사용하면이를 달성 할 수 있습니다. 나는 모든 코드가 스타일면에서 동일해야한다고 말하지는 않습니다. 이는 생산적이지만, 일관성이 있어야합니다.

이제 헝가리어 표기법으로 :

IntelliSense 유형 동작을 지원하는 최신 IDE를 사용하면서 이름에 변수 유형을 포함시킬 필요는 없습니다. 이 정보는 다른 방법으로 제공됩니다. 최악의 경우 나중에 변수 유형을 변경해야하는 경우 코드를 읽기가 더 어려워 질 수 있습니다.

사용하지 마십시오. 중복되어 코드를 읽기 어렵게 만듭니다.

(시스템) 헝가리 표기법에 대한 많은 논쟁은 작업 분야에 달려 있습니다. 예전에는 "안돼!" .

헝가리어 시스템

내가 알 수 있듯이 Systems Hungarian은 임베디드 분야에서 많이 사용되는 경향이 있습니다. PC 응용 프로그램에서 컴파일러는 문자열, 정수 및 부동 소수점 값의 차이와 관련된 많은 문제를 처리합니다. 깊이 포함 된 플랫폼에서는 8 비트 부호없는 정수, 16 비트 부호있는 정수 등의 차이점에 대해 더 자주 우려합니다. 컴파일러 (또는 MISRA 규칙이 적용된 보푸라기)가 항상 이러한 요소를 선택하지는 않습니다. 변수 이름이 좋아 가진이 경우 u8ReadIndex, s16ADCValue도움이 될 수 있습니다.

헝가리어 앱

Apps Hungarian은 PC / 웹 응용 프로그램과 관련하여 확실한 이점을 제공합니다. 예를 들어 '안전하지 않은'문자열과 '안전한'문자열 (예 : 사용자가 입력 한 문자열과 내부 리소스에서 이스케이프되거나 읽은 문자열) 사이의 시각적 차이를 제공 ). 컴파일러는이 차이점을 알지 못합니다.

점은 무엇인가?

(시스템 또는 앱) 헝가리어 사용은 잘못된 코드 를 잘못 보이게하는 것 입니다.

안전하지 않은 문자열을 탈출하지 않고 안전한 문자열로 똑바로 복사하는 경우 Apps Hungarian을 사용하면 잘못 보입니다.

부호있는 정수에 부호없는 정수를 곱하는 경우 컴파일러는 부호있는 정수를 부호없는 정수로 조용히 올리는 경우가 많으며 오류가 발생할 수 있습니다. 시스템 헝가리어에서는이 오류를 잘못 표시합니다.

이 두 가지 상황에서 (Apps / Systems) 헝가리어 표기법은 변수 유형에 대한 참조가 적기 때문에 공식 코드 검토가 더 빨라지는 경향이 있습니다.

사무용 겉옷

전반적으로, 제 의견은 가장 중요한 것은 코딩 표준이 있다는 것입니다. 이것이 시스템 헝가리어를 사용하든 Apps 헝가리어를 사용하든 또는 들여 쓰기 유형 선택과 마찬가지로 개인 또는 그룹 선호도의 문제는 아닙니다. 그러나 전체 개발 팀이 동일한 선호도를 사용하는 것은 분명한 이점이 있습니다.

헝가리 표기법의 목적은 정보를 유형 시스템에서 인코딩 할 수없는 식별자로 인코딩하는 것입니다. 내 의견은이 정보가 인코딩되기에 충분히 중요하다면 올바르게 확인할 수있는 유형 시스템에서 인코딩하기에 충분히 중요하다는 것입니다. 그리고 정보가 중요하지 않다면 왜 소스 코드를 혼란스럽게 만들고 싶습니까?

또는 더 간결하게 말하면 유형 정보는 유형 시스템에 속합니다. (참고 : 정적 유형 시스템 일 필요는 없습니다. 유형 오류를 잡는 한 언제 오류를 잡든 상관하지 않습니다 .)

다른 두 답변은 측정 단위를 헝가리 표기법의 용법으로 언급했습니다. (헝가리 표기법에 대한 토론에서 항상 NASA Mars Climate Orbiter를 언급 한 사람이 없기 때문에 놀랍습니다.)

다음은 F #의 간단한 예입니다.

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

봐, 엄마, 헝가리 인은 없어!

내가하면 있었다 대신 여기 종류의 헝가리어 표기법을 사용하는 것을 나에게 조금이라도 도움이되지 것입니다 :

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

컴파일러는 바로 그것을 통해 보냈습니다. 나는 본질적으로 유형 오류가 무엇인지 발견하기 위해 인간 에 의존하고 있습니다. 타입 체커가 아닌가?

Frink 프로그래밍 언어를 사용하는 것이 더 좋습니다 .

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

그래서 요약하면, 나는 헝가리 표기법을 좋아하지 않습니다. 절대 사용해서는 안됩니다.

헝가리어 표기법을 사용하는 것이 좋습니다. 무엇을 기다립니다?

예! 이 특별한 경우에 , 당신은 언급했다 :

또한 대부분의 코드는 bool 또는 float와 같은 개념이 존재하지 않는 이상한 DSP에서 실행되어야합니다.

그러나 즉 정확하게 유일한 합리적인 사용 사례 에 대한 헝가리어 표기법!

추신 : 나는 진심으로 Frink를 보는 것이 좋습니다. 이 매뉴얼에는 가장 멋진 방귀 농담이 포함되어 있습니다. 또한 꽤 멋진 언어입니다 :-)

객체 지향 언어에서는 의미가 없습니다. 모든 것을 사용하려고 할 때 분명한 유형입니다.

Systems Hungarian 이 보증 하는 유일한 장소 는 C와 같이 약한 유형의 언어를 사용하는 것입니다. 명시 적 객체가 없기 때문에 C와 함께 중요합니다 (구조체는 있지만 모든 함수는 구조 외부에 있습니다). C ++, Java 및 C #과 같이 더 강력하게 입력하면 도움이되지 않으며 실제로 상황이 악화됩니다. 코드가 변경되며 변수 이름을 사용하는 모든 장소를 변경하는 것보다 유형을 변경하는 것이 훨씬 쉽습니다. 또한 무시되는 경향이있는 불필요한 바쁘다.

측정 단위가있는 경우 이름으로 인코딩하는 것이 도움이 될 수 있지만 결국에는 노이즈가 추가 될 수 있습니다. 예를 들어, 코드에서 다루고있는 다양한 것들에 대한 표준 측정 단위를 선언 할 것입니다. 예를 들어 그라디언트 또는 각도, 미터 또는 피트, 프레임 또는 밀리 초를 사용합니까? 코드에 대한 표준이 설정되면 한 측정 단위로 읽을 때마다 항상 코드의 표준 측정 단위로 즉시 변환됩니다.

내 조언 : 현재의 고통 지점에서 시작하여 코드의 해당 부분에 대한 합리적인 표준을 선택하십시오. 코딩 표준을 과도하게 지정하면 비생산적입니다. 변수와 필드 이름이 나타내는 것을 나타내는 많은 가치가 있으며, 대부분 개념에서 유형을 안전하게 유추 할 수 있습니다.

안돼!

헝가리어 표기법이나 다른 표기법을 사용하지 마십시오. 프로그래머로서 변수 이름에 "표기법"을 사용해서는 안됩니다.

우리가해야 할 일은 변수의 이름을 잘 지정하는 것입니다 .

• 너무 일반적인 이름은 피하십시오. z전화 요금 청구서와 같은 명명 된 개체를 나타내는 클래스 변수 인 경우 이름을 지정하지 마십시오 . phoneBill또는로 전화하십시오 PhoneBill.

• 너무 구체적인 이름은 피하십시오. 추가 정보없이 명확한 것이 있으면 포함하지 마십시오. 문자열의 문자를 반복하는 문자열 인덱스 변수이고 MyFunc 함수에서 한 번만 사용하면 왜 지구상에서 호출 MyFuncTempStringCharacterIndex합니까? 슬픈 농담이야. 전화를 Pos하거나 i원하는 경우 에도 전화하십시오 . 맥락에서, 다음 프로그래머는 그 의미를 쉽게 이해할 것입니다.

• 이름이 얼마나 일반적이거나 구체적이어야하는지에 대해 언급 할 때는 이름이 속한 도메인과 다른 가능한 의미의 맥락을 고려하십시오. 같은 방식으로 사용되는 쉽게 혼동되고 비슷한 유형의 항목이 두 개있는 좁은 경우에는 그 차이를 나타내는 접두사 또는 접미사를 사용하는 것이 좋습니다. 가능한 짧게 유지하십시오.

다른 답변자들이 말했듯이, "앱 헝가리어"를 시작한이 좁은 경우는 창과 rwTabPosition문서 에 대한 측정 값을 구분 하는 것 rdTabPosition입니다. 그러나 문서와 관련된 모든 작업을 수행하는 응용 프로그램에는 추가 크래프트를 추가하지 마십시오! 실제로 Jörg W Mittag가 실제로 새로운 유형을 만드는 아이디어 를 사용하지 않겠습니까? 그러면 당신은 일을 혼동시킬 수 없습니다.

거의 모든 영역에서 최소의 의미 밀도를 가진 물질을 추가하면 전체적인 의미와 이해가 쉬워집니다. Ben Franklin 의 한 예가 있습니다 . 또 다른 예 : 영어로 말의 일부로 단어를 꾸밀 수 있습니다. 더 많은 정보입니까? 영어 초보자가 혼란 스러울 경우 실제로 도움이 될 수 있습니다. 이 내용을 읽고 이것이 장기 이해와 정보의 효율적인 전달에 얼마나 유용하다고 생각하는지 알려주십시오.

헝가리어 명사 cnjor adjany adjother nounotation. nouprogrammers, prowe vrbsh는 멍청한 형용사를 위해 "nounotation"prp를 뉘우 치지 않아야합니다.

정보 를 추가 함으로써 나는 그 책을 읽기가 완전히 어려워졌다.

따라서 표기법을 잊어 버리십시오. 항상 추가하는 특수 접두사를 잊어 버리십시오. 내 의견으로는, 여기에 유일한 실제 지침은 다음과 같아야합니다.

변수 이름은 가능한 짧고 필요한 만큼 의미 가 있으며 항상 명확해야 합니다.

식별자의 목적은 유형보다 중요합니다. 프로그램에서 식별자에 설명적인 이름을 사용하는 경우 헝가리어 표기법을 사용할 필요가 없습니다. isConnected보다 읽기 쉽고 이해하기 쉽습니다 boolConnected.

우리는 내가 C ++ 프로그래머 였을 때 헝가리어를 다시 사용했는데 훌륭했습니다. 선언을 검색하지 않고 변수 유형 (fe BSTR, CString, LPCTSTR 또는 char *)을 볼 수 있습니다. 당시에는 다음을 수행하여 선언을 검색합니다.

1. ctrl-home
2. Ctrl-F
3. 변수 이름
4. 들어가다

그래서 그것은 꽤 중요했습니다. 그러나 2000 년경 몇 가지 일이 일어났습니다.

• 편집기는 변수 유형을 툴팁으로 표시 할 수있을 정도로 지능적으로되었습니다
• 편집자에게는 "선언으로 이동"바로 가기와 빠른 탐색 방법이있었습니다.
• C ++은 덜 사용되었으며 대부분의 다른 언어에는 변수 유형이 적습니다. 예를 들어 C #에서는 문자열 클래스가 하나만 있기 때문에 lastNameis System.String입니다.

나는 헝가리어에서 마지막으로 전환 한 사람 중 하나였으며 이제는 오래된 소스 코드를 읽을 때 실제로 짜증납니다.

나는 헝가리어 표기법을 싫어하고 변수 이름을 구분하는 데 밑줄을 사용하는 것을 선호합니다.

또한 변수 이름의 시작 부분에 다음과 같이 유형을 첫 글자로 입력하면 float fvelocity; vect vDirection; 문자열 ** ppszWord;

자동 완성 기능이 모든 항목을 정렬하므로 원하는 것을 찾는 데 어려움을 겪고 사람들은 자신이 더 잘 생각하는 것을 사용하는 경향이 있으며 더 이상 표기법이 아닙니다.

변수를 매우 설명해야 할 때 ThingsLikeThat을 쓰고 싶습니다. 공간을 절약하고 뚜껑이 있기 때문에 더 읽기 쉽습니다.

내가 일반적으로하는 일은 첫 글자가 대문자이고 변수 이름은 소문자이고 변수 이름은 밑줄로 내 메소드와 클래스 이름을 지정하는 것입니다 (이 마지막 것이 유용합니다).

진지하게 나는 사람들이 그 규칙에 관심을 갖기를 선호합니다. 관련 공간에 쉼표, 산술 및 중괄호를 사용하십시오.

void f(int a, char b);
int a = b + 4 / (3 + 4);

한 줄에 80 문자를 넘지 않거나 AT MOST 90 문자는 함수 또는 long에 여러 줄 인수를 사용합니다 if.

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

대부분 오래된 스타일입니다.

최신 IDE에서는 변수 위에 마우스를 올려 놓으면 유형이 표시됩니다.