icarofreire · October 15, 2024 23:19
diff --git a/gistfile1.txt b/gistfile1.txt
 Rob Pike ofereceu as seguintes "regras" em Notas para programação em C como máximas da programação de computadores, embora elas possam ser vistas como pontos da filosofia Unix:

 	•	Regra 1: Você não pode dizer qual trecho de um programa é lento. Os gargalos ocorrem em locais que surpreendem, portanto, não tente supor e determinar uma solução até que tenha determinado exatamente onde se encontra o gargalo.
 	•	Regra 2: Meça. Não otimize o programa até que você tenha medido o seu tempo de execução, e mesmo depois de medido o tempo, não otimize a menos que uma parte do código esteja gastando muito mais tempo em comparação com o restante do programa.
 	•	Regra 3: Algoritmos extravagantes são lentos quando  é pequeno, e  é normalmente pequeno. Algoritmos extravagantes têm grandes constantes. Até que você saiba que  torna-se freqüentemente grande, não seja extravagante. (Mesmo se  tornar-se grande, use a Regra 2 primeiro.)
 	•	Regra 4: Algoritmos extravagantes contém mais defeitos que algoritmos simples e são mais difíceis de implementar. Utilize algoritmos simples assim comoestrutura de dados simples.
 	•	Regra 5: O dado domina. Se você escolher a estrutura de dados certa e organizar bem as coisas, os algoritmos surgirão naturalmente. O elemento central da programação é a estrutura de dados, não o algoritmo.
 	•	Regra 6: Não existe Regra 6.
 	
 As regras 1 e 2 de Pike, reforçam a famosa máxima de Tony Hoare: "A otimização prematura é a raiz de todo mal." Ken Thompson reescreveu as regras 3 e 4 da seguinte forma: "Quando em dúvida, use força bruta." As regras 3 e 4 são exemplos da filosofia de projeto KISS. A regra 5 foi colocada anteriormente por Fred Brooksno livro The Mythical Man-Month. A regra 5 é freqüentemente resumida como: "escreva um código burro que use uma estrutura de dados inteligente", e é um exemplo da norma "Se a sua estrutura de dados é boa o bastante, o algoritmo para manipulá-la deverá ser trivial."
	Rob Pike ofereceu as seguintes "regras" em Notas para programação em C como máximas da programação de computadores, embora elas possam ser vistas como pontos da filosofia Unix:

	• Regra 1: Você não pode dizer qual trecho de um programa é lento. Os gargalos ocorrem em locais que surpreendem, portanto, não tente supor e determinar uma solução até que tenha determinado exatamente onde se encontra o gargalo.
	• Regra 2: Meça. Não otimize o programa até que você tenha medido o seu tempo de execução, e mesmo depois de medido o tempo, não otimize a menos que uma parte do código esteja gastando muito mais tempo em comparação com o restante do programa.
	• Regra 3: Algoritmos extravagantes são lentos quando é pequeno, e é normalmente pequeno. Algoritmos extravagantes têm grandes constantes. Até que você saiba que torna-se freqüentemente grande, não seja extravagante. (Mesmo se tornar-se grande, use a Regra 2 primeiro.)
	• Regra 4: Algoritmos extravagantes contém mais defeitos que algoritmos simples e são mais difíceis de implementar. Utilize algoritmos simples assim comoestrutura de dados simples.
	• Regra 5: O dado domina. Se você escolher a estrutura de dados certa e organizar bem as coisas, os algoritmos surgirão naturalmente. O elemento central da programação é a estrutura de dados, não o algoritmo.
	• Regra 6: Não existe Regra 6.

	As regras 1 e 2 de Pike, reforçam a famosa máxima de Tony Hoare: "A otimização prematura é a raiz de todo mal." Ken Thompson reescreveu as regras 3 e 4 da seguinte forma: "Quando em dúvida, use força bruta." As regras 3 e 4 são exemplos da filosofia de projeto KISS. A regra 5 foi colocada anteriormente por Fred Brooksno livro The Mythical Man-Month. A regra 5 é freqüentemente resumida como: "escreva um código burro que use uma estrutura de dados inteligente", e é um exemplo da norma "Se a sua estrutura de dados é boa o bastante, o algoritmo para manipulá-la deverá ser trivial."