L’excellent Jeff Atwood (de Stack Overflow) a rassemblé sur son blog quelques exemples de jargon de développeurs, ces expressions inventées qui collent parfaitement à une situation souvent rencontrée en développement. J’avais déjà twitté un article basé sur le même sujet il y a 2 ans, et j’aime bien découvrir de nouvelles expressions de ce type.
Voici mes cinq préférées.
1) Les conditions de Yoda
Utiliser if(constant == variable) au lieu de if(variable == constant), comme par exemple if(4 == foo). C’est comme dire « si bleu est le ciel » ou « si grand est le monsieur ».
2) Les accolades égyptiennes
Désignent des accolades écrites avec l’accolade ouvrante sur la même ligne que le bloc d’instruction, comme ceci :
if (a == b) {
alert("hello");
}
3) Bugfoot
Un bug qu’une seule personne a vu, et qui n’a jamais été revu depuis.
4) Moustache
Vu chez apgwoz, la moustache est tout simplement un petit nom pour désigner une accolade.
5) Bébé ours, Maman ours et Papa ours
Vu chez CSS-Tricks, c’est une autre façon de nommer les versions responsives d’un site.
// Papa ours
@media (max-width: 1600px) { }
// Maman ours
@media (max-width: 1250px) { }
// Bébé ours
@media (max-width: 650px) { }
Pauland, le
Pour le 1, dans ton exemple, c’est effectivement inutile, mais c’est surement le résultat d’une pratique pour les tests sur les chaines:
Si tu fais maChaine.equals(« toto ») et que maChaine est null >> Boom
par contre « toto ».equals(maChaine) >> Tranquille Emile
J’imagine donc que ceux qui écrivent ça comme ça, le fond par habitude.
teles, le
Non, le 1 permet d’éviter de faire une assertion si on oublie le 2e égal
if($var = 4) sera toujours vrai et ne générera pas d’erreur, tandis que if(4 = $var) oui car on ne peut rien affecter au chiffre 4
donc si tu mets toujours ta variable en 2e tu peux éviter de chercher pourquoi ton code est appelé à chaque fois, parce qu’écrire = au lieu de == ça arrive à tout le monde :)
teles, le
Ah oui, le 3 m’a fait explosé de rire :D
balbinus, le
Autre avantage : en faisant constante == variable, impossible de faire une assignation par erreur. constante = variable will raise an error.
Johan, le
@Pauland : C’est exactement mon cas, il m’arrive d’écrire le test à l’envers par habitude des NPEs…
Sinon, j’adore les variables ours ! :D
badprocess, le
Il manque le fameux:
var that = this;
;)
Pauland, le
@teles et @balbinus En effet, je n’avais pas pensé à ce cas là, mais là, c’est une erreur d’écriture, et ça se voit aussitôt à l’exécution (et du coup on le corrige aussitôt), contrairement au cas de la chaine (qui en théorie devrait être testée, on est d’accord) qui est très peu décelable.
Pauland, le
@teles Oublie mon dernier comment, j’ai dit de la merde ^^
Toxonit, le
if (a == b) {
alert(« hello »);
}
=>
if (a == b) {
alert(« hello »);
}
Merci ^^ Si on parle de bonnes pratiques … autant aller jusqu’au bout !
Toxonit, le
Oups sa ne prend pas en compte l’indentation ><
jcm, le
J’ai une horreur absolue de ceux qui ne pratiqueraient pas le « 2 » et écriraient :
if (a == b)
{
alert(« hello »);
}
et j’écris toujours :
if »ee »(« ee »a == b »ee ») « ee »{
« ind » alert(« hello »);
« ind » }
avec « ind » pour indentation et « ee » pour espace.
On voit facilement la différence sur un script de quelques centaines de lignes.
Car tout simplement avec quelques centaines de lignes on a un long scroll : autant le raccourcir de ce qui serait inutile à une bonne lisibilité.
Le « if » calé à gauche (et le reste indenté) permet de signaler sans aucune ambiguïté un bloc conditionnel et la présences d’espaces comme je les ai mentionnés permet de scinder chaque proposition en « mots » (morphèmes au sens sémantique du terme) et favoriser ainsi la lisibilité de l’ensemble (voir de nombreuses études sur la lisibilité et nos capacités cognitives).
C’est aussi la raison pour laquelle il faudra éviter (et même bannir) la camélisation chère aux informaticiens, qui sont en général des ignares absolus dans pas mal de domaines malheureusement…, et ont ainsi adopté une méthode de notation foncièrement contraire à nos capacités les plus communes, ce qui rend le travail de développeur parfois beaucoup plus pénible qu’il ne devrait l’être.
Voir à ce sujet : http://activart.com/intelliblug/index.php/2011/07/10/114-ecrire-du-php-lisible