Java 변수 및 메소드 이름에 밑줄 사용 [닫힘]

요즘에도 Java 변수와 메소드에서 밑줄을 자주 볼 수 있습니다. 예는 멤버 변수 (예 : "m_count"또는 "_count")입니다. 제가 기억하는 한, 이러한 경우 밑줄을 사용하는 것은 Sun에서 나쁜 스타일이라고합니다.

사용되어야하는 유일한 위치는 상수 ( "public final static int IS_OKAY = 1;"에서와 같이)입니다. 상수는 낙타 대문자가 아닌 모두 대문자 여야하기 때문입니다. 여기서 밑줄은 코드를 더 읽기 쉽게 만들어야합니다.

Java에서 밑줄을 사용하는 것이 나쁜 스타일이라고 생각하십니까? 만약 그렇다면, 그 이유는 무엇입니까?

지금 사용하는 코드가 없다면 계속하는 것이 좋습니다. 코드베이스에서 사용하는 경우 계속하십시오.

코딩 스타일의 가장 큰 장점은 일관성 입니다. 일관성이없는 경우 언어 공급 업체의 권장 사항을 시작하는 것이 좋습니다.

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs ();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable ();

규칙 :

1. 편집중인 코드가 수행하는 작업을 수행하십시오.
2. # 1이 적용되지 않으면 밑줄없이 camelCase를 사용하십시오.

멤버 변수가 Java 또는 다른 언어에서 나쁘다는 것을 나타 내기 위해 _ 또는 m_을 사용한다고 생각하지 않습니다. 제 생각에는 스 니펫을보고 지역에서 모든 멤버 변수를 신속하게 식별 할 수 있기 때문에 코드의 가독성이 향상됩니다.

사용자가 인스턴스 변수 앞에 "this"를 추가하도록하여이 작업을 수행 할 수도 있습니다. 인스턴스 변수이기 때문에 여러면에서 DRY를 위반합니다.

제 개인적인 스타일은 _ 대신 m_을 사용하는 것입니다. 그 이유는 전역 변수와 정적 변수도 있기 때문입니다. m _ / _의 장점은 변수 범위를 구별한다는 것입니다. 따라서 전역 또는 정적에 _를 재사용 할 수 없으며 대신 g_와 s_를 각각 선택합니다.

"나쁜 스타일"은 매우 주관적입니다. 특정 규칙이 당신과 당신의 팀에게 효과가 있다면, 그것은 나쁘고 좋은 스타일을 인정할 것이라고 생각합니다.

귀하의 질문에 대답하기 위해 : 나는 개인 변수를 표시하기 위해 선행 밑줄을 사용합니다. 분명하고 코드를 빠르게 스캔하여 무슨 일이 일어나고 있는지 알아낼 수 있습니다.

(하지만 이름 충돌을 방지하기 위해 "this"를 거의 사용하지 않습니다.)

변수 앞에 'm_'또는 '_'를 사용하면 개체 전체의 메서드에서 멤버 변수를 쉽게 찾을 수 있습니다.

부수적으로 'm_'또는 '_'를 입력하면 intellsense가 먼저 팝업됩니다.)

• 나는 (개인) 인스턴스 변수에 대한 밑줄을 좋아하는데, 읽고 구별하기가 더 쉬운 것 같습니다. 그들은 당신의 명명 규칙을 어 기고 있습니다.
• private int _my_int; public int myInt;? _my_int? )

-내가 _style을 좋아하고 읽을 수 있다고 생각하는 한, 흔하지 않고 사용중인 코드베이스의 다른 것과 일치하지 않을 가능성이 높기 때문에 가치가있는 것보다 더 많은 문제가 있음을 알 수 있습니다.

-자동화 ​​된 코드 생성 (예 : 이클립스의 게터 생성, 세터)은 이것을 이해하기 어렵 기 때문에 손으로 고치거나 이클립스를 사용하여 인식 할 수있을만큼 뭉쳐야합니다.

궁극적으로, 당신은 나머지 (자바) 세계의 환경 설정에 반대하며 그로 인해 약간의 성가심을 가질 것입니다. 그리고 이전 포스터에서 언급했듯이 코드베이스의 일관성이 위의 모든 문제를 능가합니다.

