As regras de programação de Rob Pike (1989)

• Artigo de 1989 sobre as 5 regras de programação de Rob Pike
• Regra 1: não presuma onde o programa passará a maior parte do tempo; gargalos podem surgir de forma inesperada. Evite hacks de desempenho até que o gargalo seja comprovado.
• Regra 2: sempre meça antes de ajustar em busca de velocidade. Otimize apenas quando uma parte do código tiver impacto significativo sobre o restante.
• Regra 3: algoritmos complexos são lentos quando n é pequeno. Esse é o caso na maioria das vezes. Use algoritmos complexos apenas quando n costuma ser grande e, mesmo assim, aplique primeiro a Regra 2.
• Regra 4: algoritmos e estruturas de dados simples são preferíveis. São menos propensos a bugs e mais fáceis de implementar do que os complexos.
• Regra 5: a estrutura de dados correta é decisiva na programação. Se os dados estiverem bem organizados, o algoritmo se tornará óbvio.
• As regras 1 e 2 de Pike refletem o aforismo de Tony Hoare: "otimização prematura é a raiz de todo mal".
• Ken Thompson reformulou as regras 3 e 4 de Pike como: "na dúvida, use força bruta".
• As regras 3 e 4 implementam a filosofia de design KISS (Keep It Simple, Stupid).
• A Regra 5 está alinhada com uma observação de Fred Brooks em 'The Mythical Man-Month', muitas vezes resumida como "escreva código burro que use objetos inteligentes".

[GN⁺]

Comentários no Hacker News

• Artigo sobre as regras de programação de Rob Pike em 1989
• Os comentaristas concordam que o cerne da programação são as estruturas de dados, não os algoritmos
• Críticas ao fato de entrevistas com LeetCode não focarem mais em estruturas de dados do que em algoritmos
• Argumento de que algoritmos complexos são lentos quando n é pequeno, e que na maioria dos casos n é pequeno
• Os comentaristas enfatizam a importância de escolher estruturas de dados adequadas e manter tudo bem organizado
• Discussão sobre o mau uso de bancos de dados e o impacto negativo de esquemas de banco gerados por ORM
• As diretrizes parecem ser uma estratégia para evitar engenharia excessiva e otimização prematura
• Alguns comentaristas argumentam que pequenos desperdícios de desempenho podem se acumular e deixar o programa lento
• Debate sobre a citação "otimização prematura é a raiz de todo mal" e seu contexto
• Alguns comentaristas afirmam que bons programadores conseguem prever o que vai ficar lento e até fazer apostas instrutivas com antecedência
• Contra-argumento de que algoritmos complexos sobre dados simples podem trazer grandes ganhos de desempenho e até simplificar as coisas
• O artigo continua influenciando a forma como alguns leitores abordam design e complexidade
• Discussão sobre a interpretação da regra 5, com alguma discordância sobre a frase "escreva código burro que use objetos inteligentes"