Eu posso pensar em pelo menos dois argumentos em favor de funções longas:
Isso significa que você tem muito do contexto em torno de cada linha. Uma maneira de formalizar isso: desenhe o gráfico de fluxo de controle do seu código. Em um vértice (~ = linha) entre a entrada e a saída da função, você conhece todas as arestas recebidas. Quanto mais longa a função, mais existem vértices.
Muitas funções pequenas significam que há um gráfico de chamadas maior e mais complexo. Escolha uma linha aleatória em uma função aleatória e responda à pergunta "em que contexto (s) essa linha é executada?" Isso se torna mais difícil, quanto maior e mais complexo for o gráfico de chamadas, porque é necessário observar mais vértices nesse gráfico.
Também existem argumentos contra funções longas - a testabilidade por unidade vem à mente. Use a sua experiência ao escolher entre um e outro.
Nota: não estou dizendo que seu chefe está certo, apenas que a perspectiva dele pode não ser completamente desprovida de valor.
Acho que minha opinião é que o bom parâmetro de otimização não é o tamanho da função. Eu acho que um desiderata mais útil para pensar em termos de é o seguinte: todos os demais sendo iguais, é preferível poder ler fora do código uma descrição de alto nível da lógica de negócios e da implementação. (Os detalhes de implementação de baixo nível sempre podem ser lidos se você encontrar o bit de código relevante.)
Comentando a resposta de David Arno :
Escrever pequenas funções é uma dor, porque obriga a passar para cada uma das pequenas funções para ver o que o código está fazendo.
Se a função for bem nomeada, este não é o caso. isApplicationInProduction é evidente e não deve ser necessário examinar o código para ver o que ele faz. De fato, o oposto é verdadeiro: examinar o código revela menos sobre a intenção do que o nome da função (e é por isso que seu chefe precisa recorrer a comentários).
O nome evidencia o que significa o valor de retorno , mas não diz nada sobre os efeitos da execução do código (= o que o código faz ). Os nomes (apenas) transmitem informações sobre a intenção , o código transmite informações sobre o comportamento (a partir do qual partes da intenção às vezes podem ser inferidas).
Às vezes você quer um, às vezes o outro, então essa observação não cria uma regra de decisão universalmente válida unilateral.
Coloque tudo em um loop grande principal, mesmo que o loop principal tenha mais de 300 linhas, é mais rápido ler
Pode ser mais rápido varrer, mas para realmente "ler" o código, você precisa executá-lo efetivamente em sua cabeça. Isso é fácil com pequenas funções e é muito, muito difícil com métodos com centenas de linhas.
Concordo que você precisa executá-lo em sua cabeça. Se você tem 500 linhas de funcionalidade em uma grande função vs. em muitas pequenas funções, não está claro para mim por que isso fica mais fácil.
Suponha o caso extremo de 500 linhas de código de efeito colateral linear e você deseja saber se o efeito A ocorre antes ou depois do efeito B. No grande caso de função, use Page Up / Down para localizar duas linhas e depois compare números de linha. No caso de muitas funções pequenas, você deve se lembrar de onde os efeitos ocorrem na árvore de chamadas e, se esqueceu, deve gastar um tempo não trivial redescobrindo a estrutura dessa árvore.
Ao percorrer a árvore de chamadas das funções de suporte, você também enfrenta o desafio de determinar quando passou da lógica de negócios para os detalhes da implementação. Afirmo sem evidência * que quanto mais simples o gráfico de chamadas, mais fácil é fazer essa distinção.
(*) Pelo menos eu sou honesto sobre isso ;-)
Mais uma vez, acho que ambas as abordagens têm pontos fortes e fracos.
Escreva apenas pequenas funções se você precisar duplicar o código
Discordo. Como mostra seu exemplo de código, funções pequenas e bem nomeadas melhoram a legibilidade do código e devem ser usadas sempre que [por exemplo] você não estiver interessado no "como", apenas no "o quê" de uma parte da funcionalidade.
Se você está interessado no "como" ou "o que" é uma função da finalidade para a qual você está lendo o código (por exemplo, obter uma idéia geral versus rastrear um bug). O objetivo para o qual você está lendo o código não está disponível durante a criação do programa e você provavelmente lerá o código para diferentes propósitos; decisões diferentes serão otimizadas para diferentes propósitos.
Dito isto, essa é a parte da visão do chefe com a qual eu provavelmente não concordo mais.
Não escreva uma função com o nome do comentário, coloque sua complexa linha de código (3-4 linhas) com um comentário acima. Assim, você pode modificar o código com falha diretamente
Eu realmente não consigo entender o raciocínio por trás deste, assumindo que realmente seja sério. [...] Os comentários têm uma falha fundamental: eles não são compilados / interpretados e, portanto, não podem ser testados em unidade. O código é modificado e o comentário é deixado sozinho e você acaba não sabendo o que é certo.
Os compiladores comparam apenas nomes para igualdade; eles nunca fornecem um MisleadingNameError. Além disso, como vários sites de chamada podem chamar uma determinada função pelo nome, às vezes é mais árduo e propenso a erros alterar um nome. Os comentários não têm esse problema. No entanto, isso é um pouco especulativo; para realmente resolver isso, provavelmente seria necessário ter dados sobre se os programadores têm maior probabilidade de atualizar comentários enganosos versus nomes enganosos, e eu não tenho isso.