겸손한 견해로는 일반적으로 다른 작업을 수행하는 산발적 인 기능을 제외하고는 일반적으로 코드를 작성하려고하지 않기 때문에 일반적으로 프로덕션 코드에서 크게 피해야합니다. 테스트하는 데 사용되는 일부 스크랩 코드에서 수행하는 경향이 있지만 프로덕션 코드에서 각 함수가 수행해야 할 작업에 대해 미리 생각한 유혹을 찾지 않습니다. 로컬 상태와 관련하여 제한된 범위.

나는 익명 블록의 이러한 조건 (조건부, try트랜잭션 블록 등을 포함하지 않음)이 왜 그럴 수 없는지에 대한 질문을하지 않은 함수에서 의미있는 방식으로 범위를 줄이기 위해 사용 된 예를 본 적이 없습니다. 익명 블록의 진정한 SE 관점에서 실제로 실제로 이익을 얻는다면 범위가 줄어든 간단한 함수로 더 나눌 수 있습니다. 그것은 일반적으로 우리가 이것에 도달하려는 유혹을받는 느슨하게 관련되거나 매우 관련이없는 것들을 수행하는 절충주의 코드입니다.

예를 들어,이라는 변수를 재사용하기 위해이 작업을 수행하려는 경우 count두 가지 별개의 것을 세는 것이 좋습니다. 변수 이름이만큼 짧으면 count함수의 컨텍스트에 연결하는 것이 좋습니다. 잠재적으로 한 가지 유형의 항목 만 계산할 수 있습니다. 그런 다음 함수의 이름 및 / 또는 설명서를 count즉시 보고를 참조 하고 모든 코드를 분석하지 않고 함수가 수행하는 작업의 맥락에서 그 의미가 무엇인지 즉시 알 수 있습니다. 나는 익명의 스코프 / 블록을 대안에 비해 매력적으로 만드는 방식으로 동일한 변수 이름을 재사용하는 두 가지 다른 것을 세는 함수에 대한 좋은 주장을 찾지 못합니다. 모든 기능이 한 가지만 계산해야한다는 것은 아닙니다. 나는’엔지니어링은 동일한 변수 이름을 사용하여 둘 이상의 항목을 계산하고 익명 블록을 사용하여 각 개별 수의 범위를 제한하는 기능에 유용합니다. 함수가 단순하고 명확하다면, 처음에는 이상적으로 필요한 것보다 몇 줄 더 많은 스코프 가시성이있을 수있는 두 개의 다른 이름의 카운트 변수를 갖는 것이 세계의 끝이 아닙니다. 이러한 함수는 일반적으로 로컬 변수의 최소 범위를 더 줄이기 위해 익명 블록이없는 오류의 원인이 아닙니다.

불필요한 방법에 대한 제안이 아님

이것은 단순히 범위를 줄이기 위해 강제로 메소드를 작성하도록 제안하는 것이 아닙니다. 그것은 틀림없이 나쁘거나 나쁘고, 내가 제안하는 것은 익명의 범위에 대한 필요 이상으로 어색한 개인 “도우미”방법의 필요성을 요구해서는 안됩니다. 그것은 코드에 대해 너무 많이 생각하고 있으며 변수의 범위를 줄이는 방법보다 인터페이스의 수준에서 문제를 개념적으로 해결하는 방법보다 블록의 깊은 중첩없이 자연스럽게 로컬 함수 상태를 깨끗하고 짧은 가시성을 얻는 방법에 대한 생각보다 6 단계 이상의 들여 쓰기 나는 3 줄의 코드를 함수에 강제로 삽입하여 코드 가독성을 방해 할 수 있다고 Bruno에 동의하지만, 그것은 당신이 기존 구현에 따라 생성하는 함수를 진화시키고 있다는 가정에서 시작됩니다. 구현에 얽매이지 않고 함수를 디자인하는 대신. 후자의 방법으로 수행하면 무해한 코드 몇 줄로 변수의 범위를 열성적으로 줄이려고하지 않는 한 주어진 방법 내에서 변수 범위를 줄이는 것 외에는 목적이없는 익명의 블록이 거의 필요하지 않습니다. 이 익명 블록의 이국적인 도입은 그들이 제거하는 것만 큼 많은 지적 오버 헤드에 기여할 것입니다.

