Clean Code의 블록과 추가 매개 변수에 추가 라인

문맥

에서 클린 코드 , 35 페이지, 그것은 말한다

이는 if 문, else 문, while 문 등의 블록은 한 줄 길이 여야 함을 의미합니다. 아마도 그 라인은 함수 호출이어야합니다. 이렇게하면 둘러싼 함수가 작게 유지 될뿐만 아니라 블록 내에서 호출 된 함수의 이름이 잘 설명 될 수 있으므로 다큐멘터리 값도 추가됩니다.

나는 완전히 동의합니다.

나중에 40 페이지의 함수 인수에 대해 설명합니다.

함수에 대한 이상적인 인수 수는 0입니다 (나일론). 다음은 하나 (모나 딕)가오고 그 뒤에는 2 (이차)가옵니다. 가능한 경우 세 가지 주장 (삼국 법)을 피해야합니다. 3 개 이상 (다 극적)은 매우 특별한 타당성을 요구하므로 어쨌든 사용해서는 안됩니다. 인수는 어렵다. 그들은 많은 개념적 힘을 취합니다.

나는 완전히 동의합니다.

발행물

그러나 나는 종종 다른 목록에서 목록을 작성하는 것을 발견하고 두 가지 악 중 하나와 함께 살아야합니다.

어느 내가 블록에 두 줄을 사용하여 , 결과에 추가하는 것은, 하나를 만들기위한 하나

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            Flurp flurp = CreateFlurp(badaBoom);
            flurps.Add(flurp);
        }
        return flurps;
    }

또는 항목을 추가 할 목록 의 함수 에 인수를 추가하여 "한 인수를 더 악화시킵니다".

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            CreateFlurpInList(badaBoom, flurps);
        }
        return flurps;
    }

의문

내가 보지 못하는 (단점) 장점이 있습니까? 또는 특정 상황에서 그러한 이점이 있습니까? 이 경우 결정을 내릴 때 무엇을 찾아야합니까?

이 지침은지도가 아닌 나침반입니다. 그들은 합리적인 방향으로 당신을 가리 킵니다 . 그러나 어떤 솔루션이“최고의”솔루션인지 절대적으로 말할 수는 없습니다. 어느 시점에서 목적지에 도착했기 때문에 나침반이 가리키는 방향으로 걷기를 중단해야합니다.

Clean Code는 코드를 매우 작고 명백한 블록으로 나누도록 권장합니다. 그것은 일반적으로 좋은 방향입니다. 그러나 인용 된 조언을 문자 그대로 해석하여 극단적으로 가져 가면 코드를 쓸모없는 작은 조각으로 세분화합니다. 실제로는 아무것도하지 않으며 모든 것이 위임됩니다. 이것은 본질적으로 또 다른 종류의 코드 난독 화입니다.

“너무 작을수록 쓸모가 없다”와“작을수록 좋다”의 균형을 맞추는 것이 당신의 일입니다. 어떤 솔루션이 더 간단한 지 스스로에게 물어보십시오. 필자에게는 분명히 목록을 구성하는 첫 번째 솔루션 입니다. 이것은 잘 이해되는 관용구입니다. 또 다른 기능을 보지 않고도 해당 코드를 이해할 수 있습니다.

더 잘 할 수 있다면,“목록에서 다른 목록으로 모든 요소 변환”은 기능적 map()연산 을 사용하여 추상화 될 수있는 일반적인 패턴이라는 점에 주목해야 합니다. C #에서는이라고 Select합니다. 이 같은:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(BadaBoom => CreateFlurp(badaBoom)).ToList();
}

함수에 대한 이상적인 인수 수는 0입니다 (나일론)

아니! 함수에 대한 이상적인 인수 수는 하나입니다. 값이 0이면 작업을 수행 할 수 있도록 함수가 외부 정보에 액세스해야합니다. "삼촌"밥이 이걸 매우 잘못했습니다.

코드와 관련하여 첫 번째 예제는 첫 번째 행에 로컬 변수를 작성하기 때문에 블록에 두 개의 행만 있습니다. 해당 할당을 제거하면 다음과 같은 깨끗한 코드 지침을 준수하게됩니다.

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    List<Flurp> flurps = new List<Flurp>();
    foreach (BadaBoom badaBoom in badaBooms)
    {
        flurps.Add(CreateFlurp(badaBoom));
    }
    return flurps;
}

