Diretriz de codificação: Os métodos não devem conter mais de 7 declarações?

Eu estava olhando as Diretrizes de codificação da AvSol para C # e concordo com quase tudo, mas estou realmente curioso para ver o que os outros pensam de uma regra específica.

AV1500

Os métodos não devem exceder 7 instruções Um método que requer mais de 7 instruções está executando demais ou com muitas responsabilidades. Também requer que a mente humana analise as declarações exatas para entender o que o código está fazendo. Divida-o em vários métodos pequenos e focados, com nomes autoexplicativos.

A maioria de vocês segue esta regra? Mesmo que haja pouco a ser salvo na criação de um novo método (seu código ainda está SECO ), além de aumentar muito a legibilidade? E seu número ainda é tão baixo quanto 7? Eu tenderia mais para 10.

Não estou dizendo que viole essa regra em todo o lugar - pelo contrário, meus métodos são 95% pequenos e focados, mas dizer que você nunca deve violar essa regra realmente me deixou impressionado.

Eu realmente só quero saber o que todos pensam de NUNCA violar essa regra (é um '1' no padrão de codificação - o que significa NUNCA fazer isso). Mas acho que você teria problemas para encontrar uma base de código que não funciona.

Este é um "cheiro de padrões" para mim. Sempre que vejo padrões de codificação com limites específicos, eu me preocupo. Você quase sempre encontra um caso em que um método precisa ser maior do que o padrão permite (seja comprimento / contagem de linhas, número de variáveis, número de pontos de saída etc.). Os padrões devem ser mais parecidos com as diretrizes e permitir uma margem de manobra suficiente para o bom julgamento. Não me interpretem mal, é bom ter padrões, mas eles não devem se tornar "microgerenciamento por proxy".

Geralmente, é uma boa ideia dividir as coisas em pequenos métodos. Mas o importante é dividir as coisas onde faz sentido.

Se não faz sentido dividir, não divida. Geralmente, esse é o caso de alguns procedimentos ou código da GUI.

Steve McConnell afirmou no Code Complete que você nem sempre é mais produtivo ao usar métodos curtos. Se você dividir quando não fizer sentido, adicione complexidade ao código sem nenhum benefício.

Como sempre com as diretrizes, é bom lembrar por que as restrições existem, para que você possa aprender quando elas não se aplicam. Na maior parte do código, os métodos serão curtos, ou você provavelmente terá um problema com DRY ou separação de preocupações . Mas se não for o caso, tudo bem.

Deve ser considerado como uma regra de ouro.

Coisas como "Não mais que 80 (100.120) colunas de texto", "um ponto de saída por método", "não mais que 2 níveis de aninhamento", são o que eu chamaria de limiares para indicadores de cheiro de código. Se você violá-los ocasionalmente, isso não significa necessariamente que o código esteja incorreto. Se você os violar de forma consistente, algo cheira ao código e você pode fazer uma pausa e repensar sua abordagem.

Para mim, os critérios mais importantes são: "Este código é compreensível?", "É repetitivo?", "É dividido em locais lógicos?", "É pouco acoplado?" Existem mais alguns, mas acho que a idéia básica pode ser resumida lembrando-se do conselho de Donald Knuth: "Os programas são feitos para serem lidos por humanos e apenas por acaso os computadores executam".

Nunca dediquei tempo para contar o número de declarações em meus métodos, mas me esforço para escrever métodos que executem de maneira limpa um único objetivo claro. Desde que seu código seja limpo, legível e siga os princípios DRY e de responsabilidade única , você provavelmente já fez seu trabalho. Penso que dividir arbitrariamente um método apenas para impor o limite de sete instruções pode tornar seu código menos legível / sustentável.

É aproximado

Esses tipos de regras não devem ser tomadas de maneira muito literal. Eles poderiam ter dito que "os métodos devem ser curtos ". No entanto, algumas pessoas teriam interpretado isso como "menos de 1 página" e outras como "2 linhas no máximo".

Eu diria que eles disseram "7 declarações" para lhe dar uma idéia aproximada (embora eu ache que eles deveriam ter dito "cerca de 7"). Se precisar de 9 de vez em quando, não se preocupe. Mas se você estiver com 20 anos, saberá que não está no estádio certo para esta regra.

