반환 값과 반환 문 계산을 한 줄로 나누시겠습니까?

동료와 의견을 나누고 return두 줄로 반환 값을 계산 하는 진술 에 대해 토론했습니다 .

예를 들어

private string GetFormattedValue()
{
    var formattedString = format != null ? string.Format(format, value) : value.ToString();
    return formattedString;
}

대신에

private string GetFormattedValue()
{
    return format != null ? string.Format(format, value) : value.ToString();
}

코드 측면에서는 첫 번째 변형에서 실제로 가치를 보지 못합니다. 나를 위해, 후자는 특히 짧은 방법에 대해 더 명확합니다. 그의 주장은 이전의 변형이 디버그하기 쉽다는 것이 었습니다. VisualStudio는 중단 점으로 인해 실행이 중지 될 때 명령문을 매우 상세하게 검사 할 수 있기 때문에 아주 작은 장점입니다.

내 질문은, 코드를 덜 명확하게 작성하는 것이 여전히 유효하다면, 디버깅을 더 쉽게 만드는 것입니까? 분할 계산 및 명령문이 있는 변형에 대한 추가 인수 가return 있습니까?

변수를 설명하는 것은 잘 알려진 리팩토링 으로 복잡한 표현을 더 읽기 쉽게 만드는 데 도움이 될 수 있습니다. 그러나 표시된 경우

• 추가 변수는 주변 메소드 이름에서 명확하지 않은 것을 "설명"하지 않습니다
• 문장이 더 길어 지므로 (약간) 읽기가 어렵다

또한 최신 버전의 Visual Studio 디버거는 불필요한 변수를 도입하지 않고도 대부분의 경우 함수의 반환 값을 표시 할 수 있습니다 (그러나주의해야합니다. 몇 가지주의 사항 이 있습니다.

따라서이 특정 경우, 나는 당신에게 동의하지만 설명 변수가 실제로 코드 품질을 향상시킬 수있는 다른 경우가 있습니다.

사실은 다음과 같습니다.

a) 컴파일러가 변수를 멀리 최적화하므로 최종 코드에는 영향을 미치지 않습니다.

b) 분리하면 디버깅 기능이 향상됩니다.

나는 개인적으로 시간의 99 %를 분리하는 것이 좋은 습관이라는 결론에 도달했습니다.

이 방법으로 수행하는 데 중요한 단점은 없습니다. 부풀어 오른 코드는 읽을 수 없거나 디버그하기 어려운 코드와 비교하여 사소한 문제이기 때문에 코드를 부풀린다는 주장은 잘못되었습니다. 또한이 방법만으로는 혼란스러운 코드를 만들 수 없으며 이는 전적으로 개발자에게 달려 있습니다.

종종 일부 결과의 이름을 지정하기 위해 변수를 도입하면 코드를보다 자체 문서화 할 때 매우 유용합니다. 이 경우 변수 이름이 메소드 이름과 매우 유사하기 때문에 이는 요인이 아닙니다.

한 줄 방법에는 고유 한 값이 없습니다. 변경 사항이 더 많은 행을 도입하지만 코드를 더 명확하게 만들면 좋은 변경입니다.

그러나 일반적으로 이러한 결정은 개인 취향에 따라 크게 달라집니다. 예를 들어 조건부 연산자를 불필요하게 사용하고 있기 때문에 두 솔루션이 혼동됩니다. if 문을 선호했을 것입니다. 그러나 팀에서는 다른 협약에 동의했을 수도 있습니다. 그런 다음 컨벤션에서 제안하는대로하십시오. 이와 같은 경우에 규칙이 침묵하는 경우 장기적으로 중요하지 않은 매우 작은 변경 사항입니다. 이 패턴이 반복적으로 발생하면 팀이 이러한 사례를 처리하려는 방식으로 토론을 시작할 수 있습니다. 그러나 그것은“좋은 코드”와“아마도 조금 더 나은 코드”로 헤어를 나누고 있습니다.

질문에 대한 답변 :

내 질문은, 코드를 덜 명확하게 작성하는 것이 여전히 유효하다면, 단순히 디버깅을 더 쉽게 만드는 것입니까?

예. 사실, 당신의 이전 문장의 일부가 될 날 (악의)에 보이는 작은 근시안적 "(아래 굵은 참조) 이전 변종 디버깅 쉽다는 것을이었다 무엇이든지 그의 주장 - 아주 작은 장점입니다 으로 VisualStudio 때문에, 중단 점으로 인해 실행이 중지 될 때 명령문을 매우 상세하게 검사 할 수 있습니다. "

일부 추정에 따르면 프로그래머 시간의 50 %가 디버깅에 소비되기 때문에 (쉽게 디버깅 할 수 있음) "거의 장점 " 은 아닙니다 ( 가역 디버깅 소프트웨어 ).

split 계산 및 return 문이있는 변형에 대한 추가 인수가 있습니까?

예. 일부 개발자는 분할 계산을보다 쉽게 ​​읽을 수 있다고 주장합니다. 물론 이것은 디버깅에 도움이되지만 누군가 코드에서 수행하거나 적용 할 수있는 비즈니스 규칙을 해독하려는 경우에도 도움이됩니다.

