2009-05-07 4 views
6

모두 "밑줄, 밑줄 없음"논쟁은 순전히 철학적이며 사용자 기본 설정이지만 intelli-sense는 밑줄을 사용하면 멤버 변수를 지역 변수와 매우 쉽게 차별화 할 수 있으므로 구체적인 이점을 얻을 수 있습니다.멤버 변수의 밑줄 접두사. intellisense

에는 모든 멤버 변수에 밑줄을 사용하는 이점에 대한 반론이 있습니까?

답변

21

예 - 일부 사용자에게는 가독성이 떨어집니다. 나는 다른 사람들이 여러 가지 방법으로 읽는다고 믿습니다. (예를 들면, 내부적으로 보컬이나 다른 것들은 그렇지 않습니다.) 어떤 사람들은 (자신을 포함해서) 코드를 읽었을 때 코드의 "흐름"을 방해한다고 강조합니다.

나는 지역 변수와 인스턴스 변수를 구분하는데 어려움이 있다면, 당신의 방법이 너무 크거나 수업이 너무 많이하고 있다고 주장 할 것이다. 물론 항상 그런 것은 아니지만 짧은 수업/방법으로 전혀 문제가되지 않는 경향이 있습니다.

+1

나는 접두사 밑줄이이 대답에 좋은 생각이라고 생각하는 사람을 추천 할 것입니다. –

+3

글쎄, 나는 항상 밑줄을 사용 해왔다. 나를 위해. 1) 더 많은 타이핑 2) 실수로 우회하기 쉬운 3) 밑줄은 내 관점에서 읽기 쉽습니다. vb "then" "if if 4"와 비슷하고 방법이 작거나 크지 않아도 로컬 및 클래스 바를 명확히 구분하는 것이 항상 유익합니다. – Jack0fshad0ws

+0

@ Jack0fshad0ws : 물론 맛의 문제입니다. 개인적으로 그것은 나를 위해 너무 많은 흐름 - 구두점을 추가합니다. 나는 어디에서나 'this.'를 추가 할 것을 제안하지 않았다. - 나는 단지 구문이나 접두어로 구별하지 않는다. 로컬 변수와 인스턴스 변수가 약간 혼동 스러울 때가 마지막으로 기억납니다. 메소드를 짧게 유지하고 이름을 선택하면 논리 객체 상태의 일시적인 정보를 처리하는지 여부가 명확합니다. –

7

밑줄을 사용하면 그 효과를 얻는 한 가지 방법 일뿐입니다. 중요한 점은 일관성을 유지하는 것입니다.

+0

심지어 Microsoft는 .NET Framework에서 일관성이 없습니다 ...;) – Siewers

13

인텔리 센스라면 언제든지 "this."을 입력하면됩니다.

좋아, "_"보다 4 개의 문자가 더 많지만 intellisense가 멤버를 불러옵니다.

밑줄을 사용하고 팀에서 밑줄을 사용하는 경우 계속 사용하십시오. 다른 사용자는 "m _"을 사용하고 다른 사용자는 다른 아이디어를 가질 수 있습니다. StyleCop을 사용하고 팀에서 토론이 끝나면 "this"을 사용합니다. 헝가리어 스타일 또는 밑줄 접두사는 사용되지 않습니다. 그리고 우리는 더 이상 걱정하지 않아도됩니다.

[편집] 이것은 질문의 비판이 아닙니다. 올바른 질문이므로 물어 볼 가치가 있습니다. 그러나이 토론은 개발자 프로젝트에 너무 많은 시간을 낭비합니다. 비록 StyleCop에 대한 모든 것을 좋아하지는 않지만, 나는 이런 유형의 토론을 없애 기꺼이 사용합니다. 진지하게, 나는 이런 종류의 토론이 전체 dev 팀을 차지하는 긴 시간의 회의에있었습니다. 미친. 내가 말했듯이, 당신의 질문은 유효하지만 자신의 시간을 낭비하지 마십시오. 가치가 없습니다 :-)

+0

+1 동의합니다 - 토론을 바로 가기로 설정할 수 있다면 그렇게하십시오. – ChrisF

+0

플러스 나는'this.'가 가독성을 향상 시킨다고 생각합니다. 구문 강조를 사용하면 개인 변수를 한 눈에 쉽게 파악할 수 있습니다. – Cocowalla

3

당신이 그것을 사용하는 한 당신이 선택하는 명명 규칙은 정말로 중요하지 않습니다. 전체 프로젝트.

+9

나는 그것이 중요하다고 믿습니다. 모든 종류의 모든 구성원이 프로젝트 이름으로 시작하는 명명 규칙을 사용하면 예를 들어 막대한 양의 코드와 코드가 나오기 쉽지 않습니다. 일관성은 확실히 중요합니다. 조금만 중요한 것은 아닙니다. –

5

밑줄은 헝가리어 표기 *의 형태로 볼 수 있지만 접두사는 의미가있는 것 대신 "마법의 문자"입니다.

접두어가 무엇인지 더 자세히 알려면 member 또는 mbr 또는 m과 같은 접두사를 사용하십시오. 때로는 접두어 m_이 사용되지만 밑줄은 접두어의 일부가 아닌 구분 기호로 사용되며 .NET에 대한 이름 지정 권장 사항에서는 구분 기호로 사용해서는 안됩니다.

개인적으로 나는 멤버 변수의 밑줄을 좋아하지만, 접두사에 숨겨진 의미가 있습니다. 다른 접두사만큼 이름을 어지럽히 지 않습니다.

언제나 그렇듯이 실제로 선택한 표준보다 표준을 고수하는 것이 더 중요합니다.


* 헝가리어 notaition는 대부분 데이터가 VBScript를 같은 약하게 입력 된 언어를 입력 지정하는 데 사용할 수왔다,하지만 원래 의도는 그래서 멤버 변수를한다하여, 변수의 다른 속성을 지정하는 것이 었습니다 원래 함께 더 의도.

2

사용 중입니다. 어디에서나 제 의견으로는 가독성이 떨어집니다. 프라이빗 클래스 필드의 언더 스코어 접두어는 완벽하게 받아 들일 수 있습니다. 정말 엉뚱한 명명 규칙 인 intelisense 프론트 타이핑 _ 글자를 포함한 거의 헝가리어는 귀하의 목록을 가져 오는 매우 빠른 방법입니다. CSLA.NET을 사용하고 많은 BO 예제에서 밑줄 규칙을 사용하며 모든 작업에서이 예제를 계속 사용합니다. 예전의 예전의 C++과 C 개발자가 당신을 놀라게하는 것을 두려워하지 마십시오. .NET은 똑같은 문제를 겪지 않습니다. 제 생각에는

public MyObject(int field1, int field2, int field3) 
{ 
    _field1 = field1; 
    _field2 = field2; 
    _field3 = field3; 
} 

이 더 많은 읽을 수

public MyObject(int field1, int field2, int field3) 
{ 
    this.field1 = field1; 
    this.field2 = field2; 
    this.field3 = field3; 
} 

보다하지만 개인적인 취향과 다른 곳에서 말한 것처럼 일관성이 가장 중요한 문제입니다 : 좋은 예는 생성자에 인수를 전달합니다.