케이싱만으로 형식 이름과 다른 매개 변수 이름을 사용하는 것이 C #에서 나쁜 습관으로 간주됩니까?

클래스의 속성과 일치하는 매개 변수 이름과 관련하여 이와 비슷한 질문이 있지만 C #의 케이싱을 제외하고 매개 변수 유형 이름과 동일한 매개 변수 이름을 사용하는 것과 관련하여 아무것도 찾을 수 없습니다. 내가 찾을 수있는 위반 인 것 같지는 않지만 나쁜 습관으로 간주됩니까? 예를 들어 다음과 같은 방법이 있습니다.

public Range PadRange(Range range) {}

이 메서드는 범위를 취하고 일부 패딩이 적용된 새 범위를 반환합니다. 따라서 일반적인 컨텍스트를 고려할 때 매개 변수에 대해 더 설명적인 이름을 생각할 수 없습니다. 그러나 "심리적 거리"에 대한 Code Complete를 읽을 때 선택한 팁을 생각 나게합니다. 그것은 말한다

심리적 거리는 두 항목을 쉽게 구별 할 수있는 것으로 정의 할 수 있습니다 ... 디버그 할 때 비슷한 변수 이름과 비슷한 루틴 이름 사이의 심리적 거리가 충분하지 않아 발생하는 문제에 대비하십시오. 코드를 작성할 때 문제를 피할 수 있도록 큰 차이가있는 이름을 선택하십시오.

내 메소드 서명에는 많은 "범위"가 진행 되므로이 심리적 거리와 관련하여 문제가 될 수 있습니다. 이제 많은 개발자가 다음을 수행하는 것을 봅니다.

public Range PadRange(Range myRange) {}

나는 개인적으로이 협약에 대한 강한 열망을 가지고 있습니다. 변수 이름에 "my"접두사를 추가하면 추가 컨텍스트가 제공되지 않습니다.

나는 또한 다음을 본다

public Range PadRange(Range rangeToPad) {}

나는 "my"접두사보다 이것을 좋아하지만 여전히 전체적으로 신경 쓰지 않습니다. 그것은 나에게 너무 장황하다고 느끼고 변수 이름으로 어색하게 읽습니다. 나에게, 메서드 이름으로 인해 범위가 채워질 것입니다.

이 모든 것이 준비되어 있으면, 내 직감은 첫 번째 서명과 함께하는 것입니다. 나에게는 깨끗하다. 필요하지 않을 때 컨텍스트를 강제 할 필요가 없습니다. 그러나 나 자신이나 미래 개발자 에게이 협약으로 장애를 겪고 있습니까? 모범 사례를 위반하고 있습니까?

이것을 지나치게 생각하지 마십시오 Range range. 나는 C #에서 15 년 이상 그런 종류의 이름을 사용하고 아마도 C ++에서는 훨씬 더 길며 그 반대의 실제 단점을 경험하지 못했습니다.

물론, 같은 범위에서 같은 지역에 다른 지역 변수가 있다면, 그것들을 올바르게 구별하기 위해 정신적 인 노력을 기울이는 것이 도움이 될 것입니다.

나는 항상 이것을한다, 그것은 나에게 큰 마음을주고있다. 멤버에게 할당해야하는 생성자에 전달 된 인수 인 경우 내 멤버의 이름도 range가되고 할당은 다음과 같습니다.

this.range = range;

그리고 일반적으로 Range라는 속성이 있습니다.

그것들은 모두 똑같고 상황이 다르기 때문에 단일 이름을 유지하는 것이 합리적이며 하나의 이름 만 기억해야합니다. 차이점은 순전히 기술적 인 것입니다.

"this"로 정규 멤버 자격을 갖추어야합니다. 그러나 이것이 StyleCop의 목적입니다.

StyleCop 사이드 노트

논쟁 보장!

"this"의 사용을 반대하는 사람들에게 : 나는 _, m, m_을 보았고 아무것도 보지 못했습니다. 언어 자체는 우리가 반원을 상대하고 있음을 나타내는 완벽하고 명확하고 명백한 보편적 인식 방법을 제공합니다. 왜 지구상에서 이미 완벽한 이름을 절단하는 자신 만의 방식을 만들고 싶습니까?

내가 생각할 수있는 유일한 이유는 다른 방법이 없었기 때문에 실제로 그렇게하는 것이 합리적 일 때 C 시대의 유산이라고 생각할 수 있습니다.

"더 많은 캐릭터입니다!" 진심이야? "컴파일 시간이 치 솟을 것입니다!" 진심이야? "입력 할 때 핑키를 들어야합니다!". 타이핑 시간이 전체 개발 시간에 의미가있는 것처럼.

