Commentaires : Contraint de communiquer un code source, l'État l'envoie… sur du papier

education
opendata
opensource
Tags: #<Tag:0x00007f3d25c28238> #<Tag:0x00007f3d25c280f8> #<Tag:0x00007f3d25c27f40>

#22
  • ah ben moi je trouve taquin et très amusant de leur part. Surtout que ça ne fait que 20 pages.
  • Vous nous emmerdez à vouloir le code source et à jeter la suspicion sur nous, et bien voilà le code... hahahah il est pas obligé d'être qualité hein ? :sunglasses:
  • j'ai fait perso la même chose avec un gugusse qui voulait récuperer mon projet de stage et qui était un vrai con : code source papier, j'enlève tous les com' et je renomme les variables avec des noms atroces...

#23
  • je vois du tout ce qui cloche ??
  • au contraire c'est bien de mélanger 2 langues dans un source. Par exemple obligatoirement les mot clé du langage sont en anglais, donc déja les variables en français ça aide la lisibilité. Ensuite les commentaires... ce serait totalement idiot de commenter le code en anglais pour un site de l'EN ! mais le terme TODO est universellement connu... c'est comme Weekend.

#24
  • je ne connais pas ce langage, mais il n’est jamais inutile de forcer un cast inutile, ça montre juste que l’auteur contrôle ce qu’il fait, ça aide à la lisibilité, c’est explicite.
  • LA plaie d’un code source c’est tout ce qui se passe de manière non-explicite.

#25
  • ça a été evidemment obsfusqué.

#26

Il y a mille raisons pour lesquelles rédiger son code en français est une mauvaise pratique.

Première, quand vous faites cela vous ne pouvez plus faire travailler de développeur étranger dessus. Ce qui peut-être très utilile (si un expert oracle américain vient faire un audit par exemple, il aura l'air bien con avec des variables françaises).

Deuxièmement ça n'aide absolument pas à la lisibilité. Prenont le cas des setters.

Si vous avez une variable nommé "maison", son setter sera "setMaison". On se retrouve donc avec une fonction dont le nom est à moitié en anglais, à moitié en français.


#27

"setMaison" c'est beaucoup moins ambigu que "setHome".


#28
  • bof, c'est déja vachement plus facile de la lire Maison que lire g_LstrCZm comme ça se fait chez les ricains.
  • et alors? c'est justement très clair, on sait immédiatement que c'est un setter perso et non pas une fonction d'une bibliothèque.

  • le seul problème avant c'était les caractères accentués français dans les com', le français en ascii c'est vraiment dégueux. C'est fini maintenant avec unicode, on peut.


#29

Grosse erreur !
Justement vous n’avez pas à savoir si c’est un setter ou non.

En programmation orienté objet les méthodes doivent faire abstraction de leur fonctionnement interne.


#30

Le but du jeu n'est pas d'écrire une pièce de Shakespeare.
Cela n'a strictement aucune importance.

Et alors ?

Je préfère largement qu'un développeur écrive function CalculerInteretsComposes () plutôt qu'il m'invente un function ComputeComposedInterest()

Et de même, je trouve 1000 fois plus compréhensible une conception orientée objet avec des classes nommée Client, Facture, Devis.

C'est d'ailleurs pour ça qu'on a des setters et des getters ? Parce que dans le genre méthodes dont le nom indique le fonctionnement interne, il n'y a guère mieux, non ? Tu as même des langages où tu n'a même pas la peine de les écrire explicitement tellement leur syntaxe est standardisée.


#31
  • euh… si ça commence par set_ , c’est un setter, non ?
  • mouais, en quoi setMaison ça décrit le fonctionnement interne, par rapport à setHome ?

#32

Tout à fait c'est pour ça que l'on préférera "setHouse" :stuck_out_tongue:


#33

Les experts d’Oracle France parlent parfaitement le français puisqu’ils sont français. Et si tu as besoin de faire venir un expert Oracle des USA, ce n’est sûrement pas pour debugger une procédure PL/SQL.


#34

Une fois, je suis tombé sur un programmeur qui appelait ses variables du nom des personnages de Walt Disney.
Du style
/* calculer le TTC en additionnant le HT et la TVA */
Mickey = Donald + Pluto

Autant dire qu'il n'a pas terminé sa période d'essai...


#35

D'un point de vue pratique, y'a même largement plus de "chance" de devoir faire appel à un développeur français qui maitrise pas l'anglais, qu'à un développeur étranger maitrisant pas le français....


#36

Jamais vu un bout de PL aussi illisible.


#37

Haha je comprends tout à fait. Pour savoir si je peux travailler avec un développeur je regarde 2 choses particulièrement :

  • Les noms de ses variables / classes / methodes : si je ne comprends pas à quoi elles servent du premier coup d’oeil c’est pas bon
  • La logique de ces instructions, par exemple je hais par dessus tout
    if(false) { //not correct } else { //correct }
    Je lis ça comme “si non sinon oui”

#38

J'ai été assez "surpris" d'un :
a
b
c
...

Ou encore un gars qui s’était amusé a redéfinir des variable PASOK OK pour false true , en inversant les codes numériques (0 / 1)
:smiley:


#39

Même si la modélisation objet est en principe destinée au développeur, c'est quand même aussi un moyen de communication avec le client utilisateur. Tu lui montres un schéma qui explique comment les objets Devis, Facture, Client, ... s'articulent entre eux et quelles sont les propriétés associées (dateFacture, montantHT, montantTTC, ..).
Si tu as tout traduit en (pseudo)anglais, ça va être un peu moins évident de communiquer.


#40

C'est quand même le gars qui vient reprocher de mélanger du français et de l'anglais qui écrit "son setter sera...". :joy:


#41

Surtout que accesseur et mutateur, ça en jette quand même vachement plus qu'un getter ou setter :dagger: