Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

L’ART DE PROGRAMMER 1 6 L’art de programmer1 « Il n’y a pas de règles immuables

L’ART DE PROGRAMMER 1 6 L’art de programmer1 « Il n’y a pas de règles immuables à suivre pour écrire un programme logique, efficace et lisible. Il y a bien sûr des guides, et certains sont meilleurs que d’autres; mais c’est le style du programmeur (ou son absence de style), sa clairvoyance (ou non), sa créativité (ou son absence) qui déterminent la qualité du produit final. » Peter J. Denning, ACM Computing Surveys, Volume 6, décembre 1974. Le travail d’un programmeur consiste à trouver des solutions informatiques pour des problèmes particuliers et à les mettre en place sous forme de programmes. L’apprenti programmeur doit reconnaître l’importance d’avoir un style à son art, la programmation. Il doit développer très tôt des habitudes de réflexion et de rédaction qui le suivront constamment au cours de sa vie professionnelle. On dit qu’une bonne connaissance des règles de la grammaire n’est pas une garantie de succès pour un écrivain; aussi, la connaissance approfondie des guides de programmation ne sera pas non plus une garantie d’un style de programmation apprécié. Ce chapitre tentera d’y remédier. 6-1 L’IMPORTANCE DU STYLE Les gens en création, comme les artistes, les compositeurs, les écrivains et les architectes travaillent beaucoup pendant leur apprentissage pour maîtriser les fondements de leur art. Ils développent alors un style qui leur est unique et personnel. Leur succès artistique et commercial dépend de ce style, car dans un milieu compétitif, seuls ceux dont le style plaît et est reconnu sont en demande. 1. Extrait de Logique de programmation : initiation à l’approche algorithmique, chapitre 6, Jean-Paul Tremblay, Richard B. Bunt et Paul G. Sorenson, McGraw-Hill Éditeur, 1985, p. 297-336. 23 mars 2017 2 LOGIQUE DE PROGRAMMATION Dans tous les domaines et selon les circonstances, il y a des styles plus appropriés que d’autres. Par exemple, certains styles de musique ou vêtements sont plus recherchés que d’autres et souvent par des gens différents. Un style d’écriture particulier facilite une meilleure communication des idées, alors qu’un autre est plus approprié pour la description de détails techniques. Certains styles architecturaux sont plus appropriés que d’autres selon le climat. Nous verrons au cours de ce chapitre, qu’en programmation le style qu’on adopte a des conséquences certaines sur la valeur des programmes qu’on écrit. Les considérations de style sont indépendantes des stan- dards professionnels et contribuent à l’amélioration de la qualité des programmes. Des recherches ont démontré que certaines pratiques stylistiques aident à réduire le nombre d’erreurs produites durant le développement d’un programme. En même temps, le programme devient plus lisible et compréhensible aux yeux des autres pro- grammeurs qui seront possiblement appelés à modifier ce programme (comme vous serez appelé à modifier celui d’un collègue qui est absent ou qui a quitté). La maintenance de programmes, c’est-à-dire, l’entretien de programmes existants (que ce soit pour en corriger des lacunes ou pour les adapter à un environnement chan- geant), occupe une portion importante du temps des programmeurs professionnels. Il n’est pas rare de voir qu’effectivement, on consacre plus de temps à la maintenance qu’au développement original. Il ne faut donc pas être surpris de constater l’intérêt des programmeurs et de la direction envers les techniques d’amélioration de l’analyse et de la programmation pour réduire la portion de temps affecté à l’entretien. Tous préfèrent en général consacrer ce temps précieux à de nouveaux développements. Un bon style de programmation contribue indéniablement au succès professionnel d’un programmeur. La reconnaissance de ce succès est très tangible ($$$), mais comme dans toutes les disciplines, il est bon de ne jamais se laisser aller. Nous étudierons donc dans ce chapitre plusieurs points importants de la programmation stylisée. Nous espérons ainsi stimuler l’intérêt du lecteur tout en lui présentant la démarche à suivre en situation de réalisation informatique. Au cours de l’étude de ce processus, nous en examinerons les pièges et comment il faut les contourner. 6-2 QUALITÉ D’UN PROGRAMME Avant de nous aventurer trop profondément dans l’étude des méthodes d’amélioration d’un programme, peut-être devrions-nous définir ce qui est recherché. Le concept d’un bon programme est bien sûr difficile à saisir. Si l’on pose la question aux programmeurs professionnels et à leurs supérieurs, la gamme des réponses est surprenante; elle est matière de goût et basée sur l’expérience de chacun. Mais ils s’entendront tous sur un certain nombre de points communs. En voici quelques-uns : L’ART DE PROGRAMMER 3 Bon fonctionnement d’un programme Le bon fonctionnement d’un programme est l’aspect le plus important et qu’il ne faut jamais perdre de vue. Cela semble évident! Et pourtant c’est le point le plus difficile à garantir. Les journaux et les revues spécialisées sont remplis d’histoires de programmations catastrophiques et dispendieuses. Bien sûr, de tels incidents ne représen- tent qu’une faible proportion de tous les programmes écrits, mais ils perturbent le milieu professionnel informa- tique et sont en partie responsables de la méfiance et de l’aversion du grand public en général, et des petites compagnies en particulier. Le programmeur doit s’assurer aussi que le programme éventuellement mis en place répondra aux spéci- fications requises. Il est très facile de se perdre dans des détails et en conséquence, de perdre de vue le but premier du programme. Solutionner en partie un problème posé ne satisfait pas le client et risque de lui faire plus de tort que de bien. Il est important de revoir continuellement les spécifications (qui sont d’ailleurs sujettes à des changements) tout au cours des phases d’analyse et de développement; on se méfiera des spécifications erronées, incomplètes ou incomprises. Il ne faut pas non plus embellir un système de caractéristiques non requi- ses (même si l’on a eu du plaisir à les programmer); elles sont susceptibles de tomber éventuellement en panne et de créer du temps de maintenance, ou même d’embêter carrément un confrère qui examine le programme et de lui faire perdre son temps (et sa patience). Absence d’erreurs Trop de programmeurs considèrent que les erreurs de programmation sont humaines et qu’un programme est voué à un entretien éternel. Il n’y a aucune raison logique à cela. On a beau dire que les erreurs germent comme des champignons dans la nuit, en fait, le programmeur est le seul responsable, par négligence ou manque de compréhension, des spécifications et des particularités du langage ou de l’ordinateur, ou simplement par l’oubli d’un cas particulier qui était possible (ou même impossible) et qui s’est présenté à un moment donné. Bien sûr, le programmeur ne le fait pas délibérément (peu adorent provoquer les erreurs), mais elles peuvent être évitées pour la plupart. Bestougeff (1975) et Arsac (1977) parlent de techniques d’écriture de programmes sans erreurs à l’aide d’une écriture simple et récurrente des algorithmes. On a fait beaucoup de recherches en informatique pour trouver des modèles mathématiques formels qui assurent l’exactitude d’un algorithme. Si ces preuves sont toujours possibles, elles n’en sont pas moins souvent ardues, longues et rarement pratiques dans l’industrie. Puisque le programmeur est responsable dans tous les cas de ses erreurs de programmation, il doit avoir recours à d’autres techniques pour s’assurer de l’exactitude de son programme (par exemple, à l’aide de tests appro- priés). Nous en reparlerons dans la prochaine section. Bonne documentation La documentation d’un programme est là pour aider à comprendre et à modifier un programme, et est à ce titre, une partie importante de la programmation; il ne faut pas la négliger. La documentation s’avère utile non seule- ment pour ceux qui ont à comprendre et à modifier un programme, mais également pour l’auteur. Beaucoup de programmeurs travaillent concurremment sur plusieurs projets, donc sur de nombreux programmes ou sections de programmes (plus, peut-être, un peu de maintenance impromptue et urgente) et peuvent oublier facilement où ils en étaient rendus. Ils mélangent tout, surtout s’ils n’ont pas documenté convenablement les programmes au fur et à mesure de leur écriture. 4 LOGIQUE DE PROGRAMMATION Il existe deux formes de documentation : la documentation externe qui consiste en documents d’utilisation pour l’usager, de présentation du problème posé, de l’analyse, des algorithmes, des diagrammes, des program- mes, etc. La documentation interne est constituée des commentaires et des explications que l’on retrouve dans les algorithmes et programmes. On ne peut pas trop insister sur l’importance de cette dernière documentation qui, avec les instructions mêmes, sont indispensables à quiconque doit examiner le corps d’un programme. Les instructions constituent la première partie de la documentation interne et voilà pourquoi on insiste sur une écriture soignée des programmes. La documentation externe s’adresse souvent davantage aux supérieurs ou à l’usager qui ne savent que faire d’un imprimé du(des) programme(s), mais qui aiment bien voir la structure du système qu’on leur propose. Elle est également destinée au collègue qui doit fouiller dans un système informa- tisé pour y localiser un module à modifier. Efficacité La question d’efficacité est épineuse. Au début de l’ère informatique, les ordinateurs étaient lents, limités et dispendieux; les programmes devaient être construits minutieusement pour maximiser l’emploi de ressources peu abondantes, telles l’espace mémoire et le temps d’exécution. Les programmeurs consacraient de longues heures à minimiser le temps d’exécution (sauver uploads/s3/ art-programmer.pdf