최소 범위를 더욱 줄이려고 노력

지역 변수 범위를 절대 최소값으로 줄이는 것이 가치가 있다면 다음과 같은 코드를 광범위하게 수용해야합니다.

ImageIO.write(new Robot("borg").createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize())), "png", new File(Db.getUserId(User.handle()).toString()));

… 그러므로 처음에 변수를 참조 할 변수를 만들지 않아도 상태의 가시성이 최소화됩니다. 나는 독단적으로 벗어나고 싶지 않지만 실제로 실용적인 해결책은 위의 괴물 같은 코드 줄을 피하는 것과 마찬가지로 가능한 한 익명 블록을 피하는 것입니다. 함수 내에서 정확성과 불변성을 유지하는 관점에서 코드를 함수로 구성하고 인터페이스를 디자인하는 방법을 다시 검토 할 가치가 있다고 생각합니다. 당연히 분석법이 400 줄이고 변수의 범위가 필요 이상으로 300 줄의 코드로 보이는 경우 이는 진정한 엔지니어링 문제 일 수 있지만 익명 블록으로 해결해야하는 문제는 아닙니다.

다른 곳이 없다면, 사방에 익명의 블록을 사용하는 것이 관용적이 아닌 이국적이며, 이국적인 코드는 몇 년이 지난 후에도 다른 사람들에 의해 미워 될 위험이 있습니다.

범위 축소의 실용적 유용성

변수의 범위를 줄이는 궁극적 인 유용성은 상태 관리를 올바르게 유지하고 올바르게 유지하고 코드베이스의 특정 부분이 수행하는 작업에 대해 쉽게 추론 할 수 있도록하는 것입니다. 개념적 불 변형을 유지할 수 있습니다. 단일 함수의 로컬 상태 관리가 너무 복잡하여 코드에서 익명의 블록으로 범위를 강제로 줄여야하지만 최종적이고 좋은 것이 아니며 다시 말하면 함수 자체를 다시 검사해야한다는 신호입니다. . 로컬 함수 범위에서 변수의 상태 관리에 대한 추론이 어려운 경우 전체 클래스의 모든 메소드에 액세스 할 수있는 개인 변수에 대한 추론의 어려움을 상상하십시오. 익명 블록을 사용하여 가시성을 줄일 수 없습니다. 저에게 변수를 유지하는 데 어려움을 겪지 않는 지점에서 변수가 손에 닿지 않는 한 변수가 많은 언어에서 이상적으로 필요한 것보다 약간 넓은 범위를 갖는 경향이 있다는 점을 받아들이는 것이 도움이됩니다. 실용적인 관점에서 받아들이는 것처럼 볼 때 익명 블록으로 많은 것을 해결하는 것은 아닙니다.

답변

{
    char[] password = getPassword();
    try{
        keyStore.load(new FileInputStream(keyStoreLocation), password);
        keyManager.init(keyStore, password);
    }finally{
        Arrays.fill(password, '\0');
    }
}

{
    MethodBuilder m_ToString = tb.DefineMethod("ToString", MethodAttributes.Public | MethodAttributes.Virtual | MethodAttributes.Final, typeofString, Type.EmptyTypes);
    var il = m_ToString.GetILGenerator();
    il.Emit(OpCodes.Ldstr, templateType.ToString()+":"+staticType.ToString());
    il.Emit(OpCodes.Ret);
    tb.DefineMethodOverride(m_ToString, m_Object_ToString);
}
{
    PropertyBuilder p_Class = tb.DefineProperty("Class", PropertyAttributes.None, typeofType, Type.EmptyTypes);
    MethodBuilder m_get_Class = tb.DefineMethod("get_Class", MethodAttributes.Public | MethodAttributes.Virtual | MethodAttributes.Final, typeofType, Type.EmptyTypes);
    var il = m_get_Class.GetILGenerator();
    il.Emit(OpCodes.Ldtoken, staticType);
    il.Emit(OpCodes.Call, m_Type_GetTypeFromHandle);
    il.Emit(OpCodes.Ret);
    p_Class.SetGetMethod(m_get_Class);
    tb.DefineMethodOverride(m_get_Class, m_IPattern_get_Class);
}