Vos petites manies de développeurs

Les petites choses dont vous ne vous pouvez vous passez lorsque vous vous trouvez dans un éditeur de texte, un gestionnaire de versions...

a marqué ce sujet comme résolu.

Le latin est mort. Il n'y a plus aucun peuple dont c'est la langue maternelle, et qui l'utilise assez pour la faire vivre et évoluer (pour y ajouter des mots utiles, tels que téléphone).

Et on s'en fiche que untel ait défendu l'esperanto. On a une norme de facto, l'Anglais, on l'applique pour être compatible, ou on s'ostracise. La seule alternative, c'est d'être assez nombreux à utiliser une nouvelle norme pour la légitimer. L'Allemand en électronique s'est tenu un temps, aujourd'hui, c'est le Chinois (le mandarin, je pense), et ça ne marche que parce que le travail est fait en double, en anglais et en chinois. Mais si tu es seul à lutter, tu as perdu, et je ne vais pas m'amuser à dupliquer mes codes en Français et en Anglais pour te suivre.

Natalya

C'est bien c'est bien. On a une norme. On l'applique. On a une majorité, elle définit la vérité, la norme. On s'en fiche d'avoir des intellectuels sauf pour les laisser penser à notre place, mais faudrait pas ne pas être pragmatique ni les écouter.

Les normes se font et se défont avec la volonté des gens à priori. Partir d'un constat du type on a une norme de facto c'est rejeter le fait qu'historiquement c'est faux. Et donc, c'est un raisonnement qui est faux.

+0 -0

Je vous invite à ouvrir un autre sujet, les zamis. J'ai pas envie de voir ce sujet partir en vrille et de devoir masquer des messages (c'est moche et nuisible à la lecture).

Par ailleurs, vu qu'une certaine Mme. Tension semble pointer sa frimousse, je vous invite à prendre un bol d'air avant de poster (oui à 2h du mat', le froid a de belles propriétés, vous verrez :P ).

+6 -0

Coucou,

Après une courte page de HS, on revient dans le sujet. Je ne suis pas encore pro donc j'ai des chances de me faire incendier mais bon. Voici mes petites manies à moi :

  • Je ne commente quasiment pas, sauf pour référencer un bug cité ailleurs, expliquer un workaround tordu ou pour dire pourquoi j'ai choisi de résoudre le problème de cette façon. Les commentaires interminables de license en début de fichier me saoulent.
  • J'essaie tant que possible de faires les choses intéressantes et intensives le matin (codage à fond, algorithmes complexes, débogage), et les trucs chiants ou nécéssitant moins de concentration l'après-midi (lire ou écrire de la doc, de la traduction, du contenu de site web, chercher des sites/docs/API/ressources), parce que moi-même je sais que je suis meilleur le matin.
  • Je n'indente pas de façon stricte et je ne mets pas mon code en forme, j'estime que c'est le job des environnements de développement et autres scripts automatiques d'afficher le code selon la forme voulue par l'utilisateur qui lit le code.
  • Moi-même je n'utilise pas d'IDE, je préfère les environnements sobres et la ligne de commande quand je peux. En parralèle de l'éditeur de texte j'ai à peu près toujours un browser d'ouvert même quand je ne code pas du web, pour avoir rapidement la doc sous la main; certains langages sont les champions des inconsistances, php par exemple avec l'ordre des paramètres passés aux fonctions, alors c'est bien utile.
  • Par contre j'ai quand même mes petites conventions perso:
    • Sûrement une déformation dû à mon premier langage d'adoption, mais je n'aime pas les_noms_avec_des_underscores, je préfère largement utiliserLeCamelCase.
    • Je déteste les accolades ouvrantes toutes seules sur une ligne, mais ça ne me dérange pas pour les fermantes.
    • Ca me saoule quand une méthode aussi simple qu'un getter/setter prend 10 lignes, surtout quand il y en a 7 de commentaires à la con; quand c'est moi qui en écris, je mets tout sur la même ligne.
    • Je mets un espace avant la parenthèse ouvrante à la déclaration/définition d'une fonction/méthode, mais pas d'espace lors de ses appell; ça me permet de retrouver très facilement avec Ctrl+F sa déclaration/définition ou les endroits où je l'appelle.
    • Je laisse systématiquement une ligne blanche entre la fin d'une méthode et la suivante; ça permet d'utiliser des raccourcis comme Ctrl+Haut/BAs.
  • Moi aussi j'ai tendance à marteler Ctrl+S, Ctrl+C, Ctrl+Home/End et autres 36 fois pour être sûr
  • Côté musique, j'en écoute parfois, et parfois pas, ça dépend du niveau de concentration requis et de l'humeur du moment; par contre toujours de l'instrumental uniquement ! J'ai déjà remarqué que même s'il y a des paroles dans une langue complètement inconnue, on essaie toujours de comprendre quand même, et fatalement ça finit par déconcentrer.
+0 -1

Je ne commente quasiment pas

Au bûcher !

Je n'indente pas de façon stricte et je ne mets pas mon code en forme

Qu'on le jette dans une fosse rempli de serpent !

Zut… d'abord le bûcher, puis les serpents, ou le contraire ?

+4 -0

Question de point de vue. Je trouve que mettre (très) peu de commentaires nuit beaucoup plus à la compréhension d'un code que le nom de ses variables et fonctions.

Personnellement, je trouve que les commentaires nuisent à la lecture du code. Surtout quand ils sont longs ou expliquent plus que deux lignes de code (comprendre un pavé qui explique ce que fait ta fonction).

Pour moi, un commentaire doit être soit une explication d'un calcul qui semble hasardeux (pourquoi j'ajoute 1 ou multiplie par deux), soit un rappel d'une info importante (actuellement, je rappelle que le premier octet est le MSB alors que le premier but est le lsb chaque fois que je manipule les données binaires), soit un marqueur de correction d'un fait technique.