7 é um número completamente arbitrário com absolutamente nenhum significado.

A complexidade ciclomática é um problema maior que o número de declarações. Eu vi código que tinha centenas de instruções em um único método (que eu achei terrível), mas tinha uma complexidade ciclomática de 1 e realmente fez apenas uma coisa. Havia apenas muitos passos. Discutimos dividi-lo em métodos menores, mas esses métodos seriam chamados apenas por esse método.

Embora esse seja um caso bastante extremo, o ponto é que você precisa manter o código DRY e uma baixa complexidade ciclomática. Isso é mais importante que o número de linhas em um método.

Veja uma declaração de troca / caso, por exemplo. Se você tiver mais de 7 valores possíveis, precisará dividir a avaliação em vários métodos? Claro que não, isso seria bobagem.

A quebra artificial de código em mais métodos, apenas para manter o número de instruções abaixo de 7, só piora o seu código.

A diretriz deve ser Cada método deve fazer uma coisa e manter seu código SECO.

Bem, isso depende um pouco. Eu escrevo muito código que acessa bancos de dados. O código da placa da caldeira para manipulação de exceções tem mais de sete instruções em muitos casos. Eu diria que a melhor orientação é garantir que sua função tenha um propósito

Tudo é uma troca. O problema com a abordagem proposta - refatorar em vários métodos e classes para que cada método seja curto - é que, embora por razões diferentes, leve a um código ilegível quando levado ao extremo.

Imagine um método foo()que faça 7 coisas. Você pode argumentar que 7 coisas são demais. Talvez em muitos casos você esteja certo. Por outro lado, essas sete coisas podem estar intimamente relacionadas; a lógica pode fluir sem problemas e ler como prosa; você pode ter problemas para entender quando realmente precisa. O que pode acabar muito pior é ter essas 7 coisas distribuídas em uma grande árvore de origem, para que, se você olhar, foo()não tenha idéia do que faz sem procurar em 7 lugares diferentes.

Muitas pessoas têm regras como essa na cabeça, e o resultado é o que eu penso como espaguete OO. Tudo é arrumado, encaixotado em seu próprio método ou classe, com pequenas microtransações atômicas ocorrendo em cada local. Mas é impossível chegar a essa base de código e saber o que está fazendo. Você se perde.

não é uma má orientação. Eu nunca me arrependi de dividir métodos e classes (nunca achei que tinha muitos), desde que estejam agrupados e inter-relacionados o suficiente.

O truque é NÃO dividi-lo verticalmente (apenas aperte um método em um ponto e inicie um novo). O truque, como no teste de unidade, é manter essa regra em mente desde o início, para que você realmente projete melhor, passando 3 ou 4 instruções no meio do método para outro método, porque ter uma chamada de método descreve o que você está fazendo melhor do que essas 3 ou 4 instruções no meio do seu código.

Esse tipo de divisão, mesmo que seja arbitrário e usado apenas uma vez, pode levar a melhores refatorações mais tarde devido a uma nova clareza de código, isso também se aplica a classes menores.

Pense nisso como se fosse um teste de unidade. Se você tentar adicionar testes de unidade após o fato, é difícil e, às vezes, parecer impossível, mas se você o criar desde o início, realmente melhorará todo o seu código.

Resumo? Se comparar o cheiro de design de "Use menos de 7 instruções" com o cheiro de código de "Eu usei mais de 7 instruções", prefiro eliminar o cheiro de código.

Uau! Eu nunca esperei encontrar uma discussão tão intensa sobre uma diretriz simples que diga aproximadamente que seus métodos devem ser muito pequenos. Como eles são sempre desenvolvedores que desejam que suas diretrizes sejam explícitas, escolho 7 porque isso soou como um bom limite.

Alguns de vocês já citaram o aviso no início do documento. Mas, para deixar claro, este documento representa uma coleção de diretrizes que tentam ajudá-lo a escrever melhor código e projetar melhores sistemas. Eu nunca afirmei que algo deveria ser uma regra, mesmo que uma diretriz seja marcada como nível 1. Esses níveis são simplesmente a opinião coletiva de muitas pessoas que usam este documento há algum tempo.

Eu também nunca afirmei ser um especialista. Mas estou nessa profissão há 15 anos, com cerca de 4 anos de experiência em C ++ e 11 anos de experiência em C #. Ele foi originalmente baseado no Industrial Strength C ++, mas eu o refino desde então com a contribuição da comunidade.

Independentemente disso, o ponto que eu estava tentando levantar é que você deve continuar pensando por si mesmo. Se você acha que a diretriz das 7 declarações não é útil, basta prolongá-la. Caramba, eu até viole essa diretriz de vez em quando. Eu apenas a vi violentamente e aceito as consequências.

Em primeiro lugar: é uma diretriz, não uma regra. É chamado de orientação, portanto, trate-o como tal. Isso implica que seu próprio julgamento também é necessário (como sempre)

Além disso, posso pensar em vários exemplos de bons códigos que não aderem a essa restrição. Mesmo que seja apenas uma orientação, é péssima.

Eu concordo com a afirmação acima de mim. Isso é apenas orientação e, em um mundo perfeito, tudo seria objeto, reutilizado em todos os programas, e o mundo seria um lugar bonito. Nem sempre é verdade e, às vezes, isso levaria a muitos custos indiretos ou desperdiçados. Você precisa colocar isso em mente também.

Muito bobo quando você adiciona manipulação de exceção à mistura.

Depois de "tentar, pegar, finalmente", você terá quatro instruções por método!

Considere também um método "validateForm" para um formulário de 20 campos, mesmo se você manipular todas as validações individuais em métodos separados, você ainda terá 20 métodos de validação de campo para invocar. De acordo com essas diretrizes, você terminaria com uma divisão inútil, como "validateTopOfScreen", "validateMiddleOfScreen" e "validateBottomOfScreen".

A questão está misturando "regras" com "diretrizes". Regras devem ser obedecidas - diretrizes são conselhos que devem levar você a considerar o que está fazendo e se realmente pode ser feito de uma maneira melhor.

Eu diria que, em média, a maioria da programação provavelmente é aprimorada seguindo as diretrizes, mas sempre haverá casos em que seguir as diretrizes dogmaticamente causará mais problemas do que eles pretendiam resolver. É por isso que eles não são apresentados como regras, mas como diretrizes.

Um respondente anterior mostrou que os autores das diretrizes nunca pretendiam que elas fossem aplicadas dogmaticamente e incluiu declarações nesse sentido em seus documentos.

Eu concordo com soe dos comentários acima. 7 para mim é arbitrário e pode ser útil em algumas linguagens em que ruby, mas para linguagens como C #, Java, C ++ duvido desta convenção de "7 linhas". Deixe-me dar um exemplo. Meu aplicativo atual possui 22 campos de texto e eu faço a validação no servidor. O método é chamado validateInput () e minha preferência é validar todos os campos em um método, a menos que eu valide algo complexo como checkEmailFormat (). Então, basicamente, meu código de método validateInput é 108 linhas com chamadas ocasionais para validação complexa.

Agora imagine se eu chamasse 25 métodos para validar cada campo. Se um novo desenvolvedor entrar, ele terá que entrar e sair do método principal para passar por 25 métodos que, por sua vez, podem estar chamando alguns outros. Ele é obrigado a se perder em grandes projetos.

O que realmente faço para tornar meu código claro é fornecer comentários simples, que basicamente dizem o que essas quatro linhas estão fazendo ex -

validateInput (usuário UserObj) {

// Valida o primeiro nome ....... ......

// validar sobrenome ...... ......

// validar email ..... // muito complexo para verificar o formato do email expressão regular checkEmailFormat (); .... .....

e assim por diante.. }

Má regra. Com o código para manipulação de exceções, definindo campos de banco de dados, validação, como a maioria dos métodos pode ter menos de sete instruções? Nunca devemos executar funções lambda embutidas?

Linhas de código são uma contagem arbitrária de complexidade. Com métodos de extensão, posso criar código como

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Todos os programadores juniores devem ser forçados a aderir a esse princípio. Isso os forçaria a pensar na estrutura do que eles estão ocupados, em vez de apenas adicionar mais e mais código de linhas.

Atualmente, estou olhando para um método de 550 linhas de código com muitas instruções if else e continua e retorna tecidas nele. É porcaria. O programador apenas foi forçado a pensar no que estava fazendo ...