헝가리어 표기법을 사용하지 않기 위해 고군분투


10

Systems Hungarian 에 대한 논쟁을 보았습니다 . 몇 년 동안 나는 모든 변수의 이름을 지정 하여이 시스템을 사용하는 레거시 프로젝트를 수행 해 왔으며 변수 유형의 접두사 (예 : strName, intAge, btnSubmit 등)를 사용하여 기능을 수행했습니다. 변수가 아닌 유형). 다음 프로젝트에서 완전히 포기하기를 원하지만 비슷한 것들에 의지하지 않고 고유 한 이름을 지정하는 것이 더 어렵다는 것을 알게되었습니다.

이메일 주소를 수집하여 데이터베이스 테이블에 저장하는 웹 양식과 주소를 db에 저장하는 기능을 호출하는 버튼이 있다고 가정 해 보겠습니다.

내가 헝가리어 스타일 표기법을 사용하고 있다면,이 상자를 호출 할 수 txtEmail있는 버튼 btnEmail및 텍스트 상자에 포함 된 값을 strEmail. 그런 다음 기능 storeEmail(strEmail)을 사용하여 이메일을 저장할 수 있습니다 . 여기에 명확한 규칙이 있습니다. 각 변수가 무엇인지 분명합니다.

이러한 변수의 이름을 지정하는 가장 좋은 방법은 무엇입니까

  • 헝가리 시스템에 의지하지 않고
  • 오랫동안 혼란스럽게 만들지 않고
  • 내 프로젝트 전체에서 사용할 명확한 규칙이 있습니까?

2
고유 한 이름을 찾는 데 문제가있는 경우 나머지 이름 지정 규칙이나 함수 크기에 문제가있을 수 있습니다.

어떤 기술을 사용하고 있습니까? 이 접두사는 Web Forms에 적합합니다.
StuperUser

