{"id":1767,"date":"2014-04-21T11:06:19","date_gmt":"2014-04-21T10:06:19","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=1767"},"modified":"2014-04-25T10:53:44","modified_gmt":"2014-04-25T09:53:44","slug":"audit-application-legacy-c-microsoft-word-1-1a-2","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/audit-application-legacy-c-microsoft-word-1-1a-2\/","title":{"rendered":"Audit d\u2019une application Legacy en C \u2013 Microsoft Word 1.1a (II)"},"content":{"rendered":"

\"C_Analysis_Word2\"<\/a>Nous avons examin\u00e9\u00a0 dans le post pr\u00e9c\u00e9dent, les premiers r\u00e9sultats de l\u2019analyse du code source de Word 1.1a<\/a> (1990).<\/p>\n

Nous avons compt\u00e9 349 fichiers, ce qui n\u2019est pas \u00e9norme, mais avec une taille assez \u00e9lev\u00e9e : en moyenne plus de 470 LOC (Lines Of Code), et nombre d\u2019entre eux bien au-del\u00e0 des 1 000 LOC. Les m\u00e9triques de complexit\u00e9 sont \u00e9lev\u00e9es \u00e9galement, et le taux de commentaires assez bas, mais c\u2019\u00e9tait probablement normal \u00e0 l\u2019\u00e9poque, il y a plus de 40 ans.<\/p>\n

Le tr\u00e8s faible niveau de duplication am\u00e8ne \u00e0 penser que tous les composants n\u00e9cessaires \u00e0 l\u2019impl\u00e9mentation d\u2019une m\u00eame fonctionnalit\u00e9 se retrouvent dans un m\u00eame fichier, ce qui explique donc la taille et la complexit\u00e9 de nombre d\u2019entre eux. Il semble que le mot d\u2019ordre ait \u00e9t\u00e9 : priorit\u00e9 \u00e0 l\u2019efficacit\u00e9, au second plan la lisibilit\u00e9 et la compr\u00e9hension du code.\u00a0\u00a0\u00a0\u00a0 <\/p>\n

Qu\u2019en est-il maintenant du respect des bonnes pratiques de programmation ? C\u2019est ce que nous allons regarder dans ce second article.<\/p>\n

Respect des bonnes pratiques de programmation<\/h2>\n

Un coup d\u2019\u0153il au \u2018Treemap of Components\u2019 nous montre un niveau assez bas de respect des bonnes pratiques de programmation.<\/p>\n

\"C_Word_Trremap\"<\/a><\/p>\n

Les fichiers les plus nombreux et les plus complexes se trouvent dans le r\u00e9pertoire principal, et pr\u00e9sentent entre 20% et 50% de \u2018Rules compliance\u2019 dans la plupart des cas.<\/p>\n

\"C_Word_Trremap2\"<\/a><\/p>\n

Au total, plus de 40 000 \u2018Issues\u2019, la plupart de type \u2018Major\u2019 et une dette technique de plus de 1 200 jours.<\/p>\n

\"C_World_Issues\"<\/a><\/p>\n

Regardons maintenant quelles sont les r\u00e8gles enfreintes, par niveau de criticit\u00e9. Pour rappel, j\u2019ai utilis\u00e9 le Quality Profile par d\u00e9faut, \u00ab\u00a0out of the box\u00a0\u00bb comme disent les anglais, c\u2019est-\u00e0-dire pr\u00eates \u00e0 l\u2019emploi.<\/p>\n

Blockers<\/h3>\n

Aucune violation aux r\u00e8gles de type Blocker, c\u2019est ce que nous souhaitons voir dans toute application. Mais quelles sont exactement ces r\u00e8gles si bien respect\u00e9es ?<\/p>\n

\"C_Word_Blockers\"<\/a><\/h3>\n

La premi\u00e8re constitue une bonne pratique en mati\u00e8re de gestion des exceptions, en C++. Donc pas de surprise si elle est parfaitement respect\u00e9e ici : il n\u2019y a pas une seule instruction \u2018throw\u2019 dans toute l\u2019application.<\/p>\n

La seconde concerne l\u2019utilisation de trigraphs, dont je ne suis pas certain qu\u2019ils existaient \u00e0 l\u2019\u00e9poque. Je ne suis pas un sp\u00e9cialiste du langage C, mais il me semble que les trigraphs ont \u00e9t\u00e9 introduits par la norme C89, donc bien apr\u00e8s 1980. Quoiqu\u2019il en soit, au moins nous savons que nous ne rencontrerons pas de d\u00e9faut de ce type.<\/p>\n

Criticals<\/h3>\n

Nous rencontrons 753 d\u00e9fauts de type Critical, la plupart d\u2019entre eux concentr\u00e9s sur 2 r\u00e8gles.<\/p>\n

\"C_World_Crticals\"<\/a><\/p>\n

La premi\u00e8re concerne l\u2019utilisation de ‘goto’ afin d\u2019effectuer un \u2018jump\u2019, c\u2019est-\u00e0-dire d\u2019aller directement \u00e0 un endroit donn\u00e9 du code. Le \u2018goto\u2019 est devenu le symbole m\u00eame du code \u2018spaghetti\u2019 dont la logique algorithmique est difficilement compr\u00e9hensible, de par le nombre excessif de renvois dans tous les sens. Il n\u2019est pas toujours possible de s\u2019affranchir des \u2018gotos\u2019, mais il est souhaitable de disposer ceux-ci dans un m\u00eame bloc de code, pour plus de lisibilit\u00e9, et donc une meilleure fiabilit\u00e9 \u00e9galement.<\/p>\n

Ce sont surtout les sauts vers des portions de code imbriqu\u00e9s qui sont dangereux. Un goto vers un bloc de plus haut niveau reste plus lisible, sauf lorsque votre programme fait plus de 1 000 lignes et que le saut vous envoie quelques pages plus bas dans celui-ci. Difficile de comprendre ce que fait le code lorsque vous passez votre temps \u00e0 faire des allers-retours sur plusieurs pages. Il devient alors extr\u00eamement difficile d\u2019effectuer une modification sans introduire un bug. Les charges de maintenance et de tests en sont accrues.<\/p>\n

La deuxi\u00e8me r\u00e8gle signale l\u2019utilisation d\u2019op\u00e9rateurs logiques qui pr\u00e9sente un risque d\u2019effet de bord parce qu\u2019elle aboutit \u00e0 modifier une valeur autre que celle du code-retour, par exemple une variable globale, avec d\u2019impr\u00e9visibles cons\u00e9quences dans l\u2019ex\u00e9cution du programme.
\nA noter que les 335 occurrences rencontr\u00e9es dans le code ne sont pas forc\u00e9ment toutes des d\u00e9fauts, mais des violations potentielles.<\/p>\n

\"C_Word_Misra5_14-1\"<\/a><\/p>\n

Par exemple, dans le cas ci-dessus, si nous sommes s\u00fbrs que la fonction \u2018DocOpenStDof\u2019 ne modifie aucune valeur mais effectue une action comme par exemple, ouvrir un document Word, alors nous pourrions signaler qu\u2019il ne s\u2019agit pas en l\u2019esp\u00e8ce d\u2019un d\u00e9faut, et de ne plus prendre en compte cette occurrence dans les futures analyses.<\/p>\n

La troisi\u00e8me r\u00e8gle concerne l\u2019utilisation de constantes en octal, qui pr\u00e9sente un risque de confusion avec des valeurs enti\u00e8res. On n\u2019en compte pas \u00e9norm\u00e9ment ici, et si l\u2019on consid\u00e8re que certaines portions de code de MS-DOS ont \u00e9t\u00e9 r\u00e9utilis\u00e9es pour \u00e9crire cette version de Word, leur pr\u00e9sence n\u2019est pas tr\u00e8s surprenante.<\/p>\n

Major<\/h3>\n

Les violations aux r\u00e8gles \u2018Major\u2019 sont les plus nombreuses, de tr\u00e8s loin. Je ne vais pas toutes les d\u00e9tailler, mais simplement commenter bri\u00e8vement les plus notables.<\/p>\n

\"C_Word_Majors1\"<\/a><\/p>\n

La r\u00e8gle la plus enfreinte (plus de 9 000 violations) concerne l\u2019utilisation d\u2019accolades dans les traitements de type If-Else. En fait, l\u2019examen du code montre que celles-ci ne sont pas employ\u00e9es lorsque le If ou le Else ne compte que tr\u00e8s peu de lignes, comme par exemple un simple \u2018return\u2019 ou \u2018goto\u2019. Donc cette absence d\u2019accolades n\u2019est pas r\u00e9ellement significative d\u2019un manque de lisibilit\u00e9 du code, puis que l\u2019esprit de la r\u00e8gle est globalement respect\u00e9. Le probl\u00e8me est que cela cr\u00e9e des exceptions dangereuses, que l\u2019on peut d\u2019ailleurs constater dans le code : \u00e0 partir de combien de lignes sans accolades le programme devient-il moins compr\u00e9hensible ?<\/p>\n

Je sortirais tr\u00e8s probablement du Quality Profile la deuxi\u00e8me r\u00e8gle concernant les r\u00e8gles de nommage, comme c\u2019est fr\u00e9quemment le cas en mati\u00e8re de \u2018naming conventions\u2019 : que celles-ci ne soient pas respect\u00e9es ne signifie pas qu\u2019elles n\u2019existent pas. Et puis, j\u2019ai tendance \u00e0 ranger celles-ci dans la cat\u00e9gorie \u2018Minor\u2019.<\/p>\n

Les syntaxes de types K&R (Kernighan & Richie) sont obsol\u00e8tes de nos jours, car consid\u00e9r\u00e9es peu lisibles, mais ne l\u2019\u00e9taient au d\u00e9but des 80\u2019s.<\/p>\n

La plupart des autres violations de type Major vont impacter \u00e9galement la lisibilit\u00e9 et la compr\u00e9hension du code, comme on peut le voir ci-dessous.<\/p>\n

\"C_Word_Majors2\"<\/a><\/p>\n

J\u2019ai configur\u00e9 ce widget afin d\u2019afficher les r\u00e8gles Major par nombre de d\u00e9fauts. La grande majorit\u00e9 sont des bonnes pratiques de programmation selon lesquelles \u00e9viter des traitements trop longs, comme \u2018Switch cases should not have too many lines\u2019 ou \u2018Function\/methods should not have too\u00a0 many lines\u2019, des fonctions trop complexes (\u2018Avoid too complex function\u2019 pour les fonctions comptant plus de 20 points de Cyclomatic Complexity), des r\u00e8gles de nommage (\u2018Literal suffixes shall be upper case\u2019), etc.<\/p>\n

Il y a en fait tr\u00e8s peu de d\u00e9faut Major qui soient susceptibles d\u2019impacter la fiabilit\u00e9 et la robustesse de l\u2019application, toutes proportions gard\u00e9es bien \u00e9videmment.<\/p>\n

Minor<\/h3>\n

Il en va d\u2019ailleurs de m\u00eame pour les r\u00e8gles de type Minor, celles-ci \u00e9tant toutefois en nombre moins importants.<\/p>\n

\"C_Analysis_Word_Minors\"<\/a><\/p>\n

L’analyse des ‘Issues’ rencontr\u00e9es dans le code de cette premi\u00e8re version de World confirme nos impressions initiales <\/a>: tout semble indiquer que les priorit\u00e9s ont port\u00e9es sur l’efficacit\u00e9 et la fiabilit\u00e9, puisque les violations de ce type sont les moins nombreuses. Par contre, les infractions aux bonnes pratiques en mati\u00e8re de maintenabilit\u00e9 et d’\u00e9volutivit\u00e9 du code constituent la grande majorit\u00e9 des ‘Issues’ constat\u00e9es, ce qui explique la Technical Debt tr\u00e8s importante pour une premi\u00e8re version d’application.<\/p>\n

Il y a certes quelques r\u00e8gles, comme celles de ‘Naming Conventions’ par exemple, que l’on pourrait d\u00e9sactiver. Je n\u2019ai pas voulu modifier le Quality Profile par d\u00e9faut pour effectuer l\u2019analyse de ce code, mais il aurait s\u00fbrement fallu l\u2019adapter aux caract\u00e9ristiques d\u2019une application C \u2018Legacy\u2019 telle que celle-ci.<\/p>\n

N\u00e9anmoins, nous verrons dans le prochain post qu\u2019il peut exister certains cas dans lesquels il vaut mieux d\u00e9marrer notre \u00e9valuation en proc\u00e9dant de cette mani\u00e8re.<\/p>\n","protected":false},"excerpt":{"rendered":"

Nous avons examin\u00e9\u00a0 dans le post pr\u00e9c\u00e9dent, les premiers r\u00e9sultats de l\u2019analyse du code source de Word 1.1a (1990). Nous avons compt\u00e9 349 fichiers, ce qui n\u2019est pas \u00e9norme, mais avec une taille assez \u00e9lev\u00e9e : en moyenne plus de 470 LOC (Lines Of Code), et nombre d\u2019entre eux bien au-del\u00e0 des 1 000 LOC. […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1767","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/1767"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=1767"}],"version-history":[{"count":35,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/1767\/revisions"}],"predecessor-version":[{"id":1812,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/1767\/revisions\/1812"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=1767"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=1767"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=1767"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}