Mais ce n'est pas pour autant que mon code n'est pas documenté : la spec technique des besoins indique ce qui être fait, la fiche de suivi de livraison, ce qui a été fait et la spec technique de réalisation fournit le comment et pourquoi.

Si je fais bien mon boulot, n'importe qui doit être en mesure de reprendre mon code et de le comprendre à partir de ces documents.

Quand je dois livrer une API ou une bibliothèque, je fournis également la documentation technique qui décrit absolument tout. Mais je ne mets rien dans mon code pour autant. Je mets tout sous forme de doxydoc dans des fichiers texte…

Je comprends un peu les arguments à l'encontre des commentaires.

Autant j'ai horreur des codes non-commentés (et généralement non documentés) autant j'ai également horreur des gens qui racontent leur vie dans les commentaires. C'est généralement difficile à suivre, les 3/4 du temps c'est dans un Anglais approximatif, et surtout c'est jamais maintenu…

Je trouve que les meilleurs commentaires (en dehors de la doc inline style javadoc) sont ceux qui viennent en bout de ligne pour expliquer à quoi fonctionnellement un test conditionnel, un calcul, … correspond quand c'est pas trivial ( if (...) { // sanity check to avoid DoS ).

Ou pour expliquer "on n'a pas pu faire autrement parce que, mais on préfèrerait que…".

Pour moi, un commentaire à l'intérieur du code ne devrait que très rarement dépasser un ligne. Un peu comme on va essayer de découper de la logique en fonctions. Si vraiment le cas est complexe et mérite une explication documentée, alors c'est sans doute que le code en question a une "responsabilité" et je colle ça dans une fonction, un objet, ou autre et je document ladite fonction.

Expliquer un algo complet dans du code, franchement je suis pas fan.

+0 -0

Je ne commente quasiment pas

Au bûcher !

Je n'indente pas de façon stricte et je ne mets pas mon code en forme

Qu'on le jette dans une fosse rempli de serpent !

Zut… d'abord le bûcher, puis les serpents, ou le contraire ?

Gabbro

repose les chaines et le bloc de ciment

Je suis pas certain que les serpents mangent de la viande carbonisée, donc serpents puis bucher (A moins de surveiller la cuisson).

+0 -0

/me met son scaphandre pour éviter de se faire cramer et mordre par les serpents.

C'est bien ce que je craignais.... mais je vous assure, j'essaie de me mettre à python et de me soigner. Suivre une indentation stricte comme l'exige python, c'est pas facile. Tiens d'ailleurs, j'ai encore pas pigé pourquoi ils aimaient tant recevoir du spam.

Du côté musique, j'ai pas dit, je dois être un peu original, j'ai un petit faible pour ces bons vieux fichiers module. L'avantage c'est qu'ils peuvent tourner en boucle… ça m'est déjà arrivé de coder de 5h30 à 12h avec le même titre. L'autre avantage c'est qu'avec rien que 100 MO de ces fichiers, on a déjà de nombreuses heures d'écoute.

Mais non lâââchez-moi, voyons ! Je ne veux pas aller au bûcher !

+0 -0

Tiens d'ailleurs, j'ai encore pas pigé pourquoi ils aimaient tant recevoir du spam.

Parce que toutes les métavariables dans les exemples sont nommées en rapport avec ce sketch des Monty Python :

+0 -0

Pour moi novice en prog:

  • Ctrl + S à chaque modification du code (histoire de rafraîchir la page web aussi)
  • Je commente JAMAIS quand je bosse sur du HTML/CSS pour moi ces deux langages sont suffisamment clair d'eux mêmes et pas assez souvent en JS/PHP/C. Quand c'est un projet a rendre pour l'école je fais du beau code avec des joli décorations en ASCII.
  • En C je compile (trop) souvent, juste pour verifier la syntaxe
  • J'écoute exclusivement du Tobu en musique, ou sinon je regarde/écoute du Doctor Who Classic (ouais les vieux épisodes)
  • Le seul moyen que j'ai de comprendre un doc de façon efficace, c'est au réveil dans mon lit sur mon PC portable.
  • J'ai toujours une organisation des mes 4 Bureaux Ubuntu de la même façon, un code + rendu, un recherche en rapport avec le code, un bureau détente, et le dernier c'est le bureau avec un écran de terminal.
+1 -0
  • En C je compile (trop) souvent, juste pour verifier la syntaxe

Benj9

Je ne sais pas quel éditeur de texte tu utilises, mais Emacs et Vim proposent tous les deux un moyen d'obtenir les erreurs de ce genre. Personnellement, j'ai fondu pour Syntastic sur Vim qui supporte un grand nombre de langages :)

Jérôme Deuchnord

J'utilise Code Blocks à cause de mon école, mais merci je retiens si je passe sur Linux pour mon C :)

+1 -0
  • Je code toujours sous vim en bépo (non négociable), ça m'arrive même de débrancher ma souris pour pas la toucher.
  • Tout est fait en ligne de commande (édition, compilation, git, …), la seule raison pour laquelle je ne fais pas tout en tty avec tmux, c'est le navigateur et les pdf. Et encore, ça m'arrive d'utiliser elinks pour éviter d'avoir un écran trop blanc.
  • J'ai une moitié d'écran pour le terminal principal et une autre où il y a tout le reste… et finalement je fais souvent rien sur le terminal principal.
  • Dès que je suis inactif pendant plus de 0.5s, j'ai une action réflexe qui se produit suivant l'environnement : ls dans un terminal quelconque, :w dans vim, git st (pour git status) dans un dépôt. À un tel point que quand j'ouvre un moteur de recherche et que je me souviens plus ce que je dois chercher, je cherche souvent ls.
  • Ça m'arrive souvent de faire une des action sus-cité 3-4 fois d'affilé.
  • J'ai toujours mon casque pour écouter de la musique… mais j'oublie très souvent de la lancer.
  • Indentation à 2 espaces (ça monte vite en haskell), aucune tabulation, absolument aucun espace à la fin des lignes (lignes vides comprises), sinon je mords.
  • Je passe parfois plus de temps à chercher la combinaison de touche la plus courte pour faire une action dans vim que pour faire l'action en elle-même.
  • Les seules fois où je mets des commentaires dans mon code, c'est avant de coder quand j'ai encore du mal à voir comment je vais faire.
  • Plus je code, plus j'ai d'onglet ouvert dans mon navigateur.
  • Sur les projets en groupe, je prends beaucoup (trop) de plaisir à faire un git revert quand quelqu'un a pushé du code non fonctionnel/buggé.
  • La moitié de mon code est en anglais, l'autre moitié en français. Ça donne plus de synonymes pour les noms de variables/fonctions.
  • Une police de taille 8, c'est bien. 9, c'est trop. 7, c'est illisible.
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte