Java 변수 및 메소드 이름에 밑줄 사용

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;
}

Others will use underscores to indicate a temp local variable that will go out of scope at the end of the method call. (I find this pretty useless - a good method shouldn't be that long, and the declaration is RIGHT THERE! so I know it goes out of scope) Edit: God forbid a programmer from this school and a programmer from the memberData school collaborate! It would be hell.

Sometimes, generated code will preface variables with _ or __. The idea being that no human would ever do this, so it's safe.

---

I think any style that breaks a language's own style guidelines (without due reason) is ugly and therefore "bad".

No doubt the code you've seen was written by someone who used to work on a language where underscores were acceptable.

Some people just cannot adapt to new coding styles...

---

The reason people do it (in my experience) is to differentiate between member variables and function parameters. In Java you can have a class like this:

public class TestClass {
  int var1;

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

If you made the member variable _var1 or m_var1, you wouldn't have the ambiguity in the function.

So it's a style, and I wouldn't call it bad.

---

Personally, I think a language shouldn't make rules about coding style. It is a matter of preferences, usage, convenience, concept about readability.
Now, a project must set coding rules, for consistency across listings. You might not agree with these rules, but you should stick to them if you want to contribute (or work in a team).

At least, IDEs like Eclispe are agnostic, allowing to set rules like variable prefixes or suffixes, various styles of brace placement and space management, etc. So you can use it to reformat code along your guidelines.

Note: I am among those keeping their old habits from C/C++, coding Java with m_ prefixes for member variables (and s_ for static ones), prefixing booleans with an initial b, using an initial uppercase letter for function names and aligning braces... The horror for Java fundamentalists! ;-)
Funnily, that's the conventions used where I work... probably because the main initial developer comes from MFC world! :-D

---

it's just your own style,nothing a bad style code,and nothing a good style code,just difference our code with the others.

참고URL : https://stackoverflow.com/questions/150192/using-underscores-in-java-variables-and-method-names