예전에는 밑줄을 사용하는 것이 나쁜 스타일로 여겨지는 이유가 있습니다. 런타임 컴파일러가 감당할 수없는 무언가가 있었다 모니터는 놀라운 320 × 240 픽셀의 해상도와 함께 제공되는 경우가 종종 쉽게 구별하는 것이었다 _name하고 __name.

private 변수와 public 변수를 구별 할 수있는 것이 있으면 좋지만 일반적인 코딩에서는 '_'를 좋아하지 않습니다. 새 코드로 도울 수 있다면 사용을 피합니다.

다음 은 Java에 대한 Sun의 권장 사항에 대한 링크 입니다. 이것을 사용해야하거나 라이브러리 코드가 모두를 따라 간다는 것은 아니지만 처음부터 시작하는 것이 좋습니다. Eclipse와 같은 도구에는 이러한 규칙 (또는 사용자가 정의한 다른 규칙)을 준수하는 데 도움이되는 포맷터 및 정리 도구가 내장되어 있습니다.

저에게 '_'는 입력하기가 너무 어렵습니다. :)

코딩 스타일의 혼합입니다. 한 가지 생각은 개인 회원을 구별하기 위해 밑줄로 시작하는 것입니다.

setBar( int bar)
{
   _bar = bar;
}

대신에

setBar( int bar)
{
   this.bar = bar;
}

다른 사람들은 밑줄을 사용하여 메서드 호출이 끝날 때 범위를 벗어날 임시 지역 변수를 나타냅니다. (나는 이것이 꽤 쓸모가 없다고 생각합니다-좋은 방법은 그렇게 길지 않아야하고 선언은 옳습니다! 그래서 나는 그것이 범위를 벗어난다는 것을 압니다) 편집 : 하나님은이 학교의 프로그래머와 memberData 학교의 프로그래머를 금지합니다. ! 지옥이 될 것입니다.

경우에 따라 생성 된 코드는 변수 앞에 _ 또는 __를 붙입니다. 인간이 절대로 이런 일을하지 않을 것이라는 생각은 안전합니다.

나는 언어 고유의 스타일 가이드 라인을 위반하는 모든 스타일 (적당한 이유없이)은 추악하기 때문에 "나쁘다"고 생각합니다.

여러분이 본 코드는 밑줄이 허용되는 언어로 작업했던 사람이 작성한 것입니다.

어떤 사람들은 새로운 코딩 스타일에 적응할 수 없습니다 ...

사람들이 (내 경험상) 그렇게하는 이유는 멤버 변수와 함수 매개 변수를 구별하기 위해서입니다. Java에서는 다음과 같은 클래스를 가질 수 있습니다.

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

멤버 변수 _var1 또는 m_var1을 만들면 함수에 모호성이 없습니다.

그래서 그건 스타일, 나는 나쁜 호출하지 않을 것입니다.

개인적으로 언어가 코딩 스타일에 대한 규칙을 만들어서는 안된다고 생각합니다 . 가독성에 대한 선호도, 사용법, 편의성, 개념의 문제입니다.
이제 프로젝트 는 목록 간의 일관성을 위해 코딩 규칙을 설정 해야합니다 . 이러한 규칙에 동의하지 않을 수 있지만 기여 (또는 팀에서 작업)하려면 규칙을 준수해야합니다.

적어도, Eclispe 등의 IDE는 무관하다 당신이 함께 다시 포맷 코드에 사용할 수 있도록 변수 접두사 나 접미사, 중괄호 배치 및 공간 관리 등의 다양한 스타일과 같은 일련의 규칙을 수 있도록 당신의 가이드 라인.

참고 : 저는 C / C ++에서 이전 습관을 유지하고 멤버 변수에 대해 m_ 접두사 (및 정적 변수에 대해 s_)로 Java를 코딩하고, 함수 이름에 초기 대문자를 사용하고 중괄호를 정렬하는 부울 앞에 이니셜 b를 붙입니다. .. 자바 근본 주의자들의 공포! ;-)
재미있게도, 그것이 제가 일하는 곳에서 사용되는 관습입니다 ... 아마도 주요 초기 개발자가 MFC 세계에서 왔기 때문일 것입니다! :-디

그것은 단지 당신 만의 스타일이고, 나쁜 스타일의 코드는 아니며, 좋은 스타일의 코드도 아닙니다. 단지 우리의 코드와 다른 코드의 차이 일뿐입니다.