Refatoração em muitos métodos - isso é considerado limpo ou não? [duplicado]

O LoC em um método é uma medida completamente inútil. As coisas importantes são separação de preocupações e duplicação de código.

Um método só deve fazer uma coisa, e uma coisa deve ser expressa em seu nome. Outras coisas devem ser deixadas para outros métodos.

Os problemas decorrentes da duplicação de código não podem ser superestimados (em outras palavras, eles são sempre maiores do que você pensa). E isso por si só justificará até métodos com uma linha de código.

Por outro lado, um método que preenche uma forma grande com detalhes de um objeto big data pode facilmente ter 50 ou mais linhas de código, mas sem uma única instrução condicional. Por que você iria querer dividir isso em pedaços menores se não houver nenhum requisito funcional (ou duplicação de código)?

Os métodos mais curtos são muito mais legíveis - menos coisas a serem lembrados para entendê-los . Os defensores mais vocais do código limpo provavelmente diriam que quase todos os métodos devem ser menores que 8 linhas. E praticamente todos os desenvolvedores interessados no tópico concordarão que 70 a 80 linhas de código em um método são demais e devem ser desmembradas.

É tudo sobre separação de interesses. O método deve responder 1 pergunta ou tomar 1 decisão. E isso é tudo. Então, ter os métodos de 100 linhas de código significa que esses métodos são demais. 7-8 Os métodos LoC são absolutamente ótimos. A outra pergunta é: onde você vai colocar todos esses métodos? Ter 20 métodos curtos em uma única aula é provavelmente um tópico de preocupação. Ter 30 deles é, acredito, a boa razão para entender que algo está errado com abstrações. Apenas mantenha tudo o mais curto e simples possível.

Existe uma escola de pensamento que diz que 7-8 LOC é um pouco longo para um método. Eu não assino isso, mas eu diria que vá em frente - qualquer coisa menos que uma tela é boa para mim.

Os métodos devem ser tão simples quanto necessários , mas não mais simples.

O LoC simplesmente não é uma métrica valiosa. Em vez disso, veja quanto um método faz. Um método geralmente deve fazer uma coisa. IMHO, às vezes é ok para abordar 1 ou 2 operações muito simples. Por exemplo, calculando o perímetro de um retângulo:

Pode ser:

public int GetPerimeter(int side1, int side2)
{
    totalWidthLength = side1 * 2;
    totalHeightLength = side2 * 2;
    return totalWidthLength + totalHeightLength;
}

-OU -

public int GetPerimeter(int side1, int side2)
{
    return DoubleSide(side1) + DoubleSide(side2);
}

private int DoubleSide(int side)
{
    return side * 2;
}

Pessoalmente, prefiro o primeiro método, embora tecnicamente realize mais de uma operação. Ao mesmo tempo, você também pode ter métodos com muitas linhas de código que são simples de ler e entender.

public void UpdateCustomer()
{
    customer Customer = new Customer();

    customer.Name = textboxName.Text;
    customer.AddrLine1= textboxName.Text;
    customer.AddrLine2 = textboxName.Text;
    customer.OfficialName = textboxName.Text;
    customer.Age = textboxName.Text;
    customer.BirthDay = textboxName.Text;
    customer.NickName = textboxName.Text;
    customer.LastLocation = textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;

    db.InsertOnCommit(customer)
    db.SubmitChanges();
}

O exemplo acima é de cerca de 50 linhas, mas pode até ser de 200 linhas e não faria diferença. Cada atribuição de propriedade no objeto de cliente não adiciona praticamente nenhuma complexidade, portanto, o método de 50 linhas permanece no mesmo nível de complexidade do seu método de 4 linhas médio. Na verdade, eu diria que tem basicamente a mesma legibilidade do método abaixo:

public void UpdateCustomer()
{
    customer Customer = new Customer();

    customer.Name = textboxName.Text;

    db.InsertOnCommit(customer)
    db.SubmitChanges();
}

O método de 50 linhas provavelmente poderia ser alcançado em menos de 10 linhas por meio do uso de reflexão e regex, iterando sobre cada uma das propriedades no Customer e procurando por uma caixa de texto que tenha um valor LIKE correspondente em seu nome. Obviamente, isso seria um exemplo de código que é muito inteligente e recorre a hacks excêntricos para obter um ideal astético. O resultado é que o LoC é uma métrica de complexidade / legibilidade extremamente confiável. Todos já sabem disso (meu exemplo de CRUD não é incomum), e enquanto a maioria das pessoas fala sobre como o LoC é medíocre produtividade, estamos constantemente ouvindo sobre este LoC por regras de método que devem medir a qualidade do código. Realmente não pode ser os dois caminhos.