내가 (C #을 뒤로) ASP.NET을 사용하고 있습니다
fearoffours

@delnan-좀 더 자세히 설명해 주시겠습니까? 함수 크기가 고유 한 이름 지정을 더 쉽게 만드는 이유는 무엇입니까?
fearoffours

@fearofours : 더 작은 함수는 더 적은 변수를 필요로하며, 더 적은 변수는 분명히 더 적은 변수 충돌을 의미합니다. 물론 모든 변수를 가능한 가장 작은 범위에 넣었다고 가정합니다.

답변:


8

마지막 요점은 프로젝트 전체 및 동료와 일관성을 유지하는 데 필요한 모든 것입니다. 일관성을 유지하는 두 가지 주요 방법이 있으며 가능하면 두 가지를 모두 사용해야합니다. 먼저 도구를 사용하여 빌드시 이름 지정 규칙을 확인하십시오. .Net 세계에서 StyleCop은 그러한 도구의 좋은 예입니다. 일관성을 얻는 두 번째 방법은 모든 코드를 동료 검토하여 모든 사용자가주의를 기울일 수 있도록하는 것입니다.

다른 두 가지 요점이 대안에 대해 묻는 것 같습니다. 대안이 필요한지 확실하지 않습니다. 헝가리어가 더 이상 대중적이지 않다는 요점은 타입 시스템과 툴이 조금만 사용되었을 때 타입을 설명하는 데 사용되었다는 것입니다. 즉, C로 프로그래밍하고 유형을 추적하는 유일한 방법으로 포인터를 전달하는 경우 헝가리어를 사용하는 것입니다. 이제 C # 또는 Java와 같은 언어를 사용하는 경우 포인터를 사용하지 않거나 매우 드물게 헝가리어가 필요하지 않습니다. 또한 최신 IDE를 사용하면 변수 위로 마우스를 가져 가거나 최악의 경우 바로 가기를 사용하여 원래 선언을 확인하여 유형을 매우 쉽게 볼 수 있습니다. 그래서 나는 당신이 어떤 종류의 표기법이 필요하지 않다고 생각합니다. 변수에 따라 변수의 이름을 지정하십시오. 이메일 주소 인 경우 "이메일"또는 "


2
폼 / 페이지 / 윈도우 / 무엇이든 이메일 버튼, 이메일 텍스트 상자, 이메일을위한 또 다른 위젯 / 컨트롤이있을 때 약간 까다로워집니다.
FrustratedWithFormsDesigner

7
@FrustratedWithFormsDesigner 반드시 그런 것은 아닙니다. 텍스트 상자는 emailAddressInput 일 수 있으며, 여기서 버튼은 emailAddressSubmit이고 내부 표현은 단순히 emailAddress입니다.
Jonathan

@Jonathan : 좋은 지적입니다.
FrustratedWithFormsDesigner

3

웹 양식 / Windows 양식 / 기타 그래픽 관련 사항을 처리 할 때는 텍스트 상자 및 레이블과 같이 매우 밀접하게 연결된 컨트롤을 가질 수 있으므로 Systems Hungarian을 사용하는 것이 좋습니다. 당신은 그 이름을 지정할 수 있습니다 txtEmaillblEmail구별 할 수 있습니다. 내 경험상 이것은 일반적이며 실제로 유용합니다.

그러나 코드 숨김에서 이러한 종류의 이름 지정은 필요하지 않습니다. string이메일을 저장하는 데 사용되는 변수 유형이있는 경우 이름을 지정하십시오 email. 어떤 이유로 혼란 스러울 경우 대부분의 IDE에서 마우스를 가져 가서 유형을 볼 수 있어야합니다. (사실, OO 분야에서는 일부 객체의 속성 일 수 있으며 user.Email더 명확합니다.)

GUI 컨트롤이 아닌 코드에 선언 된 객체가 둘 이상 있다고 생각되면 email본질적으로 디자인에 문제가 있다고 생각 합니다.


1
실제로 txt 및 lbl은 헝가리어가 아니며, txt는 텍스트의 짧은 텍스트이고 lbl의 레이블이 짧기 때문에 양식에 EmailText 및 EmailLabel과 같은 전체 길이 단어를 사용하지 않는 이유는 없습니다. 헝가리어는 두 가지 경우 모두 문자열 인 유형입니다.
Steve

1
@Steve Haigh-아니요, 컨트롤 자체에 대해 이야기하고 있습니다. txtEmail이라는 "textbox"유형의 객체와 lblEmail이라는 "label"유형의 객체가 있습니다. 둘 다 문자열이 아닙니다. 문자열 속성 이 있을 수 있지만 문자열 자체는 아닙니다.
앤드류 아놀드

1
아 죄송합니다 네 물론 이죠 그럼에도 불구하고 EmailTextBox와 같이 더 구체적인 이름을 사용하지 않을 이유는 없습니다. VS가 나쁜 이름을 생성한다고해서 그것을 유지해야한다는 의미는 아닙니다. 그러나 양식의 맥락에서 txt 및 lbl 약어는 너무 잘 이해되어 있으므로이 경우 걱정하지 않을 것입니다.
Steve

3

변수를 "길게"만드는 이유는 무엇입니까?

대신 txtEmail, btnEmail당신이 사용할 수있는 UserEmailText, UserEmailButton그리고 AdminEmailText,AdminEmailButton

이 문제는 변수가 길어지기 시작한다는 느낌이들 수 있습니다.

AdminEmailIsValid 변수가 얼마나 오래 허용되는지 경계선에서 시작합니다.

또한 변수 집합과 해당 변수에 대한 작업 집합을 재사용한다는 사실을 알기 시작할 수 있습니다. 이것은 OOP가되는 것입니다 설계 를 위해. 변수 세트 대신 일반 객체를 만듭니다.

class EmailForm
  var textBox, button, text
  function storeEmail()

그런 다음 새 변수를 클래스로 인스턴스화하고 동일한 점 표기법을 사용하여 데이터에 액세스 할 수 있습니다.

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

물론 이것은 OOP 패러다임을 사용하는 언어를 대상으로하지만 인기있는 웹 개발 언어의 대부분은 객체 지향이거나 객체 지향 코드 (PHP, Python, C #, C ++, Java, JavaScript, ActionScript 등)를 허용합니다. ).


txtEmail에 UserEmailText의 장점을 보지 못했습니다. 접두사 대신 접미사입니다. 그래도 "이것은 OOP를위한 것"입니다.
fearoffours

@fearoffours 고유 이름과 관련된 문제가 인정 OP는, I는 두 개의 유사한 변수 (구별을 설명하는 방법으로 그 일례를 첨가 UserEmailText하고 AdminEmailText구체적으로). 나는 그것이 클래스에 이동 빌려 준다로서 일반적으로 접미사 유형 UserEmailText-> UserEmail.text-> User.email.text에 따라 얼마나 많은 추상화 / 기능이 필요합니다.
zzzzBov

좋아, 어디에서 왔는지 보라. 접미사 / 클래스 비교의 경우 +1 아, 그리고 나는 OP입니다!
fearoffours

@fearoffours, lol whoops ...
zzzzBov
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.