Java 코딩 표준/모범 사례 - 중단/계속 레이블에 대한 명명 규칙
-
08-06-2019 - |
문제
때로는 레이블이 지정된 break 또는 continue를 사용하여 코드를 훨씬 더 읽기 쉽게 만들 수 있습니다.
OUTERLOOP: for ( ;/*stuff*/; ) {
//...lots of code
if ( isEnough() ) break OUTERLOOP;
//...more code
}
라벨에 대한 일반적인 규칙이 무엇인지 궁금합니다.모두 대문자인가요?첫 모자?
해결책
대문자를 사용해야 하는 경우 주의를 끌고 "클래스" 이름으로 잘못 해석되는 것을 방지합니다.주의를 끌면 코드를 리팩토링하고 제거하는 누군가의 시선을 사로잡을 수 있다는 추가적인 이점이 있습니다.;)
다른 팁
"라벨을 사용하지 마세요"라는 규칙이 어디서 나온 것인지 이해가 되지 않습니다.중요하지 않은 루핑 논리를 수행할 때 중단 또는 계속 테스트가 항상 주변 블록의 끝에서 깔끔하게 수행되는 것은 아닙니다.
outer_loop:
for (...) {
// some code
for (...) {
// some code
if (...)
continue outer_loop;
// more code
}
// more code
}
네, 이런 경우는 항상 발생합니다.사람들은 내가 대신 무엇을 사용하라고 제안하고 있나요?이와 같은 부울 조건이 있나요?
for (...) {
// some code
boolean continueOuterLoop = false;
for (...) {
// some code
if (...) {
continueOuterLoop = true;
break;
}
// more code
}
if (continueOuterLoop)
continue;
// more code
}
왝! 이를 메소드로 리팩터링해도 다음 중 하나가 완화되지 않습니다.
boolean innerLoop (...) {
for (...) {
// some code
if (...) {
return true;
}
// more code
}
return false;
}
for (...) {
// some code
if (innerLoop(...))
continue;
// more code
}
물론 조금 더 예쁘지만 여전히 불필요한 부울을 전달하고 있습니다.그리고 내부 루프가 지역 변수를 수정한 경우 이를 메서드로 리팩토링하는 것이 항상 올바른 솔루션은 아닙니다.
그렇다면 왜 다들 라벨에 반대하는 걸까요?위 사례에 대한 몇 가지 확실한 이유와 실용적인 대안을 알려주세요.
관례는 라벨을 완전히 피하는 것입니다.
루프를 벗어나기 위해 레이블을 사용하는 타당한 이유는 거의 없습니다.브레이크아웃은 괜찮지만 디자인을 약간 수정하면 브레이크아웃의 필요성을 전혀 없앨 수 있습니다.제공한 예에서는 '많은 코드' 섹션을 추출하여 의미 있는 이름을 가진 개별 메서드에 넣습니다.
for ( ;/*stuff*/; )
{
lotsOfCode();
if ( !isEnough() )
{
moreCode();
}
}
편집하다: 문제의 실제 코드를 본 후(여기), 나는 레이블을 사용하는 것이 아마도 코드를 읽기 쉽게 만드는 가장 좋은 방법이라고 생각합니다.대부분의 경우 라벨을 사용하는 것은 잘못된 접근 방식입니다. 이 경우에는 괜찮다고 생각합니다.
Sun의 Java 코드 스타일은 변수와 동일한 방식으로 이름 지정 레이블을 선호하는 것 같습니다. 즉, 첫 글자가 소문자인 낙타 표기법을 의미합니다.
내가 가장 많이 본 규칙은 메소드 이름과 같은 단순한 카멜 표기법입니다.
myLabel:
하지만 밑줄이 앞에 붙은 라벨도 본 적이 있어요
_myLabel:
아니면 실험실에서...
labSomething:
다른 답변에서 '레이블을 사용하지 마세요' 이외의 다른 코딩 표준을 찾기가 어렵다는 것을 느낄 수 있습니다.그렇다면 내 생각에 대답은 일관성이 있는 한 자신에게 적합한 스타일을 사용해야 한다는 것입니다.
wrt 새디의 코드 예제:
당신은 주었어요
outerloop:
for (...) {
// some code
for (...) {
// some code
if (...)
continue outerloop;
// more code
}
// more code
}
예로서.좋은 지적이군요.내 추측은 다음과 같다:
public void lookMumNoLabels() {
for (...) {
// some code
doMoreInnerCodeLogic(...);
}
}
private void doMoreInnerCodeLogic(...) {
for (...) {
// some code
if (...) return;
}
}
그러나 이러한 종류의 리팩토링이 수행 중인 논리에 관계없이 올바르게 적용되지 않는 예가 있습니다.
레이블은 거의 유용하지 않기 때문에 명확한 규칙이 없는 것 같습니다.Java 언어 사양에는 레이블이 있는 예제가 하나 있으며 non_cap에 있습니다.
하지만 매우 드물기 때문에 제 생각에는 이것이 정말 올바른 도구인지 다시 생각해 보는 것이 가장 좋습니다.
그리고 그것이 올바른 도구라면 다른 개발자(또는 나중에 자신)가 즉시 특이한 것으로 인식할 수 있도록 모두 대문자로 만드십시오.(Craig가 이미 지적했듯이)
대합/모범 사례는 여전히 이를 전혀 사용하지 않고 추출 방법을 사용하여 더 읽기 쉽도록 코드를 리팩터링하는 것입니다.
그것은 일종의 Java의 goto입니다. C#에 그런 기능이 있는지는 확실하지 않습니다.나는 실제로 그것들을 사용한 적이 없으며, 그것들을 피하는 것이 훨씬 더 읽기 쉬운 코드를 만들지 않는 경우를 생각할 수 없습니다.
하지만 꼭 해야 한다면- 모두 대문자로 써도 괜찮을 것 같아요.대부분의 사람들은 레이블이 붙은 구분 기호를 사용하지 않으므로 코드를 보면 대문자가 튀어 나와 무슨 일이 일어나고 있는지 깨닫게 될 것입니다.
알아요. 라벨을 사용하면 안 돼요.
하지만 레이블이 지정된 구분선에서 가독성을 높일 수 있는 일부 코드가 있다고 가정해 보겠습니다. 형식을 지정하는 방법은 무엇입니까?
모, 전제가 틀렸어.문제는 '어떻게 포맷하나요?'가 되어서는 안 됩니다.
귀하의 질문은 '루프 내부에 많은 양의 논리가 있는 코드가 있습니다. 어떻게 하면 더 읽기 쉽게 만들 수 있습니까?'입니다.
해당 질문에 대한 답은 코드를 이름이 잘 지정된 개별 함수로 옮기는 것입니다.그러면 휴식 시간에 라벨을 붙일 필요가 전혀 없습니다.