Em que ponto é tabu ter loops dentro de loops?

Apenas curioso. O máximo que eu já tive foi um loop for dentro de um loop for, porque depois de ler isso em Linus Torvalds:

As guias têm 8 caracteres e, portanto, os recuos também têm 8 caracteres. Existem movimentos heréticos que tentam aprofundar os recuos de 4 (ou até 2!) Caracteres, e isso é semelhante a tentar definir o valor de PI como 3.

Fundamentação da petição: A idéia por trás do recuo é definir claramente onde um bloco de controle começa e termina. Especialmente quando você olha para a tela por 20 horas seguidas, é muito mais fácil ver como a indentação funciona se você tiver grandes indentações.

Agora, algumas pessoas alegam que ter recuos de 8 caracteres faz com que o código se mova muito para a direita e dificulta a leitura em uma tela de terminal de 80 caracteres. A resposta para isso é que, se você precisar de mais de 3 níveis de indentação, estará ferrado de qualquer maneira e deverá corrigir seu programa.

https://www.kernel.org/doc/Documentation/CodingStyle

Achei que era uma prática inaceitável para eu ir para uma terceira camada de loop e reestruturar meu código (Principalmente Qt).

Linus estava brincando?

Depende do idioma ou aplicativo?

Existem coisas que absolutamente precisam de três ou mais níveis de loop?

O kernel prefere fortemente algoritmos simples

Embora uma variedade de algoritmos possa exigir loops profundamente aninhados dentro de loops, no contexto do kernel do Linux (no qual a citação foi mencionada), geralmente você precisa de respostas rápidas em tempo real. Nesse contexto, o aninhamento profundo é um cheiro que pode indicar que o fluxo de código é muito complexo para esse domínio e pode precisar ser alterado devido às suas características de execução, não à legibilidade ou problemas de indentação.

Além disso, o kernel do Linux é diferente da maioria dos códigos de aplicativos quanto aos requisitos de auditabilidade e teste - e, portanto, prefere não ter um algoritmo aninhado de nível 4+ em uma única função. Deve ser óbvio ver o que cada fragmento de código faz exatamente e em detalhes, incluindo todos os casos possíveis de fluxo de controle e borda. Um código profundamente aninhado dificulta isso.

Até certo ponto, parei de levar a sério essa citação em "Guias de 8 caracteres" . O ponto principal dos tabuladores é que eles não são um número fixo de caracteres (se houver, uma guia é um caractere). Quanta bobagem. Da mesma forma, não estou completamente convencido de que definir uma regra rígida e rápida de "três níveis de indentação" seja sensato (tanto quanto definir uma regra rígida para qualquer coisa é sensato).

No entanto, limitar seus níveis de indentação é geralmente uma sugestão razoável, e não uma que deveria ser uma surpresa para você.

Por fim, se seu programa precisa de três níveis de iteração, é disso que ele precisa . O espírito da citação não é aliviar magicamente esse requisito do seu projeto, mas agrupar a lógica em funções e tipos para que seu código seja mais tenso e mais expressivo.

Isso apenas alimenta a mesma diretriz acima, em relação aos níveis de indentação. É sobre como você estrutura seu código e o mantém legível, fácil de manter e divertido de modificar nos próximos anos.

O ponto é o mesmo de qualquer construção de controle de fluxo: se o código for difícil de entender, você precisará refatorá-lo. Se você estiver fazendo uma manipulação simples de uma matriz multidimensional, ter loops aninhados com profundidade de cinco ou seis profundidade pode ser apropriado, desde que a lógica no loop mais interno seja direta. No entanto, se você estiver processando alguma lógica comercial complicada e o corpo do seu loop tiver uma dúzia de linhas ou mais, provavelmente não desejará aninhar mais do que um loop com profundidade. Você pode tentar calcular a complexidade ciclomática do código, mas o que realmente se resume é a legibilidade e manutenção do código em questão.

Linus estava brincando?

A peça é escrita em um estilo lúdico que sugere que o autor esteja familiarizado com o modo como o estilo de codificação é discutido entre os praticantes sérios: todos nós temos nossas preferências e as defendemos raivosamente, mas com a língua pelo menos parcialmente na bochecha. Entendemos perfeitamente que muito disso é apenas uma questão de gosto pessoal. Ele diz, em tantas palavras,"Coding style is very personal, and I won't _force_ my views on anybody" - pelo menos fora do código que ele pessoalmente mantém. Mas a consistência do estilo em um determinado projeto é uma ótima idéia. Prefiro codificar para um estilo que não gosto do que lidar com vários estilos em uma determinada função.

Aqui está um exemplo de escrita claramente divertida:

However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
    body of function
}

Heretic people all over the world have claimed that this inconsistency
is ...  well ...  inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
special anyway (you can't nest them in C).

Brincalhão (1).

É sem dúvida um bom conselho tentar manter o recuo fora de controle, embora um máximo de três níveis possa ser hiperbólico. Não vou dar uma grep na fonte do kernel e contar sequências de quatro caracteres de tabulação, mas aposto que você poderia encontrar pelo menos um que Torvalds escreveu.

Por outro lado, se alguém pode escrever o kernel do Linux sem exceder frequentemente três níveis de indentação, um limite de três níveis pode ser um exercício que vale a pena experimentar por um tempo em seu próprio código, apenas para ver aonde ele o leva. Isso não é como uma mudança de sexo, você sabe. Não é um compromisso vitalício.

Se você se deparar com alguém na Internet que acha que ele entende de programação muito melhor do que Torvalds (2), bem, você sabe que tipo de pessoa gosta de falar muito na Internet.

Por outro lado, ele está criminalmente errado quanto às guias de oito espaços. Esse é o delírio de um homem que deve ser mantido em restrições e alimentado por uma fenda. Quatro espaços estão obviamente corretos.

(1) Mas observe como ele coloca erroneamente um espaço antes das elipses, e dois espaços depois deles e dois espaços depois de um ponto final. ERRADO, ERRADO, ERRADO. E então ele tem a ousadia descarada de castigar hereges. O herege é você, Torvalds! É VOCÊ!

(2) Se você quiser falar sobre " entender como projetar um sistema de controle de origem ", pode haver algum espaço para debate.

Nota: Caro colega usuário que enviou repetidamente a mesma edição: A formatação no material citado é mantida exatamente como o autor pretendia. Isso ocorre a partir de um ensaio sobre a formatação de texto de largura fixa, escrito em texto de largura fixa, por alguém que pensou bastante na formatação de texto de largura fixa. A formatação é uma parte consciente e deliberada da intenção do autor, e é relevante para o assunto.

Além disso, me referi a essa formatação em meu próprio texto. Se você fizer a pré-formatação, minha nota de rodapé (1) fica sem sentido. Se a pré-formatação for removida, o mesmo deverá constar no texto da nota de rodapé (1), referente aos pares de espaços após as paradas completas no final das frases. De qualquer maneira, vejo uma justificativa para remover essa nota de rodapé, por ser menos engraçada do que parecia quando a escrevi. Mas remover a formatação sem remover a nota de rodapé é inútil.

Linus tem um estilo de falar muito franco e um senso de humor seco, mas ele não estava brincando nesse caso. Há situações em que um algoritmo precisa de um aninhamento mais profundo do que dois níveis, mas você pode fazer isso usando outros meios além do recuo do código. O guia de estilo do kernel do Linux prefere fortemente esses outros métodos, devido à dificuldade de manter loops profundamente aninhados, e é isso que Linus está dizendo aqui.

Para alguns exemplos de métodos alternativos, você pode usar a recursão, dividir os loops internos em suas próprias funções ou criar estruturas de dados intermediárias.

Aninhamento excessivo é um daqueles casos mais fáceis de escrever, mas mais difíceis de ler. Definir uma grande profundidade de tabulação é a maneira de Linus também tornar mais irritante escrever.

Há muitas perguntas em que o conselho é diferente para alguém que faz a pergunta e para alguém que não faz. Se você perguntar "Devo ter loops aninhados com mais de dois níveis de profundidade", então para você, a pessoa que faz essa pergunta, a resposta é NÃO. Se você perguntar, não faça. Se você tem experiência suficiente e não precisa perguntar, sabe qual é a resposta correta em cada caso. E não discuta se você não concorda com a resposta, porque a resposta não é para você.

Parece um caso de rabo balançando o cachorro.

Se você tiver uma exibição de 80 caracteres, é claro que tentará ajustar o código da melhor forma possível, mesmo que não produza a melhor estrutura para o código .

Enfrentando o restante dos seus pontos de frente:

Achei que era uma prática inaceitável.

Eu acho que você está lendo muito sobre isso. Resista ao desejo de aceitar tudo que você lê como evangelho sem entender adequadamente o contexto.

Ele estava brincando?

Difícil de determinar o contexto, mas veja meu ponto original acima.

Depende do idioma ou aplicativo?

Muito mesmo. Pegue qualquer idioma de mainframe / midrange em que você provavelmente esteja codificando em um terminal (ou emulador de terminal).

Existem coisas que absolutamente precisam de três ou mais níveis de loop?

Sim, é muito comum em alguns algoritmos de força bruta. Consulte o Problema 31 no Projeto Euler. Este é um exemplo clássico de um problema que pode ser resolvido com força bruta usando um número de loops (8 para ser exato).

Linus estava brincando?

Não, essas são as diretrizes oficiais.

Depende do idioma ou aplicativo?

As diretrizes de codificação geralmente dependem do idioma e do aplicativo; no entanto, códigos profundamente aninhados sempre sobrecarregam o leitor.

O problema com o código aninhado é que, em geral, aumenta a complexidade ciclomática: ou seja, quanto mais aninhado o código, mais caminhos de execução em potencial existem na função. Uma explosão combinatória de possíveis caminhos de execução dificulta o raciocínio sobre o código e, portanto, deve ser evitada em geral.

Então, por que 3? Uma diretriz subjetiva de codificação é difícil de aplicar e impossível de aplicar automaticamente. A configuração de uma diretriz objetiva de codificação para o nível máximo de indentação requer a concordância de um número: no kernel do Linux, eles escolheram 3.

É arbitrário e aparentemente suficiente para eles.

Existem coisas que absolutamente precisam de três ou mais níveis de loop?

Em termos de algoritmo, provavelmente, no entanto, em linguagens suficientemente expressivas, você sempre pode refatorar o código em blocos menores (seja com funções ou fechamentos).

Obviamente, você pode escrever código ofuscado com pouco aninhamento e muitas pequenas funções se chamando sem nunca soletrar seu contrato ...

... no entanto, funções pequenas com contratos claros são muito mais fáceis de auditar do que funções grandes com contratos claros em geral.