나는 당신이 사용하는 것과 다른 스타일이 반대를 일으킬 것이라는 것을 알고 있습니다. 그러나 이것을 일관되게 사용하는 것은 논쟁하기 어렵습니다. 작동 방식은 다음과 같습니다. 새 코드 파일을 푸시하기 전에 StyleCop을 실행하면 "this"한정자가없는 많은 멤버를 찾을 수 있습니다. "이것"을 넣었습니다. 클립 보드에서 멤버가 실행하고 삽입합니다. 전혀 노력하지 않습니다.

StyleCop은 이보다 더 많은 기능을 수행합니다 (haha). 개발자가 코드 형식 만 고려하여 후속 작업의 유지 관리 작업을 좌절시킬 수있는 방법이 너무 많습니다. StyleCop은 대부분을 방지합니다. 귀중합니다.

당신이 그것에 익숙하지 않은 경우 : 그것은 일반적으로 당신이 일주일에 대한 불평을하고 다음 당신은 그것을 사랑합니다.

명명 방법, 매개 변수 및 변수에 대한 내 자체 지침은 매우 간단합니다.

1. 이름에 전달되거나 반환되는 유형이 포함 된 경우 잘못된 유형입니다.
2. 의도 한 것이 아니라 의도 한대로 이름을 지정하십시오.
3. 코드는 작성된 것보다 더 많이 읽습니다.

따라서 내 의견으로는 최적의 메소드 서명은 다음과 같습니다.

Range Pad(Range toPad)

메소드 명을 단축하는 것은 설명이 필요 없습니다.

매개 변수 이름은 toPad즉시 해당 매개 변수가 채워 져서 제자리에서 수정되고 리턴 될 것임을 독자에게 알려줍니다. 반대로이라는 변수에 대해서는 가정 할 수 없습니다 range.

또한, 방법의 실제 본문에, 다른 Range당신이 가질 수 있도록 도입되는 변수는, 자신의 의도에 의해 명명 할 (해야) 것 padded하고 unpadded... toPad그 이름 지정 규칙을 따르는,하지만 range그냥 스틱과 젤하지 않습니다.

코드 요소 (유형, 변수, 함수 등)의 이름을 지정하려면 스스로에게 물어봐야 할 주요 질문

오타를 만들면 컴파일러에서 찾을 수 있습니까?

최악의 오타 기반 버그는 코드가 컴파일되고 실행되지만 미묘한 이유로 인해 예상 한 것과 다른 동작을 제공하는 버그입니다. 그리고 오타로 인해 코드를 검사 할 때 확인하기가 일반적으로 어렵습니다. 오타가 코드 컴파일을 중지하면 컴파일러가 문제를 일으키는 행을 플래그 지정하여 쉽게 찾아서 수정할 수 있습니다.

유형과 변수가 대문자로만 다른 상황에서는 항상 그렇습니다. (또는 거의 항상-충분한 노력을 기울이면 효과를 발휘할 수 있지만 실제로 시도해야 할 것입니다.)

당신이 걱정 될 필요가 어디있을라고 현재 범위에서 두 개의 변수, 방식, 기능 또는 특성이 있다면 것 range하고 Range. 이 경우 컴파일러 가 이를 통과시켜 런타임에 예기치 않은 동작이 발생합니다. 이것은 "두 개의 변수"또는 "두 개의 함수"뿐만 아니라 이러한 코드 요소 유형 중 두 가지입니다.이 두 요소는 모두 암시 적으로 서로 캐스트 될 수 있으며, 실행될 때 캐리지가 발생합니다. 경고가 표시 될 수 있지만 그 이상을 보장 할 수는 없습니다. range및 이라고 선언 된 두 가지 유형이있는 경우 비슷한 문제가 있습니다 Range.

또한 헝가리 표기법 스타일 에도 동일하게 적용되는데, 이름에 하나 이상의 문자가 접두사로 붙어있어 그 이름에 대해 더 많은 것을 말할 수 있습니다. 예를 들어 이라는 변수 Range와이라는 포인터가 있으면 PRange실수로을 놓치기 쉽습니다 P. C #은 이것을 잡아야하지만 C와 C ++은 최대 경고만을 줄 것입니다. 또는 더 걱정스럽게도 이중 버전 DRange이 있고 부동 소수점 버전으로 다운 샘플링 한다고 가정하십시오 FRange. 실수로 실수로 플로트를 사용하십시오 (키가 키보드에 인접하기 때문에 쉬움). 코드는 일종의 작업이지만 프로세스가 해상도와 언더 플로가 부족하면 이상하고 예측할 수없는 방식으로 넘어갑니다.

