대소 문자 만 다른 변수 이름을 사용하는 것이 부도덕한가요?

예를 들어, 다음 코드를 사용하십시오.

var person = new Person();

또는 Pythonistas :

person = Person()

나는 이것이 얼마나 나쁜지 끊임없이 이야기하지만,이 두 줄의 코드가 부도덕 한 예를 아직 보지 못했습니다. 나에게 사람은 사람이고 다른 이름을 붙이는 것은 시간 낭비입니다. 구문 강조를 표시하기 며칠 전에는 이것이 큰 문제 였을 것입니다. 하지만 요즘에는 변수 이름과 별개로 유형 이름을 구분하는 것이 매우 쉽습니다. 도대체 여기에서 차이점을 쉽게 알 수 있습니다.

아니면 내가 놓친 것이 있습니까? 그렇다면 문제를 일으키는 코드의 예를 제공하면 도움이 될 것입니다.

이것이 나쁘다고 말하는 사람들의 이유는 무엇입니까? 나는 항상 이것을한다. 유형의 단일 변수에 이름을 지정하는 가장 간단하고 표현적인 방법입니다. 두 개의 Person객체가 필요하면 다음 person과 같은 의미있는 형용사를 접두사 로 붙일 수 있습니다.

fastPerson
slowPerson

그렇지 않으면 그냥

person

나도 괜찮아.

이 패턴을 메서드 서명에서 많이 사용합니다. IMHO를 설명하는 대체 이름을 제공 할 수 없다면 이것에 문제가 없습니다.

사람과 사람의 두 가지 유형이 있다면 그것은 매우 잘못된 것입니다.

나는 임시 객체 참조를 위해 항상 그것을 사용합니다. 원시 데이터 유형에 대한 전염병처럼 피할 것입니다.

Person person = new Person(); // okay

int Int = 42; // pure evil

누군가 그것이 악하다고 말하면 이것이 더 나은지 물어보십시오.

var abc = new Person();

그 사람이 문맥 상 일반적인 사람이라면 "사람"은 정말 좋은 이름입니다. 물론 Person이 코드에서 특정 역할을 가지고 있다면 역할을 사용하여 그녀의 이름을 지정하는 것이 좋습니다.

그렇게 말하면 반대 투표를받을 것 같지만 ...

장대 한 살인과 탐욕을 목격 한 지 한 세기가 지난 지금, 우리가 할 수있는 가장 부도덕 한 일이 변수에 이름을 붙이는 것이라면 우리 프로그래머들은 진정으로 축복을 받았습니다.

나는 그것이 반드시 "나쁘다"라고 생각하지는 않지만, 어떤 종류의 사람인지 (아마도 많은 가능한 사람 중 한 명만 다루고 있음)과 같이 더 많은 맥락을 제공하도록 자격을 부여 할 수 있다면 다른 사람이 그것을 선택합니다. 더 잘 이해할 수 있습니다.

Jason-이것이 나쁘다고 누가 말했는지 잘 모르겠습니다. 많은 저자가 이것을 클래스 (대문자) 의 인스턴스 (소문자)를 표현하는 표준 방법으로 사용합니다 .

나는 소문자 변수가 실제로 이것이 인스턴스 일뿐만 아니라 클래스의 이름임을 나에게 전달한다는 것을 알기 때문에 이것을 자주 사용합니다.

누군가가 그 반대에 대해 확고한 주장을하지 않는 한, 나는 확실히 이것을 계속할 것입니다.

그것이 나쁜 것으로 간주되는 이유는 미래에 2 명의 사람이 필요하다면 다음과 같은 코드로 끝날 수 있기 때문입니다.

Person person = new Person ();

Person person2 = new Person ();

그러면 "Bad"에 접하게됩니다. 그러나이 경우 두 사람을 구별하기 위해 원래 사람을 리팩토링해야합니다.

예를 들어 변수 이름 "person"은 개체 "Person"을 완벽하게 설명하는 이름입니다. 그러므로 그것에는 전혀 문제가 없습니다.

