Les règles de programmation de Rob Pike (1989)

• Article sur les cinq règles de programmation de Rob Pike en 1989
• Règle 1 : ne supposez pas où un programme passera l’essentiel de son temps ; les goulets d’étranglement peuvent apparaître de manière inattendue. Évitez les hacks de performance tant qu’un goulot d’étranglement n’a pas été démontré.
• Règle 2 : mesurez toujours avant d’optimiser pour la vitesse. N’optimisez que si une partie du code a un impact significatif sur le reste.
• Règle 3 : quand n est petit, les algorithmes complexes sont lents. C’est le cas la plupart du temps. N’utilisez des algorithmes complexes que si n est souvent grand, et même dans ce cas, appliquez d’abord la règle 2.
• Règle 4 : les algorithmes simples et les structures de données simples sont préférables. Ils sont moins sujets aux bugs que les solutions complexes et plus faciles à implémenter.
• Règle 5 : la bonne structure de données est décisive en programmation. Si les données sont bien organisées, l’algorithme deviendra évident.
• Les règles 1 et 2 de Pike reflètent la maxime de Tony Hoare : « l’optimisation prématurée est la racine de tous les maux ».
• Ken Thompson a reformulé les règles 3 et 4 de Pike ainsi : « dans le doute, utilisez la force brute ».
• Les règles 3 et 4 mettent en pratique la philosophie de conception KISS (Keep It Simple, Stupid).
• La règle 5 est cohérente avec une remarque de Fred Brooks dans The Mythical Man-Month, souvent résumée par : « écrivez du code stupide qui utilise des objets intelligents ».

[GN⁺]

Avis sur Hacker News

• Article sur les règles de programmation de Rob Pike en 1989
• Les commentateurs s’accordent à dire que le cœur de la programmation, ce sont les structures de données plutôt que les algorithmes
• Critiques sur le fait que les entretiens LeetCode ne se concentrent pas sur les structures de données plutôt que sur les algorithmes
• Argument selon lequel des algorithmes complexes sont lents quand n est petit, et que dans la plupart des cas n est petit
• Les commentateurs soulignent l’importance de choisir des structures de données adaptées et de bien organiser les choses
• Discussion sur le mauvais usage des bases de données et l’impact négatif des schémas de base générés par les ORM
• Ces lignes directrices semblent être une stratégie pour éviter le sur-engineering et l’optimisation prématurée
• Certains commentateurs soutiennent qu’un petit gaspillage de performance peut s’accumuler et ralentir un programme
• Débat autour de la citation « l’optimisation prématurée est la racine de tous les maux » et de son contexte
• Certains commentateurs affirment que les bons programmeurs peuvent prévoir ce qui deviendra lent et faire à l’avance des paris instructifs
• Objection selon laquelle des algorithmes complexes appliqués à des données simples peuvent apporter de gros gains de performance et même simplifier les choses
• L’article a eu une influence durable sur l’approche du design et de la complexité chez certains lecteurs
• Discussion sur l’interprétation de la règle 5, avec certains désaccords autour de la formule « écrivez du code stupide qui utilise des objets intelligents »