예를 들어 Android에서 CPU를 켜려면 다음과 같은 코드를 사용할 수 있습니다.

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

하지만 지역 변수를 생각 powerManager하고 wakeLock제거 할 수있다 :

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

iOS 경보보기에 유사한 장면이 나타납니다. 예 : from

UIAlertView *alert = [[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil];
[alert show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

에:

[[[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil] show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

범위에서 한 번만 사용 된 경우 로컬 변수를 제거하는 것이 좋습니다?

코드는 쓰여진 것보다 훨씬 자주 읽히므로, 6 개월 후에 코드를 읽어야 할 불쌍한 영혼을 불쌍히 여겨야합니다. 제 생각에는 지역 변수가있는 첫 번째 형식이 훨씬 이해하기 쉽습니다. 한 줄에 세 가지 작업이 아니라 세 줄에 세 가지 작업이 표시됩니다.

그리고 지역 변수를 제거하여 무엇을 최적화한다고 생각하면 그렇지 않습니다. 최신 컴파일러는 로컬 변수 사용 여부에 상관없이 메소드 를 호출하기 powerManager위해 레지스터 ^1을 넣 습니다 newWakeLock. 의 경우도 마찬가지입니다 wakeLock. 따라서 두 경우 모두 동일한 컴파일 된 코드로 끝납니다.

¹ 선언과 로컬 변수 사용 사이에 많은 코드가 포함되어 있으면 스택에 들어갈 수 있지만 세부 사항은 아닙니다.

고도로 찬란한 의견이 이것을 말했지만, 내가 본 대답은 없었으므로 대답으로 추가 할 것입니다. 이 문제를 결정하는 주요 요인은 다음과 같습니다.

디버깅 가능성

종종 개발자는 코드 작성보다 훨씬 많은 시간과 노력을 씁니다.

와 지역 변수, 당신은 할 수 있습니다 :

• 지정된 줄의 중단 점 (조건부 중단 점 등과 같은 다른 모든 중단 점 장식 포함)

• 지역 변수의 검사 / 감시 / 인쇄 / 값 변경

• 캐스트로 인해 발생하는 문제를 파악하십시오.

• 읽을 수있는 스택 추적이 있습니다 (라인 XYZ에는 10이 아닌 하나의 작업이 있음)

로컬 변수가 없으면 디버거에 따라 위의 모든 작업이 훨씬 어렵거나 매우 어렵거나 완전히 불가능합니다.

따라서, 악명 높은 격언에 따라 (방법으로 코드를 작성하면 하듯이 다음 개발자는 자신이 살고있는 곳을 알고 미친 미치광이 후 그것을 유지하는 경우)의 측면에 잘못을 쉽게 debuggability 의미, 사용 지역 변수 .

코드를 이해하기 쉽게 만드는 경우에만 가능합니다. 귀하의 예에서는 읽기가 더 어렵다고 생각합니다.

컴파일 된 코드에서 변수를 제거하는 것은 존경 할만한 컴파일러에게는 사소한 작업입니다. 출력을 직접 검사하여 확인할 수 있습니다.

귀하의 질문은 "범위에서 한 번만 사용 된 경우 로컬 변수를 제거하는 것이 좋습니다?" 잘못된 기준을 테스트하고 있습니다. 지역 변수의 유틸리티는 사용 횟수가 아니라 코드를 더 명확하게 만드는지 여부에 달려 있습니다. 중간 값을 의미있는 이름으로 레이블하면 코드가 더 작고 더 소화하기 쉬운 청크로 분할되므로 현재와 같은 상황에서 명확성을 향상시킬 수 있습니다.

필자가 제시 한 수정되지 않은 코드는 수정 된 코드보다 명확하므로 변경하지 않은 채로 두어야합니다. 사실, 명확성을 높이기 위해 수정 된 코드에서 로컬 변수를 가져 오는 것이 좋습니다.

로컬 변수의 성능 영향을 기대하지 않으며, 변수가 있더라도 프로그램의 속도 결정 부분에서 코드가 매우 빡빡하지 않으면 고려할만한 가치가 없습니다.

아마도.

개인적으로 타입 캐스트가 관련된 경우 로컬 변수를 제거하는 것을 망설입니다. 나는 괄호의 수가 내가 가진 정신적 한계에 다 다르기 시작함에 따라 압축 버전이 읽기 쉽지 않다는 것을 알았습니다. 심지어 로컬 변수를 사용하는 약간 더 장황한 버전에서는 필요하지 않은 새로운 괄호 세트도 소개합니다.

코드 편집기에서 제공하는 구문 강조는 이러한 문제를 어느 정도 완화 할 수 있습니다.

내 눈에 이것은 더 나은 타협입니다.

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc").acquire();

따라서 하나의 지역 변수를 유지하고 다른 지역 변수를 버립니다. C #에서는 typecast가 이미 유형 정보를 제공하기 때문에 첫 번째 줄에 var 키워드를 사용합니다.

현지 변수에 유리한 답변의 타당성을 인정하지만, 악마의 옹호자를 대적하고 반대되는 견해를 제시 할 것입니다.

나는 개인적으로 로컬 변수를 순전히 문서화하는 목적으로 로컬 변수를 사용하는 것에 반대하지만, 그 이유 자체는 실천에 가치가 있음을 나타냅니다. 로컬 변수는 효과적으로 코드를 의사 문서화합니다.

귀하의 경우 주요 문제는 변수가 아닌 들여 쓰기입니다. 코드를 다음과 같이 포맷 할 수 있습니다.

((PowerManager)getSystemService(POWER_SERVICE))
        .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag")
        .acquire();

지역 변수가있는 버전과 비교하십시오.

PowerManager powerManager=(PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"abc");
wakeLock.acquire();

지역 변수를 사용하면 이름이 독자에게 정보를 추가하고 유형이 명확하게 지정되지만 실제 메소드 호출은 덜 눈에 띄고 명확하게 읽히지 않습니다.

로컬 변수를 사용하지 않으면 : 더 간결하고 메소드 호출이 더 잘 보이지만 리턴되는 내용에 대한 자세한 정보를 요청할 수 있습니다. 그러나 일부 IDE에서는이를 보여줄 수 있습니다.

세 가지 추가 의견 :

1. 제 생각에, 기능적으로 사용되지 않는 코드를 추가하는 것은 독자가 실제로 기능적으로 사용되지 않고 단순히 "문서화"를 위해 있다는 것을 인식해야하기 때문에 때때로 혼란 스러울 수 있습니다. 예를 들어,이 메소드의 길이가 100 줄인 경우 전체 메소드를 읽지 않으면 나중에 로컬 변수 (및 메소드 호출의 결과)가 필요하지 않은 것은 분명하지 않습니다.

2. 지역 변수를 추가하면 해당 유형을 지정해야하며, 그렇지 않으면 코드에 의존성이 발생하지 않습니다. 메소드의 리턴 유형이 사소하게 변경된 경우 (예 : 이름이 바뀐 경우) 로컬 변수가 없으면 코드를 업데이트해야합니다.

3. 디버거에 메서드에서 반환 된 값이 표시되지 않으면 로컬 변수를 사용하여 디버깅하기가 더 쉬울 수 있습니다. 그러나 그 해결책은 코드를 변경하지 않고 디버거의 결함을 수정하는 것입니다.

동기 부여가 여기에 있습니다. 임시 변수를 도입하면 코드를보다 쉽게 ​​읽을 수 있습니다. 그러나 또한 Extract Method , Temp를 Query로 바꾸기 와 같은 다른 가능한 리팩토링을 방지하고보기 어렵게 만들 수 있습니다 . 후자의 리팩토링 유형은 적절한 경우 임시 변수보다 훨씬 큰 이점을 제공합니다.

Fowler는 후자의 리팩토링에 대한 동기에 대해 다음과 같이 씁니다 .

"임시의 문제점은 임시적이고 지역적이라는 것입니다. 사용되는 방법의 맥락에서만 볼 수 있기 때문에 온도는 더 긴 방법을 권장하는 경향이 있습니다. 왜냐하면 그것이 당신이 온도에 도달 할 수있는 유일한 방법이기 때문입니다." temp를 쿼리 메소드로 대체하면 클래스의 모든 메소드가 정보를 얻을 수 있습니다. 이는 클래스에 대한보다 명확한 코드를 만드는 데 도움이됩니다. "

따라서 코드를 더 읽기 쉽게 만들려면 특히 temps를 사용하십시오. 특히 사용자와 팀의 로컬 표준 인 경우. 그러나 그렇게하면 때때로 더 큰 대체 개선 사항을 찾기가 더 어려워 질 수 있다는 점에 유의하십시오. 그러한 온도없이 갈 가치가있을 때를 감지하고 그렇게 할 때 더 편안해질 수있는 능력을 개발할 수 있다면 그것은 아마도 좋은 일일 것입니다.

FWIW 나는 개인적으로 Fowler의 책 "Refactoring"을 10 년 동안 읽지 않았습니다. 왜냐하면 비교적 간단한 주제에 대해서는 말할 것도 많지 않기 때문입니다. 나는 완전히 틀렸다. 결국 읽을 때 매일 코딩 방식이 바뀌 었습니다.

코드를 더 읽기 쉽게 만들 수 있다면 지역 변수를 제거하는 것이 좋습니다 . 당신의 그 한 줄짜리 라이너는 읽을 수 없지만, 그것은 꽤 장황한 OO 스타일을 따릅니다. 당신이 그것을 같은 것으로 줄일 수 있다면

acquireWakeLock(POWER_SERVICE, PARTIAL, "abc");

아마 그것이 좋은 생각이라고 말할 것입니다. 아마도 도우미 메소드를 도입하여 비슷한 방식으로 정리할 수 있습니다. 이와 같은 코드가 여러 번 나타나면 가치가 있습니다.

여기서 Demeter 의 법칙을 고려해 봅시다 . LoD에 관한 Wikipedia 기사에는 다음이 명시되어 있습니다.

함수에 대한 Demeter of Law는 객체 O의 메소드 m이 다음과 같은 객체의 메소드 만 호출 할 수 있어야합니다. [2]

1. O 자체
2. m의 매개 변수
3. m 내에서 생성 / 인스턴스화 된 모든 객체
4. O의 직접 컴포넌트 객체
5. m 범위에서 O로 액세스 할 수있는 전역 변수

이 법칙을 따른 결과 중 하나는 위의 두 번째 예에 표시된 것처럼 긴 점으로 묶인 문자열로 다른 방법으로 반환 된 객체의 메서드를 호출하지 않아야한다는 것입니다.

((PowerManager)getSystemService(POWER_SERVICE)).newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag").acquire();

이것이 무엇을하고 있는지 알아내는 것은 정말로 어렵습니다. 이를 이해하려면 각 프로 시저의 기능을 이해 한 다음 어떤 객체에서 어떤 함수가 어떤 객체에서 호출되는지를 해독해야합니다.

PowerManager powerManager=(PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock=powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"abc");
wakeLock.acquire();

당신이하려는 일을 명확하게 보여줍니다-당신은 PowerManager 객체를 얻고 PowerManager로부터 WakeLock 객체를 얻은 다음 wakeLock을 얻습니다. 위의 규칙은 LoD의 규칙 # 3을 따릅니다. 코드 내에서 이러한 객체를 인스턴스화하여 필요한 것을 수행하는 데 사용할 수 있습니다.

아마도 또 다른 생각은 소프트웨어를 만들 때 간결함이 아니라 명확성을 위해 작성해야한다는 것을 기억하는 것입니다. 모든 소프트웨어 개발의 90 %가 유지 보수입니다. 기쁘지 않은 코드를 작성하지 마십시오.

행운을 빕니다.

한 가지주의 할 점은 코드를 자주 "다른 깊이"로 읽는다는 것입니다. 이 코드는 :

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

"탈지"하기 쉽습니다. 3 개의 진술입니다. 먼저 우리는 PowerManager. 그런 다음 우리는 WakeLock. 그럼 우리 . 각 줄의 시작 부분을 보면 아주 쉽게 알 수 있습니다. 간단한 변수 할당은 "Type varName = ..."으로 부분적으로 인식하기 쉽고 "..."에 대해 정신적으로 넘어갑니다. 마찬가지로 마지막 진술은 분명히 과제의 형태가 아니지만 두 개의 이름 만 포함하므로 "주 요 요점"은 즉시 명백합니다. 종종 "이 코드의 기능은 무엇입니까?" 높은 수준에서.acquirewakeLock

내가 여기 있다고 생각하는 미묘한 버그를 쫓고 있다면 분명히 더 자세히 설명하고 실제로 "..."를 기억할 것입니다. 그러나 별도의 진술 구조는 여전히 한 번에 하나의 진술을 수행하는 데 도움이됩니다 (특히 각 진술에서 호출되는 것들의 구현에 대해 더 깊이 뛰어들 필요가있는 경우 특히 유용합니다. 다음 문장으로 넘어갈 수 있습니다).

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

이제는 모두 하나의 진술입니다. 최상위 구조는 쉽게 읽을 수 없습니다. OP의 원래 버전에서 줄 바꿈과 들여 쓰기없이 구조를 시각적으로 전달하려면 괄호를 세어 시퀀스를 3 단계 시퀀스로 디코딩해야했습니다. 다중 부분 표현식 중 일부가 메소드 호출 체인으로 배열되지 않고 서로 중첩되어 있으면 여전히 이와 유사하게 나타날 수 있으므로 괄호를 세지 않고 신뢰해야합니다. 그리고 들여 쓰기를 신뢰 하고이 모든 것으로 추정되는 마지막 점으로 넘어 가면 .acquire()스스로 나에게 무엇을 말합니까?

때때로, 그것은 당신이 원하는 것일 수 있습니다. 내가 당신의 변환을 반쯤 적용하고 썼다면 :

WakeLock wakeLock =
     ((PowerManeger)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();

이제 이것은 빠른 탈지 "get a WakeLock, then acquireit"과 통신합니다. 첫 번째 버전보다 훨씬 간단합니다. 획득 한 것은이라는 것이 즉시 명백합니다 WakeLock. 를 얻는 PowerManager것이이 코드의 요점에 상당히 중요하지 않은 하위 세부 사항이지만 wakeLock중요한 것은 실제로 PowerManager물건 을 묻어 두는 것이 도움이 될 수 있습니다. 이 코드의 기능에 대한 아이디어. 그리고 그것은 것을 통신 명명되지 되어 한 번만 사용하고, 때로는 그건 중요한 사항 (나머지 범위가 매우 길면 다시 사용되는지 여부를 알기 위해 모든 것을 읽어야하지만 명시 적 하위 범위를 사용하면 언어를 지원하는 다른 방법이 될 수 있습니다).

상황과 의사 소통에 따라 달라집니다. 자연어로 산문 을 작성하는 것과 같이, 정보 내용의 관점에서 기본적으로 동일한 주어진 코드를 작성하는 방법 은 항상 많습니다. 당신은 일반적으로해야 그들 사이에서 선택하는 방법을 자연 언어로 산문, 쓰기와 마찬가지로 하지 같은 기계적인 규칙을 적용하는 "를 한 번만 발생하는 모든 로컬 변수를 제거". 오히려 어떻게코드를 작성하면 특정 사항을 강조하고 다른 사항을 강조하지 않습니다. 실제로 강조하고 싶은 내용을 바탕으로 (선택적으로 기술적 인 이유로 읽기 어려운 코드를 작성하는 선택을 포함하여) 선택적으로 의식적으로 선택하도록 노력해야합니다. 특히 코드의 "장점"(다양한 수준에서)을 가져와야하는 독자에게 무엇을 제공해야하는지 생각해보십시오. 이는 매우 근접한 표현 식별 읽기보다 훨씬 더 자주 발생하기 때문입니다.

이것은 자체 이름을 가진 반 패턴입니다 : Train Wreck . 교체를 피해야하는 몇 가지 이유가 이미 언급되었습니다.

• 읽기 어렵다
• 디버깅이 더 어려워 짐 (변수를보고 예외 위치를 탐지)
• 데메테르 법칙 위반 (LoD)

이 방법이 다른 객체로부터 너무 많은 것을 알고 있는지 고려하십시오. 메소드 체인 은 커플 링을 줄이는 데 도움이되는 대안입니다.

또한 객체에 대한 참조가 실제로 저렴하다는 것을 기억하십시오.

언급 된 질문은 "가능한 경우 지역 변수를 제거해야 하는가?"입니다.

단지 당신이 할 수 있기 때문에 제거해서는 안됩니다.

상점의 코딩 지침을 따라야합니다.

대부분의 지역 변수는 코드를보다 쉽게 ​​읽고 디버깅 할 수 있도록합니다.

나는 당신이 한 일을 좋아합니다 PowerManager powerManager. 저에게 클래스의 소문자는 한 번만 사용한다는 것을 의미합니다.

변수가 값 비싼 자원을 보유 할 것인지 여부는 아닙니다. 많은 언어에는 지역 변수에 대한 구문이있어 정리 / 해제해야합니다. C #에서는 사용 중입니다.

using(SQLconnection conn = new SQLconnnection())
{
    using(SQLcommand cmd = SQLconnnection.CreateCommand())
    {
    }
}

다른 답변에는 한 가지 중요한 측면이 언급되지 않았습니다. 변수를 추가 할 때마다 변경 가능한 상태가 발생합니다. 이것은 코드를 더 복잡하게 만들고 이해하고 테스트하기가 어렵 기 때문에 일반적으로 나쁜 것입니다. 물론 변수의 범위가 작을수록 문제는 더 작아집니다.

실제로 원하는 것은 값을 수정할 수있는 변수가 아니라 임시 상수입니다. 따라서 언어에서 허용하는 경우 코드로 이것을 표현하십시오. Java에서는 사용할 수 final있고 C ++에서는 사용할 수 있습니다 const. 대부분의 기능적 언어에서는 이것이 기본 동작입니다.

지역 변수가 가장 유해한 유형의 변경 가능한 상태라는 것은 사실입니다. 멤버 변수는 훨씬 더 많은 문제를 일으킬 수 있으며 정적 변수는 훨씬 더 나쁩니다. 여전히 코드에서 가능한 한 정확하게 표현하는 것이 중요하다는 것을 알았습니다. 그리고 나중에 수정 될 수있는 변수와 중간 결과의 단순한 이름 사이에는 큰 차이가 있습니다. 따라서 귀하의 언어로 이러한 차이를 표현할 수 있다면 그렇게하십시오.