나는 그것이 무엇인지에 대한 이름을 말합니다 : 변수가 2 마리의 개를 가진 사람을 나타내면 그것을라고 부릅니다 personWith2Dogs. 변수의 범위가 짧으면 (루프 var처럼) 사람이 괜찮습니다.

나는 그것을 내 코드에서 많이 사용하고 그것에 문제가 없다고 생각합니다. 즉, 나는 (아마도) 하나의 화면보다 긴 메서드에서 사용하지 않을 것이며 Person 클래스의 인스턴스가 여러 개있는 경우 사용하지 않을 것입니다. 이름을 person1, person2, person3으로 지정하지 마십시오. 대신 person_to_del, person_to_ban, person_to_update 등과 같이 더 설명적인 것을 사용하십시오.

부도덕하지,하지만 글로벌 검색 모두를 찾을 수 Person및 person당신이 활성화 대소 문자 구분을하지 않을 경우. 나는 글로벌 검색 / 교체를 쉽게하기 위해 접두사를 선호하지만 절대적으로 헝가리어 나 길거나 복잡한 것은 아닙니다. 그래서 저는 ...

Person클래스 변수 의 인스턴스 변수에 대한 메소드 매개 aPerson변수의 로컬 변수에 thePerson대한 클래스 / 유형 myPersonourPerson

드문 경우 p지만 많은 참조가있는 로컬 컨텍스트에서 사용할 수 있지만 일반적으로 루프 인덱스 등에 적용됩니다.

때에 따라 다르지.

엄격한 대문자 스타일을 사용하여 변수가 소문자로 시작하고 (그리고 단어 분리에 under_scores 또는 camelCase를 사용) 클래스가 대문자로 시작하는 경우 person이 변수이고 Person이 클래스라는 것이 분명하며 누군가 이것을 이해하면 , 그들은 겹치는 네임 스페이스에있는 것 같지 않습니다. (마찬가지로, 사람들은 동사 또는 명사 "polish"와 형용사 "Polish"를 거의 혼동하지 않습니다.)

그런 스타일이 없다면 쉽게 혼동 될 수 있고 대소 문자 만 다른 두 개의 이름이 있습니다. 그 나쁜.

사람들이 사용하는 정확한 주장은 무엇입니까?

변수 이름으로 사람을 사용할 수없는 경우 'a'접두사를 추가하는 것이 좋습니다.

aPerson = Person()

당신이하는 일은 괜찮다고 생각합니다. 일반적으로 코딩 표준에 동의하는 것이 중요하다고 생각합니다.

예를 들어 인스턴스, 변수에는 lowerCamelCase를 사용하고 클래스에는 UpperCamelCase를 사용합니다.

코딩 표준은이 문제를 제거해야합니다.

성공적인 오픈 소스 프로그램을 보면 종종 코딩 표준이 있습니다.

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

코딩 표준에 동의하는 것이 이것에 대한 마지막 싸움이되어야합니다.