우리는 더 이상 8 글자, 16 글자 또는 임의의 한계로 명명 제한이 없었던 시대에 있지 않습니다. 때로는 변수 이름이 길어 코딩 시간이 오래 걸리는 초보자들도 있습니다. 그러나 이것에 대해 불평하는 것은 초보자입니다. 진지한 코더들은 실제로 시간이 걸리는 것은 모호한 버그를 알아내는 것임을 알고 있습니다. 이름을 잘못 선택하는 것은 그 특정 구멍에 빠지는 전형적인 방법입니다.

한 가지 일화를 추가하고 싶습니다. Range range이것은 문법적으로 합법적이지만 디버깅이나 리팩터링하기가 더 어려울 수 있습니다. Range 유형의 변수가 많은 파일에서 "range"라는 하나의 변수를 찾으십니까? 이 명명 선택의 결과로 나중에 더 많은 작업을 수행 할 수 있습니다.

이것은 주로 상황에 따라 다릅니다. 30 줄짜리 파일이라면 내 진술은 실제로 적용되지 않습니다.

나는 Range range구문 강조라는 한 가지 이유로 오늘날 사용할 수 있다고 생각합니다 . 최신 IDE는 일반적으로 유형 이름과 매개 변수 이름을 다른 색상으로 강조 표시합니다 . 또한 유형과 변수에는 쉽게 혼동되지 않는 상당한 "논리적 거리"가 있습니다.

그렇지 않은 경우 다른 이름을 고려 하거나이 구문 강조를 수행 할 수있는 플러그인 / 확장을 활성화하려고합니다.

함수가 제네릭이면 매개 변수가 제네릭이므로 제네릭 이름을 가져야하는 이유가 있습니다.

당신이 말하는 것은 아니지만, 오해의 소지가있는 매개 변수 이름을 가진 일반 함수를 수행하는 함수를 보았습니다. 처럼

public String removeNonDigits(String phoneNumber)

함수 이름은 매우 일반적인 것처럼 들리는데, 이는 여러 상황에서 많은 문자열에 적용될 수 있습니다. 그러나 매개 변수 이름은 이상하게 지정되어 함수 이름이 잘못되었는지 궁금해합니까?

따라서 Range range 대신 Range rangeToPad라고 말할 수 있습니다. 그러나 이것은 어떤 정보를 추가합니까? 물론 패드 범위입니다. 다른 무엇입니까?

임의의 접두사 "my"또는 "m_"등을 추가하면 추가 정보가 전혀 없어지지 않습니다. 컴파일러가 변수 이름을 대소 문자 구분 여부와 상관없이 유형 이름과 동일하게 허용하지 않는 언어를 사용했을 때 컴파일하기 위해 접두사 또는 접미사를 사용하는 경우가 있습니다. . 그러나 그것은 단지 컴파일러를 만족시키는 것입니다. 컴파일러가 구별 할 수 있더라도 인간 독자가 쉽게 구별 할 수 있다고 주장 할 수 있습니다. 그러나 와우, Java에서는 "Customer customer = new Customer ();"와 같은 문장을 작성했습니다. 10 억 번이나 나는 그것을 혼동하지 않았다. (나는 항상 약간 중복되는 것을 발견했으며 VB에서는 "새 고객으로 희미한 고객"이라고 말할 수 있으며 클래스 이름을 두 번 지정할 필요가 없습니다.

일반 이름에 강력하게 반대하는 곳은 동일한 함수에 동일한 유형의 인스턴스가 두 개 이상있는 경우입니다. 특히 매개 변수. 처럼:

public Range pad(Range range1, Range range2)

range1과 range2의 차이점은 무엇입니까? 어떻게 알 수 있습니까? 그것이 실제로 두 개의 일반적이고 상호 교환 가능한 값인 경우라면

public boolean overlap(Range range1, Range range2)

범위가 겹치면 true를 반환하고 그렇지 않으면 false를 반환하므로 일반적이고 상호 교환 가능합니다.

그러나 그들이 다르다면, 그들이 어떻게 다른지 실마리를주세요! 최근에 지리적 장소에 대한 데이터를 보유 할 수있는 "Place"클래스를 가진 프로그램을 작업하고 있었고 "p", "place", "place2", "myPlace"등과 같은 유형의 변수를 사용했습니다. 와우, 그 이름은 실제로 어느 것을 결정하는 데 도움이됩니다.