Justement, le fait de mettre son nez dans le noyau linux devrait, au contraire, inciter les gens à coder de manière beaucoup plus stricte...Envoyé par InOCamlWeTrust
Le but des jalons posés par les différentes regles de codage est multiple:
Assurer la pérénité du code: un code écrit aujourd'hui, dans le cadre de la NASA pourrait n'être utilisé en conditions réelles que dans 20 ou 30 ans: dix avant meme que la sonde qui l'utilise ne se retrouve dans le nez d'une fusée et dix ou vingt avant que la sonde n'atteigne l'endroit qu'elle est supposée étudier... Et se retrouver au fond d'un coffre (ou sur une bande de sauvegarde quelconque) pendant tout ce temps...
Mais, dans vingt ou trente ans, le programmeur qui a écrit le code sera soit occupé sur un autre projet, soit pensionné, s'il n'a pas été viré et qu'il ne s'est pas fait renverser par une voiture...
Si, pour une raison ou une autre, il faut modifier ce code, il faut que celui qui aura à le modifier préfère apporter des changements au code existant au fait de le réécrire entièrement à sa main.
Pour atteindre cette pérénité du code, il faut que le type qui lit le code pour la première fois soit en mesure de déterminer précisément
- le but du code
- la logique qu'il est sensé suivre
- la manière dont la logique a été implémentée
- les dépendances éventuelles par rapport à d'autres modules/fonctions/valeurs
- d'autres choses auxquelles je n'ai peut etre pas pensé
De ce seul point de vue, et bien que je lui reconnaisse de tres grandes qualités, le noyau linux, qui n'a qu'une vingtaine d'années, ne peut pas vraiment se prévaloir d'une pérénité à toutes épreuves, avec ses deux versions principales et son nombre incroyable de sous versions (sans meme prendre en compte les bugfixes)...
Fatalement, essayer d'apporter un maximum de sécurité au niveau de l'allocation et de la libération des ressources: il est préférable d'éviter que le système ne plante apres cinq ans de "navigation" alors qu'il faudra dix ou quinze années supplémentaires pour atteindre le but
Assurer la sécurité des données elles-mêmes: l'espace est un millieu hostile, et certains rayonnements ou champs magnétiques sont susceptible de modifier les données.
Il faut donc impérativement pouvoir etre en mesure de récupérer les données d'une manière ou d'une autre...
Assurer un minimum de sécurisation lors de l'utilisation meme des données: Du fait qu'on a conscience que les données risquent d'être corrompues, il semble logique de prévoir un moyen de vérifier si elles l'ont été ou non avant d'essayer de les utiliser... Quelle que puisse etre leur origine.
Il y a sans doute d'autres points génériques importants auxquels une application spaciale devra etre attentive, mais, sur base de ces quatre seuls points, qui seraient à la limite à appliquer meme dans la "programmation de tous les jours", il y a déjà largement de quoi édicter une grosse vingtaine de regles à appliquer
Maintenant, il reste toujours le sujet de la "rigidité" des regles: certaines sont impératives (obligations/interdictions), d'autres nécessitent une sérieuse justification si elles ne sont pas suivies, et d'autres enfin peuvent n'etre que des conseils d'ordre pratique
Mais c'est comme les lois: dans tous les pays on te dit "tu ne tueras point"... Mais tous les pays acceptent l'idée que tu tues le type qui fonce vers toi avec un poigngard dans la seule idée de te l'enfoncer dans le coeur (la légitime défence, comme on dit )
Partager