실제로 wikipedia 항목 ( http://en.wikipedia.org/wiki/CamelCase )을보십시오.

프로그래밍 및 코딩 스타일

소스 코드 작성을위한 코딩 스타일 가이드 라인 (예 : Mesa 프로그래밍 언어 및 Java 프로그래밍 언어)에 따라 단어 경계를 나타 내기 위해 내부 대문자를 사용하는 것이 좋습니다. 이러한 지침 중 일부에 포함 된 권장 사항은 소스 코드의 준수 여부를 확인하는 정적 분석 도구에서 지원됩니다.

이러한 권장 사항은 종종 UpperCamelCase와 lowerCamelCase를 구분하며 일반적으로 변수, 레코드 필드, 메서드, 프로 시저, 유형 등 특정 유형의 엔티티에 사용해야하는 다양성을 지정합니다.

널리 사용되는 자바 코딩 스타일 중 하나는 UpperCamelCase를 클래스에 사용하고 lowerCamelCase를 인스턴스와 메소드에 사용하도록 지정합니다. [19] 이 사용법을 인식하여 Eclipse와 같은 일부 IDE는 CamelCase를 기반으로하는 바로 가기를 구현합니다. 예를 들어 Eclipse의 컨텐츠 지원 기능에서 CamelCase 단어의 대문자 만 입력하면 일치하는 클래스 또는 메소드 이름이 제안됩니다 (예 : "NPE"를 입력하고 컨텐츠 지원을 활성화하면 "NullPointerException"이 제안 될 수 있음).

프로그래밍을위한 원래 헝가리어 표기법은 "사용 유형"(데이터 유형이 아님)에 대한 소문자 약어가 모든 변수 이름 앞에 UpperCamelCase에있는 이름의 나머지를 추가해야한다고 지정합니다. 따라서 lowerCamelCase의 한 형태입니다. CamelCase는 Java 및 Amiga 개인용 컴퓨터의 파일 이름에 대한 공식 규칙입니다.

Microsoft .NET은 매개 변수 및 비공개 필드에 lowerCamelCase를 권장하고 다른 유형의 식별자에는 UpperCamelCase (일명 "Pascal Style")를 권장합니다. [20]

파이썬은 클래스 이름으로 UpperCamelCase를 권장합니다. [21]

NIEM 레지스트리는 XML 데이터 요소가 UpperCamelCase를 사용하고 XML 속성은 lowerCamelCase를 사용하도록 요구합니다.

CamelCase 이름 내에 대문자 약어 (주로 약어 및 이니셜)를 포함하는 단일 규칙은 없습니다. 접근 방식에는 전체 약어를 대문자로 남기고 (예 : "useHTTPConnection") 첫 글자 만 대문자로 두는 것 (예 : "useHttpConnection")이 포함됩니다.

카멜 케이스는 결코 컴퓨팅에서 보편적이지 않습니다. 여러 현대 프로그래밍 언어, 특히 Lisp 및 Forth 제품군의 사용자는 거의 항상 하이픈을 사용합니다. 때때로 주어진 이유 중에는 대부분의 키보드에서 이동이 필요하지 않고, 단어가 분리 될 때 더 읽기 쉽고, 카멜 대소 문자가 대소 문자를 구분하지 않거나 대소 문자를 접는 언어 (예 : Common Lisp는 기술적으로 대소 문자를 구분하는 언어이지만 기본적으로 식별자를 대문자로 정규화 (접기)합니다.

그런 종류의 메서드 이름은 무해 할뿐만 아니라 양질의 코드를 나타내는 지표가 될 수 있다는 강력한 주장을 할 수 있습니다.

• 좋은 코드 세분성의 표시기 : 메서드가 짧고 단일 목적이며 설명 적으로 명명 된 경우 변수 이름에 많은 정보가 필요하지 않습니다. 많은 작업을 수행하고 많은 컨텍스트와 상태를 추적해야하는 긴 메서드가있는 경우 변수 이름은보다 설명 적이어야합니다.

• 범용 계산이 범용 방법으로 푸시되는 지표 : 비즈니스 방법에서 데이터 구조의 중간 조작을 수행하는 경우 (예 : 사용자 배열이 중복 제거되어야 함) 범위에 변수가 있어야합니다. 이름 등을 users[]하고 deduplicatedUsers[]. 중복 제거를 유틸리티 메서드로 이동하는 경우 메서드를 호출 Utils.dedup(array)할 수 있으며 중복 제거 된 어레이를 호출 deduplicatedArray하거나 result.

• Java 디 컴파일러는 종종 로컬 변수 이름 지정에 이와 같은 체계를 사용합니다 (인스턴스 및 클래스 변수는 일반적으로 바이트 코드에서 사용할 수 있지만 로컬 변수는 사용할 수 없음). 결과는 예상보다 더 읽기 쉽고 실제로는 원본 소스.

• 의 참조 래리 벽의 원칙 "로컬 모호함은 OK입니다"- http://www.wall.org/~larry/natural.html .

개체를 만들 때마다 특정 용도를 염두에두고있을 것입니다. 유형만으로는 그 용도를 거의 반영하지 않습니다.

따라서 주소록 응용 프로그램에서 새 연락처를 만들려면 변수를 호출 할 수 있습니다 newContact.

Person이름이 설정되지 않은 객체 의 동작을 확인하기 위해 코드를 단위 테스트하는 경우 해당 객체 unnamedPerson또는 유사한 이름을 호출 할 수 있습니다 .

이를 호출하면 person코드를 자체 문서화 할 수있는 큰 기회가 없어집니다.

VB6에서 프로그래밍하는 경우에만. 이 경우 당신이하는 일은 불법이지만 부도덕 한 것은 아닙니다.

나도 그렇게하는데 왜 그것이 '부도덕'이어야하는지 이해하지 못합니다. 때때로 혼란 스러울 수도 있다는 것을 이해할 수 있지만, 오늘날 우리는 (실수를하고 클래스 대신 변수를 참조하고 그 반대의 경우도 마찬가지인 경우) 인텔리 센스 및 구문 강조 기능이있는 IDE가 있습니다. 매우 빠르게 오류를 확인하십시오. 그리고 컴파일러도 있습니다. :)

나는 또한이 관행에 어떤 문제도 보지 않는다. 해당 클래스의 변수가 하나만 있으면 작성 및 읽기가 쉽습니다. Imo, 기본 텍스트 편집기에도 적용됩니다. 나는 개인적으로 이것을 나쁘거나 심지어 부도덕하다고 말하는 사람을 기억할 수 없습니다. 그냥 계속하세요 :)

