요즘에도 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이 적용되지 않으면 밑줄없이 camelCase를 사용하십시오.
답변
멤버 변수가 Java 또는 다른 언어에서 나쁘다는 것을 나타 내기 위해 _ 또는 m_을 사용한다고 생각하지 않습니다. 제 생각에는 스 니펫을보고 지역에서 모든 멤버 변수를 신속하게 식별 할 수 있기 때문에 코드의 가독성이 향상됩니다.
사용자가 인스턴스 변수 앞에 “this”를 추가하도록하여이 작업을 수행 할 수도 있습니다. 인스턴스 변수이기 때문에 여러면에서 DRY를 위반합니다.
제 개인적인 스타일은 _ 대신 m_을 사용하는 것입니다. 그 이유는 전역 변수와 정적 변수도 있기 때문입니다. m _ / _의 장점은 변수 범위를 구별한다는 것입니다. 따라서 전역 또는 정적에 _를 재사용 할 수 없으며 대신 g_와 s_를 각각 선택합니다.
답변
“나쁜 스타일”은 매우 주관적입니다. 특정 규칙이 당신과 당신의 팀에게 효과가 있다면, 그것은 나쁘고 좋은 스타일을 인정할 것이라고 생각합니다.
귀하의 질문에 대답하기 위해 : 나는 개인 변수를 표시하기 위해 선행 밑줄을 사용합니다. 분명하고 코드를 빠르게 스캔하여 무슨 일이 일어나고 있는지 알아낼 수 있습니다.
(하지만 이름 충돌을 방지하기 위해 “this”를 거의 사용하지 않습니다.)
답변
변수 앞에 ‘m_’또는 ‘_’를 사용하면 개체 전체의 메서드에서 멤버 변수를 쉽게 찾을 수 있습니다.
부수적으로 ‘m_’또는 ‘_’를 입력하면 intellsense가 먼저 팝업됩니다.)
답변
- 나는 (개인) 인스턴스 변수에 대한 밑줄을 좋아하는데, 읽고 구별하기가 더 쉬운 것 같습니다. 그들은 당신의 명명 규칙을 어 기고 있습니다.
private int _my_int;
public int myInt;? _my_int? )
-내가 _style을 좋아하고 읽을 수 있다고 생각하는 한, 흔하지 않고 사용중인 코드베이스의 다른 것과 일치하지 않을 가능성이 높기 때문에 가치가있는 것보다 더 많은 문제가 있음을 알 수 있습니다.
-자동화 된 코드 생성 (예 : 이클립스의 게터 생성, 세터)은 이것을 이해하기 어렵 기 때문에 손으로 고치거나 이클립스를 사용하여 인식 할 수있을만큼 뭉쳐야합니다.
궁극적으로, 당신은 나머지 (자바) 세계의 환경 설정에 반대하며 그로 인해 약간의 성가심을 가질 것입니다. 그리고 이전 포스터에서 언급했듯이 코드베이스의 일관성이 위의 모든 문제를 능가합니다.
