Après, c'est une question d'habitude, j'ai fait sur un projet une RPP avec un américain, il a justifié de déroger aux règles de codage par : « Vous n'avez qu'à savoir codé ! »
En quoi il n'a pas tort, car finalement les règles de codage limite l'imagination et la compréhension du langage. Et nos experts restent des éternels débutants. D'un autre côté, quand tu passes 2mns à comprendre une ligne, c'est pas forcément très pérenne à long terme pour la reprise du code.
Exemples de perles rencontrées:
// Copie d'une chaine on s'assure que le dernier octets et bien un zéro si ça déborde...chardest[taille];strcpy(dest,src)[taille]='0円';// Dans un cas on apelle la fonction envoie_reseau et envoie_dbus dans l'autre.(a<b?envoie_reseau:envoie_dbus)(param1,param2);
Moi, j'aime pas. Le compilateur sait optimiser pour nous. Et les gens qui écrivent ça, c'est généralement avec l'excuse de la performance.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Anthony Jaguenaud . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 4.
Après, c'est une question d'habitude, j'ai fait sur un projet une RPP avec un américain, il a justifié de déroger aux règles de codage par : « Vous n'avez qu'à savoir codé ! »
En quoi il n'a pas tort, car finalement les règles de codage limite l'imagination et la compréhension du langage. Et nos experts restent des éternels débutants. D'un autre côté, quand tu passes 2mns à comprendre une ligne, c'est pas forcément très pérenne à long terme pour la reprise du code.
Exemples de perles rencontrées:
Moi, j'aime pas. Le compilateur sait optimiser pour nous. Et les gens qui écrivent ça, c'est généralement avec l'excuse de la performance.