나는 당신이 생각할 수있는 '규칙'이 기본 유형과 클래스 이름이 잘못된 변수 이름을 만드는 클래스에 더 적합하다고 생각합니다.

예를 들어, 온라인 상점에서 특정 항목의 비용을 계산하는 경우 다음 코드는 좋은 형식이 아닙니다.

Decimal _decimal = item.BaseCost + item.Tax;

대신 '_total'또는 '_cost'와 같이보다 설명적인 이름이 권장됩니다.

내가 찾은 이런 종류의 유일한 문제는 개인 구성원과 공용 자산에 대해 동일한 이름을 원하는 경우입니다.

대소 문자 만 다를 경우 C #과 같은 대소 문자를 구분하는 언어에서는 제대로 작동하지만 VB.NET에서는 작동하지 않습니다.

예를 들어 VB에서는

Private _name As String

그러나

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

나는 C #에서 똑같이 할 것이므로 하나에서 다른 것으로의 번역이 고통스럽지 않습니다. 또한 잘못 읽거나 대소 문자 만 다른 단어를 잘못 입력하기 쉽기 때문에 오류가 발생하기 쉽습니다.

부도덕하지는 않지만 변수에 대한 가장 좋은 이름이 유형의 이름이라면 잘못된 것이거나 개념 증명 또는 이와 유사한 것을 만드는 것입니다. 나에게 변수 이름은 프로그래밍 언어가 아닌 비즈니스 컨텍스트의 의미를 참조해야합니다. 코드를 이해하는 것이 더 어려울 것입니다.

나는 자주 사용 Person person = new Person() 나를 합니다. 일반적으로 Java / C #에서 사용됩니다.

어제 궁금해졌지만 왜

private enum DataType {NEW, OLD}

C #에서 작동하지 않습니다 ...

특히 당신이 사용할 수있는 방법을보고 String, string, Double, double, ... C #에서 의지.

Person person = new Person()

내 책에서는 괜찮습니다.

끔찍하게되는 것은 다음과 같은 경우입니다.

string Person;
string person;

2를 섞는 것은 매우 쉽습니다.