그러나 그것은 매우 긴 감기 (C #) 코드입니다. 그냥 다음과 같이하십시오 :

IEnumerable<Flurp> CreateFlurps(IEnumerable<BadaBoom> badaBooms) =>
    from badaBoom in babaBooms select CreateFlurp(badaBoom);

'클린 코드'조언은 완전히 잘못되었습니다.

루프에 두 개 이상의 줄을 사용하십시오. 함수에서 동일한 두 줄을 숨기는 것은 설명이 필요한 임의의 수학 일 때 의미가 있지만, 줄이 이미 기술적 인 경우에는 아무 것도하지 않습니다. '만들기'와 '추가'

두 번째 줄을 피하기 위해 두 번째 인수를 추가하지 않아도되므로 두 번째 방법은 실제로 의미가 없습니다.

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            flurps.Add(badaBoom .CreateFlurp());
            //or
            badaBoom.AddToListAsFlurp(flurps);
            //or
            flurps.Add(new Flurp(badaBoom));
            //or
            //make flurps a member of the class
            //use linq.Select()
            //etc
        }
        return flurps;
    }

또는

foreach(var flurp in ConvertToFlurps(badaBooms))...

다른 사람들이 지적했듯이, 최상의 기능은 인수가없는 기능이라는 조언은 OOP로 기울어지고 최악의 경우에는 명백한 나쁜 조언입니다

두 번째는 CreateFlurpInList목록 을 수락하고 해당 목록을 수정하여 함수가 순수하지 않고 추론하기가 어렵 기 때문에 확실히 더 나쁩니다 . 메소드 이름의 어떤 것도 메소드가 목록에만 추가한다고 제안하지 않습니다.

그리고 나는 세 번째 최선의 옵션을 제공합니다.

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(CreateFlurp).ToList();
}

그리고 하나의 라이너 자체가 명확하기 때문에 사용되는 장소가 하나 뿐인 경우 즉시 해당 메소드를 인라인 할 수 있으므로 의미를 부여하기 위해 메소드로 캡슐화 할 필요가 없습니다.

하나의 인수 버전이 더 좋지만, 주로 인수의 수로 인한 것은 아닙니다.

가장 중요한 이유는 커플 링 이 낮아서 더 유용하고, 추론하기 쉽고, 테스트하기 쉽고, 복사 + 붙여 넣기 된 복제본으로 전환 할 가능성이 적기 때문입니다.

당신이 저를 제공하는 경우 CreateFlurp(BadaBoom)간단한 : 나는 수집 컨테이너의 모든 유형이 사용할 수 있습니다 Flurp[], List<Flurp>, LinkedList<Flurp>, Dictionary<Key, Flurp>, 등. 하지만와 함께 내 뷰 모델에서 목록이 변경되었다는 알림을받을 수 있도록 CreateFlurpInList(BadaBoom, List<Flurp>)내일 다시 방문 할 예정 CreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)입니다. 왝!

추가적인 이점으로 서명이 단순할수록 기존 API에 더 적합 할 수 있습니다. 반복되는 문제가 있다고

오히려 다른 목록에서 목록을 작성하는 경우가 종종 있습니다.

사용 가능한 도구를 사용하기 만하면됩니다. 가장 짧고 효율적이며 최상의 버전은 다음과 같습니다.

var Flurps = badaBooms.ConvertAll(CreateFlurp);

이 코드는 작성 및 테스트를위한 코드가 적을뿐만 아니라 List<T>.ConvertAll()결과가 입력과 동일한 수의 항목을 갖고 결과 목록을 올바른 크기로 미리 할당 할 수있을 정도로 똑똑하기 때문에 더 빠릅니다 . 코드 (두 버전 모두)에서 목록을 확장해야했습니다.

코드를 쉽게 읽고 유지 관리 할 수 ​​있도록 전반적인 목표를 명심하십시오.

종종 여러 줄을 하나의 의미있는 기능으로 그룹화 할 수 있습니다. 이 경우 그렇게하십시오. 때때로, 당신은 일반적인 접근법을 재고해야 할 것입니다.

예를 들어, 전체 구현을 var로 바꾸는 경우

flups = badaBooms.Select(bb => new Flurp(bb));

가능성이 있습니다. 아니면 당신은 같은 것을 할 수 있습니다

flups.Add(new Flurp(badaBoom))

때로는 가장 깨끗하고 읽기 쉬운 솔루션이 한 줄에 맞지 않을 수도 있습니다. 두 줄이 있습니다. 임의의 규칙을 이행하기 위해 코드를 이해하기 어렵게 만들지 마십시오.

두 번째 예는 (제 생각에) 첫 번째 것보다 이해하기가 상당히 어렵습니다. 두 번째 매개 변수가 아니라 매개 변수가 함수에 의해 수정 된 것입니다. Clean Code가 무엇에 대해 말하고 있는지 찾아보십시오. (현재 책을 가지고 있지는 않지만 기본적으로 "피할 수 있다면 그렇게하지 마십시오"라고 확신합니다).