Java sans joie

Il y a quelques années, j’ai sui­vi un cur­sus en infor­ma­tique, plus par­ti­cu­liè­re­ment orien­té vers la pro­gram­ma­tion. J’ai bifur­qué ensuite et ne touche plus à un code que très épi­so­di­que­ment (genre pour modi­fier le pré­sent blog) mais, du coup, quand j’ai besoin d’un mor­ceau de logi­ciel par­ti­cu­lier et que j’ai les outils pour le déve­lop­per, je peux me pen­cher sur la ques­tion et voir si je peux obte­nir moi-même le résul­tat vou­lu en un temps rai­son­nable. Et aus­si, du coup, j’aime bien quand j’en ai l’oc­ca­sion jeter un œil au code d’un pro­gramme, par curio­si­té — c’est un peu comme quand on a des notions de méca­nique et qu’on aime jeter un œil sous le capot d’une voi­ture pour voir com­ment c’est foutu.

Récem­ment, j’ai donc télé­char­gé et sur­vo­lé les sources de Pho­to­shop 1.0.1, gra­cieu­se­ment mises à dis­po­si­tion par le Com­pu­ter His­to­ry Museum. Je vais pas refaire l’ar­ticle, d’autres qui y ont pas­sé plus de temps que moi l’ont déjà dit, mais en bref : c’est propre. C’est prin­ci­pa­le­ment du Pas­cal, lan­gage que je n’ai que très indi­rec­te­ment fré­quen­té (il a des bouts de syn­taxe com­muns avec Ada, qu’on nous a fait bouf­fer dès notre entrée à l’IUT), mais à pre­mière vue, le code est bien struc­tu­ré, les dif­fé­rents fichiers bien iden­ti­fiés, l’in­ter­face est sépa­rée du cœur, chaque bout de pro­gramme a ses propres variables avec un nom­mage constant et seules les variables qui ont besoin d’être glo­bales le sont.

Il se trouve que, depuis quelque temps, je suis ame­né à adap­ter à mon usage un plug-in open source pour Ima­geJ (un outil de trai­te­ment d’i­mages), qui pour­rait bien me sim­pli­fier la vie. Et je rêve­rais qu’il soit écrit par les frères Knoll.

Voyez plu­tôt le début, juste après les appels de librai­ries. Note : c’est du Java.

Ce que vous voyez, c’est les (pre­mières) décla­ra­tions de variables glo­bales. Là-dedans, il y a des variables qui ont effec­ti­ve­ment de bonnes rai­sons d’être glo­bales, parce qu’elles sont uti­li­sées un peu par­tout dans dif­fé­rentes fonc­tions ; par exemple, les tableaux qui vont conte­nir les valeurs de pixels à traiter.

Mais il y a là des variables qui ne servent que très ponc­tuel­le­ment, dans quelques fonc­tions bien identifiées.

Par exemple, il n’y a qu’une seule et unique fonc­tion qui affiche des fenêtres : pour­quoi donc la chaîne ‘title’, qui n’est uti­li­sée que dans celle-ci, est-elle glo­bale ? Ah oui : parce qu’elle est ini­tia­li­sée dans une autre fonc­tion, au début du trai­te­ment de l’i­mage, mélan­geant ain­si moteur et car­ros­se­rie… Et je vous ras­sure : la fonc­tion qui affiche les fenêtres a bien accès à tous les élé­ments pour cal­cu­ler elle-même le titre à leur donner.

Pis, deux autres fonc­tions reçoivent une chaîne de même nom dans leurs para­mètres : dans celles-ci, un pro­gram­meur dis­trait pour­rait donc confondre la variable locale avec son homo­nyme globale.

Et vous savez ce que fait le boo­léen ‘can­cel’ ? Et bien, comme son nom l’in­dique, il est là pour mar­quer qu’il faut inter­rompre le pro­gramme, soit parce que l’u­ti­li­sa­teur l’a deman­dé, soit parce qu’une condi­tion d’exé­cu­tion n’est pas rem­plie. Il y a donc une série de fonc­tions qui véri­fient que tout va bien et, si elles trouvent un pro­blème, font un petit ‘can­cel = true; return;’, en lais­sant le soin au reste du pro­gramme de véri­fier s’il faut conti­nuer. Était-il com­pli­qué de faire comme tout le monde : uti­li­ser la valeur de retour de la fonc­tion (elles sont toutes de type ‘void’, donc elles pour­raient être ‘int’ ou ‘boo­lean’ sans gêner leur concep­tion) pour tes­ter la bonne exé­cu­tion d’un bout de code ? Plus lisible, plus simple, je ne vois pas quel incon­vé­nient ça pour­rait avoir…

Et je ne par­le­rai pas du fait que j’ai dû créer moi-même une fonc­tion pour lan­cer les cal­culs : les com­mandes néces­saires étaient inté­grées au construc­teur du plug-in et au ges­tion­naire d’é­vé­ne­ments, les pro­gram­meurs ini­tiaux n’ayant mani­fes­te­ment pas eu l’i­dée qu’un jour quel­qu’un vou­drait auto­ma­ti­ser une série d’o­pé­ra­tions successives.

Je ne suis pas un grand pro­gram­meur. En fait, il me faut sou­vent un bon moment pour com­prendre ce que mes pré­dé­ces­seurs ont vou­lu faire, parce que je n’ai pas (ou plus) une vision glo­bale et ins­tan­ta­née de ce qu’il se passe. J’ap­pré­cie donc par­ti­cu­liè­re­ment un code lisible, clair, qui n’u­ti­lise pas n’im­porte où une variable décla­rée 500 lignes plus haut juste parce que le pro­gram­meur a eu la flemme de se deman­der si elle ser­vi­rait ailleurs, et qui ne pré­pare pas l’af­fi­chage d’une fenêtre au fil de vingt opé­ra­tions dis­sé­mi­nées dans douze bouts de “back-end” au milieu de cal­culs vectoriels.

L’o­pen source, c’est bien, ça évite de ré-inven­ter la roue. Mais pitié : si vous faites de l’o­pen source, c’est que vous pen­sez que cer­tains auront envie de réuti­li­ser votre code. Pour­quoi leur com­pli­quer la vie ? Les bases sont simples : don­ner un nom clair à vos variables et vos fonc­tions, évi­ter les homo­nymes, faire une chose à la fois dans une fonc­tion don­née et sépa­rer ce qui est du pro­gramme pro­pre­ment dit de ce qui est de l’af­fi­chage et du contrôle d’exécution.

/*Ah, et un petit com­men­taire de temps en temps pour expli­quer ce qu’on a vou­lu faire, c’est pas mal non plus.*/

Et même vous, quand vous vou­drez faire évo­luer votre pro­gramme quelques années plus tard, vous vous ren­drez compte que ça vous faci­li­te­ra la vie.