나에게 표현 된 것은 코딩 표준을 충족하지 않는 것 외에 다른 사람이 내 코드를 읽을 때 혼동을 추가하는 것을 피하는 것입니다. 나는 개인적으로 의미가 분명하다면 아무런 문제가 없다고 생각합니다.

CLR 유형 (int, string 등)의 경우 String 또는 string (etc.)을 사용하여 유형을 선언 할 수 있으므로 다음과 같은 것을 사용하지 않을 것입니다.

int Int = 0;
string String = "hi there";

... 유일한 차이점은 위험 총액을 만드는 큰 프로젝트와 I를 위해이 일을 계속 보장 당신이 찾을 수없는 것 기괴한 오류로 실행하겠습니다.

위와 같은 fastPerson / slowPerson은 괜찮습니다 ... 그들은 설명적이고 변수 유형 이름과 구별됩니다 ...하지만 어서, int "Int"를 호출하는 것은 평범한 게으른 것입니다.

나는 결코 부도덕하지 않다고 말할 것입니다-그것은 실제로 당신의 기본 변수 이름입니다. 더 나은 이름을 생각할 수 없다면, 유형 뒤에 이름을 지정하는 것이 좋은 기본값입니다. (복잡한 유형의 경우에만 -내장 유형의 경우 악함 ) 그리고 많은 시간 동안 더 나은 이름은 없습니다. t 변수에 대해 다른 것을 알고 있습니다. 이 방법처럼

void SaveToDatabase(Person person) {...}

당신이 합리적으로 사람을 부를 수있는 유일한 것은 person_to_save중복 된 것 같은 것입니다.

그러나 많은 경우 사람을보다 설명적인 이름으로 대체하여 코드의 가독성을 향상시킬 수 있습니다. 예를 들어 이것은 덜 설명 적입니다.

void AddToAccount(Account account, Person person)  {...}

이것보다

void AddToAccount(Account account, Person dependent)  {...}

그러나 제발, 제발-예쁘게 유형 이름 앞에 'a'또는 't'를 넣지 마십시오. IE aPerson for 'a person'또는 tPerson for 'the person'. 지나치게 복잡하고 가치가 많지 않습니다. 또한 인텔리 센스의 값을 최소화 할 수있는 a 또는 t로 시작하는 여러 변수로 범위를 오염시키기 시작합니다.

나는 그것이 끔찍하다고 말하지 않을 것입니다. 일반적으로 변수 이름 앞에 'a'를 붙여서 유형의 단일 인스턴스라는 것을 보여줍니다.

Person aPerson = new Person();

그것은 내가 생각하기에 코드를 더 자연스럽게 읽도록 만듭니다.

다른 사람이 지적한주의 사항 (편의를 위해 여기에 요약)에 따라 전혀 문제가 없습니다. 기본 유형으로 수행하지 않고 나중에 다른 인스턴스가 추가 될 경우 원래 인스턴스를 리팩토링하고 클래스 이름을 구별하기 위해 문자 케이스를 사용하지 않는 등.

내 경험 법칙? 코드의 문장은 단순한 영어 문장처럼 읽어야합니다.

Person person = new Person ();

직원 직원 = person.getRole (EMPLOYEE);

부모 부모 = person.getRole (PARENT);

person.getFullName ();

employee.getSalary ();

parent.getChildren ();

parent.getFullName (); // 플레이시 데코레이터 패턴 가정

if (person.hasRole (EMPLOYEE)) {

  ...

}

기타 등등.

변수의 범위가 제한된 경우 (예를 들어 캡슐화 방법은 10-15 줄) 'person'대신 'p'를 사용할 수도 있습니다. 짧은 변수 이름은 머릿속에 맥락을 담으려고 할 때 산만 해지지 않습니다. 'a'또는 (shudder) 헝가리 표기법 및 그 파생물과 같은 불필요한 접두사를 피하십시오. (C ++ / COM / ATL / Win32 API 코드 등 적절한 컨텍스트에서 사용될 때 그러한 접두사에 대해 아무것도 가지고 있지 않습니다.

내 두 (!) 비트 :-)