Linux Attitude

Ce qui se conçoit bien s'énonce clairement !

Ya pas à dire, l'informatique, c'est comme la littérature.

Il y a les gens qui savent écrire et il y a les autres. Il y a les gens qui savent se faire comprendre du premier code source et il y a les autres.

Il est très important de savoir écrire correctement pour se faire bien comprendre. Tout comme il est plus facile de lire du Voltaire que du Kant, il est aussi plus facile de lire du source postfix que du source sendmail, plus facile de lire du source noyau que du source xorg.

Et ne parlons pas des rfc et autres howto. Il est plus facile de lire la RFC sur IP que la RFC sur punycode.

Les points à réfléchir lorsque vous écrivez :

• la prédictibilité : des noms de fonction, des types de paramètres, de l'ordre des paramètres
• la lisibilité : nommage ni trop court ni trop long, ni trop proche (si un seul caractère diffère entre 2 noms, les fonctions doivent être identiques à l'exception d'un paramètre par exemple)
• la mémorisabilité : découper son texte en concepts indépendants (l'orienté objet a fait beaucoup pour ça)
• la compréhensibilité : avoir des blocs suffisamment courts pour les lire et les comprendre dans leur globalité
• la visualisabilité : faites un schéma avant d'écrire, ça sera clair dans votre tête et donc dans celle du lecteur, si c'est trop dur, incluez votre schéma.

Avoir du style, ça se travaille, et ça nécessite de la réflexion, on ne jette pas une api sur l'écran au fil de l'eau. On écrit ce qu'on pense bien, on l'utilise, puis on constate les problèmes, on la refait, et on renomme toutes les fonctions pour respecter une certaine cohérence.

Bon, excusez-moi, cet article est un peu jeté en vrac comme ça et n'a pas vraiment de style.

Niveau :      
Résumé : C

Le C est plus lisible que le perl, la preuve le code C (test.c) suivant est valide :

%:include <stdio.h>
??=define T 2

int main(void)
??<
        int n<:T:>;

        n??(0??) = 1;
        if(n<:0??) == 1)
        <%
                n??(1:> = ??- n<:0:>;
        %> else
        <%
                n??(1??) = n<:0:> ??! 2;
        %>
        n??(0??) ??'= 3;

        printf( " n0 = %d ??/
                n1 = %d\n", n<:0:>, n<:1:> );

        return 0;
??>

Je le dis et je le prouve :

$ gcc -trigraphs test.c
$ ./a.out
 n0 = 2 		n1 = -2

Hé oui, le C contient quelques spécifications plus ou moins oubliées qui vous permettent ces bizarreries. Il s'agit en fait des trigraphs et des digraphs. Les premiers (3 caractères dont les 2 premiers sont des ?) ont été inventé pour palier un manque dans les tables de caractères pré ASCII (on me souffle qu'en fait c'est post ASCII), dont le petit nom est ISO 646. À l'époque de l'unicode ceci est toujours valable (par une option du compilateur il est vrai).

La deuxième série de caractère spéciaux (basée sur des <, >, % et :) a été introduite en 1999 ! Hé oui, la première écriture était trop peu lisible et devait être simplifiée ...

On peut ainsi créer un bug en C99 sans s'en rendre compte avant longtemps. Exemple :

int a;
a=1;
// Algo a la Kevin ?????????????????/
a++;

Exercice : Pour ceux qui suivent, trouvez la signification de chacun des groupes de caractères. Vous avez le droit à un gcc mais pas au web.

Un chercheur c'est quelqu'un à qui ont pose un problème hypothétique et qui passe sa vie (ou presque) à y chercher une solution. Pour cela il va lire le grand tableau noir des connaissances humaines, se creuse la tête et lorsqu'il trouve une solution il est heureux d'aller mettre son nom sur le grand tableau avec la solution du problème. Un chercheur travaille (du chapeau) autant la nuit que le jour et son boulot étant dans sa tête, il le rapporte toujours chez lui. Maintenant vous savez pourquoi ils sont autistes. Un chercheur est motivé par la reconnaissance reconnue grâce à des publications, il est en général moins bien payé qu'un étudiant chez macdo. Un chercheur a en général pour supérieur direct un chercheur qui a trouvé une solution et qui peut l'orienter dans sa quête du graal.

Un ingénieur c'est quelqu'un qui rencontre des problèmes pratiques et qui ne passe pas sa vie à en chercher la solution. Il va simplement réutiliser les résultats des chercheurs (qu'il est le seul a comprendre) et les appliquer à son cas particulier. Il sera ainsi heureux de savoir qu'il a contribué au bien être de l'humanité grâce à son mixer, sa fusée ou son épluche patate. Un ingénieur est en motivé par la reconnaissance, l'utilité de son travail et une paye plus élevée que celle de l'étudiant macdo. Un ingénieur a en général pour supérieur direct un ex ingénieur fatigué.

Un informaticien c'est quelqu'un qui se pose des problèmes qui pourraient survenir si Paris était en bouteille et qui va chercher à les résoudre. Pour cela il se pose la question à lui même et parfois à son ami google quand il est futé. N'ayant jamais entendu des mots comme "état de l'art", il finira par développer un nouvel outil qui ne sera utile qu'à lui-même. La reconnaissance qui le motive est a peu près la même que celle de l'étudiant macdo, ce qui explique le développement gigantesque du monde opensource ou il tentera de se faire un nom. Un informaticien a en général pour supérieur direct une personne qui a déjà envoyé un mail.

Maintenant une petit fable à raconter à vos amis.

On pose le même problème à un chercheur, un ingénieur et un informaticien, "Combien font 1+1 ?".

• Le chercheur se gratte la tête, sort ses axiomes et dit : "On suppose qu'on est dans Z, on peut prouver que +1 équivaut au successeur, 2 est le successeur de 1, donc 1+1=2".

• L'ingénieur montre du doigt le chercheur : "On est dans Z, je pique son résultat, ça fait 2".

• L'informaticien sort son cray, fait un programme qui fait la soustraction, la multiplication, la division et l'addition en virgule flottante sur n chiffres. Il lance le tout, tape 1+1 et le programme répond : "erreur, division par 0". Et donc l'informaticien demande un budget supplémentaire pour terminer un projet qui avait été mal estimé.

(Et pour ceux qui veulent la vraie démo, c'est dans les cours de second cycle)