주석 대체로 추가 로컬 변수 소개

기술적으로 불필요한 추가 로컬 변수를 사용하여 발생하는 상황을 설명하는 것이 좋은 스타일입니까?

예를 들면 다음과 같습니다.

bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);

if(easyUnderstandableIsTrue)
{
    // ...
}

기술 오버 헤드에 관해서는 컴파일러 가이 추가 라인을 최적화 할 것으로 기대합니다. 그러나 불필요한 코드 팽창으로 간주됩니까? 내 눈에 그것은 오래된 주석의 위험을 줄입니다.

추가 변수를 사용하는 비용은 얼마입니까? 대부분의 언어에서는 컴파일 된 언어와 해석 된 언어 모두가 없습니다.

이것의 장점은 무엇입니까?

• cryptic boolean expression을 별도의 메소드로 추출하는 것과 마찬가지로 중복 코드의 위험을 줄이지 만 별도의 메소드의 경우보다 약간 적습니다. 조건식이 메소드 자체에서 재사용되면 변수를 재사용 할 수 있습니다. 식이 다른 방법으로 표시되면 그렇지 않습니다.

  프로그래밍 언어로 변경할 수없는 지역 변수를 가지거나 스타일을 강제로 적용 할 수있는 방법이 없다면 어떠한 변수도 재 할당 할 수 없으며, 이러한 리팩토링은 장기적으로 위험 할 수 있습니다. 변수 값이 변경되면 코드를 추론하기가 매우 어려울 수 있습니다.

• 당신은되는 문서는 코드와 동기화지고의 위험을 감소 . 개발자는 주석보다 변수 및 메소드의 이름을 더 쉽게 업데이트하는 경향이 있습니다 .¹ 따라서 다음과 같은 코드를 보는 것은 드문 일이 아닙니다.

    // Find if the user is an actual author in order to allow her to edit the message.
    if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))

이 표현은 아마도로 시작한 if (message.author == currentUser)다음 저자 일 필요가없고 잠긴 물건을 신경 쓰지 않는 잠긴 메시지와 관리자의 경우를 처리하도록 진화했습니다. 그러나 의견에는 이러한 변경 사항이 반영되지 않았습니다.

두 가지 이점이 모두 중요하지는 않지만 추가 변수가 저렴하므로 실제로 사용하는 것이 좋습니다.

부울 표현식이 지나치게 복잡 해지는 경우 :

• 별도의 방법으로 추출하고 다음을 수행하십시오 .
• 여러 간단한 부울 식으로 리팩터링하십시오.

위의 예는 다음과 같습니다.

class Message
{
    ...
    public boolean canBeEditedBy(User user)
    {
        ...
        if (user.isAdministrator) {
            return true;
        }

        return this.author == user && !this.locked;
    }
}

...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
    ...
}

^{¹ 출처 : 대부분 비즈니스 소프트웨어를 개발하는 동료에 대한 본인의 관찰; YMMV. 실제 연구는 다른 결과를 보여줄 수 있습니다. 개인적으로 개발자가 코드를 읽을 때 코드에 초점 을 맞추고 있으며 주석은 코드 가 아니라 문서라고 생각합니다. 따라서 일반적으로 주석을 읽지 않으므로 주석을 업데이트하기를 기대하기가 어렵습니다.}

^{² 지나치게 복잡한 임계 값은 간단한 공식으로 정의됩니다. 코드를 검토 한 개발자의 절반이 살인 의도를 표현하면 임계 값에 도달합니다. 위의 부울 식은 리팩토링이 필요할 정도로 간단합니다. 그러나 연속으로 네 부분으로 if ((a && b) || (c && d))구성되어 잠재적으로 리팩터링이 가능합니다. 표현이 평평하면 부품 수는 대부분 관련이 없습니다. if (a || b || c || d || ... || z)충분히 읽을 수 있습니다.}