참고 : 비즈니스 규칙은 자주 변경 될 수 있으므로 데이터베이스에서 더 잘 제공 될 수 있습니다. 그럼에도 불구하고이 분야의 명확한 코딩은 여전히 ​​가장 중요합니다. ( 비즈니스 규칙 엔진을 작성하는 방법 )

더 나아가겠다.

private string GetFormattedValue()
{
    if (format != null) {
        formattedString = string.Format(format, value);
    } else {
        formattedString = value.ToString()
    }
    return formattedString;
}

왜?

더 복잡한 논리에 삼항 연산자를 사용하면 읽을 수 없으므로 더 복잡한 명령문에는 위와 같은 스타일을 사용합니다. 이 스타일을 항상 사용하면 코드가 일관되고 사람이 파싱하기 쉽습니다. 또한 이러한 종류의 일관성을 도입하고 코드 보푸라기 및 기타 테스트를 사용하면 goto fail형식 오류를 피할 수 있습니다.

또 다른 장점은 테스트 적용을 잊어 버린 경우 코드 적용 범위 보고서가 format널이 아님 을 알려 줍니다. 삼항 연산자의 경우에는 그렇지 않습니다.

내가 선호하는 대안-당신이 "가능한 한 빨리 군중을 얻는다"고 방법에서 여러 번의 반품에 반대하지 않는 경우 :

private string GetFormattedValue()
{
    if (format != null) {
        return string.Format(format, value);
    }

    return value.ToString();
}

따라서 마지막 반품을보고 기본값이 무엇인지 확인할 수 있습니다.

일관성을 유지하는 것이 중요합니다. 모든 방법이 하나 이상의 규칙을 따르도록하십시오.

나는 그러한 기술이 디버그의 필요성에 의해 정당화 될 수 있다고 생각하지 않습니다. 나는이 접근법을 수천 번 직접 경험했으며 때때로이 작업을 계속하고 있지만 Martin Fowler가 디버깅에 대해 말한 것을 항상 명심하십시오 .

또한 사람들은 디버깅에 소비하는 시간을 과소 평가합니다. 그들은 긴 버그를 추적하는 데 얼마나 많은 시간을 소비 할 수 있는지 과소 평가합니다. 테스트를 통해 버그를 추가하면 바로 알 수 있습니다. 크롤링하고 숨길 수 있기 전에 즉시 버그를 수정할 수 있습니다. 디버깅보다 좌절하거나 시간을 낭비하는 것은 거의 없습니다. 우리가 처음에 버그를 만들지 않았다면 훨씬 더 빨리 지옥이 아닐까요?

삼항 연산자와 같은 문제에 대한 문제에 사람들이 걸려 있다고 생각합니다. 그렇습니다. 많은 사람들이 싫어하기 때문에 어쨌든 기르는 것이 좋습니다.

질문의 초점과 관련하여 반환 된 문을 변수로 참조하도록 옮기십시오 ...

이 질문은 내가 동의하지 않는 두 가지 가정을합니다.

1. 두 번째 변형이 더 명확하거나 읽기 쉽습니다 (반대가 사실이라고 말합니다).

2. 누구나 Visual Studio를 사용합니다. Visual Studio를 여러 번 사용했으며 잘 사용할 수 있지만 일반적으로 다른 것을 사용하고 있습니다. 특정 IDE를 강요하는 개발 환경은 회의적입니다.

명명 된 변수로 무언가를 나누는 것은 거의 읽기가 어렵지 않으며 거의 ​​항상 반대입니다. 자기 문서 감독이 분명히 나쁜 경우와 같이 누군가가 문제를 일으킬 수있는 구체적인 방식var thisVariableIsTheFormattedResultAndWillBeTheReturnValue = ... 은 별개의 문제입니다. var formattedText = ...괜찮습니다.

이 특정 경우, 그리고 아마도 1- 라이너에 대해 이야기하고 있기 때문에 많은 경우에 변수는 함수 이름이 이미 알려주지 않았다고 말하지 않습니다. 따라서 변수가 많이 추가되지 않습니다. 디버깅 인수는 여전히 유지 할 수 있지만이 특정 경우 디버깅 할 때 초점이 될만한 것을 보지 못하고 누군가가 디버깅을 위해 해당 형식이 필요한 경우 나중에 쉽게 쉽게 변경할 수 있습니다.

일반적으로 일반 규칙을 요청한 경우 (예 : 일반화 된 형식의 예) 변형 1 (2 라이너)을 선호하는 모든 사항이 정확합니다. 이것들은 좋은 지침입니다. 그러나 지침은 유연해야합니다. 예를 들어, 현재 작업중 인 프로젝트는 한 줄에 최대 80 자이므로 많은 줄을 나눕니다.하지만 일반적으로 81-85 자의 줄을 찾아서 가독성을 나누거나 줄이기가 어려울 수 있습니다. 한계.

가치를 추가 할 가능성이 없기 때문에 주어진 특정 예에 대해 2 줄을 사용하지 않을 것입니다. 이 경우 점이 다른 방법으로 할만 큼 강하지 않기 때문에 변형 2 (1 라이너)를 사용합니다.