Bonjour,
je suis intéressé par ce que vous considérez comme de bonnes pratiques, que vous avez vous-même expérimenté.
Pour préciser je suis plus intéressé par des exemples pratiques que par la théorie. Et plus par la méthode que par les technique de programmation.
Voici pour ma contribution:
- Toujours utiliser une gestion de configuration, même à un ou deux.
Les avantages sont évidents. Ne pas utiliser une gestion de configuration qui plombe le processus de développement, je pense à un certain logiciel propriétaire assez buggé, lent, contre-intruitif, et qui veut en faire trop. En bref Subversion est très bien.
- utiliser une méthodes automatisée pour générer et déployer l'application.
- plus généralement les procédures manuelles sont à proscrire.
- Ne pas laisser d'erreurs considérés comme "normales":
Tout ce qui est en gestion de configuration doit compiler (!!),
de préférence sans warning. Et quand on passe les procédures automatises (ant, make, script), cela doit se passer sans erreurs.
- Eviter les générateur de code.
- Ne pas mettre en gestion de configuration des fichiers qui sont générés.
- Commiter du code propre et indenté (penser au merge)
- Ne pas utiliser les tabulation mais des espaces à la place
- Ne pas commiter de fichier avec du code en commentaire
- Utiliser des outils réactif: rien de plus agaçant et distrayant que d'attendre devant son écran.
- définir un vocabulaire: ne pas utiliser le même mot pour des choses différentes, même si les contextes sont différents.
Voilà, et vous quelle est votre expérience du front?
Journal Bonnes pratique pour le développement
11
jan.
2007
# .
Posté par snt . Évalué à 8.
Dans la meme optique que "utiliser une méthode automatisée" je ne suis pas contre les méthodes automatisées pour generer le code quand il s'agit de code répétitif. Exemple: si j'ai 500 tables de base de données, je fais generer des classes d'acces base. Toutes les classes sont écrites de la meme manière. Ca evite des erreurs. Et ca me fait gagner *beaucoup* de temps.
>- Ne pas utiliser les tabulation mais des espaces à la place
De toute facon il faut se mettre d'accord sur la taille d'une tabulation en espace ...
Perso je prefere les tabulations plutot que les espaces..
[^] # Re: .
Posté par Matthieu . Évalué à 7.
[^] # Re: .
Posté par パパフラクス . Évalué à 1.
Il me semble que je m'était fait pincé aussi par un collègue pour une autre raison, mais je ne me souviens plus...
En tout cas c'est sûr, il ne faut pas! ;)
[^] # Re: .
Posté par Guinns . Évalué à 2.
[^] # Re: .
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
Évidemment on peut toujours dire : t'as qu'à utiliser un éditeur avec des tabs à 4 par exemple....Mais c'est un peu énervant si on a, par exemple, juste envie de "visualiser" des sources, rapidement et que le visualisateur/éditeur rapide n'a pas le bon format pour les tabs.
[^] # Re: .
Posté par liberforce (site web personnel) . Évalué à 5.
Règle: pour du placement absolu, utiliser des espaces, pour de placement relatif, utiliser des tabulations. Y a rien qui me gonfle plus que devoir apuyer 15 fois sur backspace, ou avoir des fichiers indentés à la barbare.
[^] # Re: .
Posté par gaston . Évalué à 2.
Je m'insurge ! Avec tout bon éditeur/IDE, on peut faire apparaitre visuellement les tabulations, les espaces et les espaces en fin de ligne.
Geany (ide gtk2) permet de configurer cela dans les préférences, et vim via les options 'set list' et 'set listchars'.
[^] # Re: .
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: .
Posté par gnu_thomas . Évalué à 2.
L'indentation avec des espaces c'est une hérésie, en tout cas ce n'est pas une bonne pratique.
[^] # Re: .
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: .
Posté par gnu_thomas . Évalué à 1.
Je ne vois pas de quoi tu parles.
L'indentation des débuts de lignes est peut-être une hérésie pour toi, ça n'en reste pas moins le standard.
La config par défaut de indent représente les coding styles de GNU et on voit dans la page de man :
-ut, --use-tabs (Use tabs. This is the default.)
En ce qui concerne openbsd et freebsd c'est la même chose :
http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9
http://www.openbsd.org/cgi-bin/man.cgi?query=style
Indentation is an 8 character tab. Second level indents are four spaces.
[^] # Re: .
Posté par Troy McClure (site web personnel) . Évalué à 2.
if(toto && truc_vachement_long &&
tutu && encore_un_truc) {
plop();
coin();
prout();
}
n'est pas possible à faire avec des tabs, puisqu'il y a trois espaces devant tutu (pour qu'il soit joliement aligné avec toto)
> Indentation is an 8 character tab. Second level indents are four spaces.
je comprends pas. Ils recommandent de mélanger espaces et tabs ? Je trouve que c'est le pire du pire
[^] # Re: .
Posté par gnu_thomas . Évalué à 1.
Ton code s'indente donc comme ça :
if(toto && truc_vachement_long &&
tutu && encore_un_truc) {
plop();
coin();
prout();
}
Je trouve ça plus clair d'ailleurs, je trouve maladroit que tes instructions soient décalées sur la gauche par rapport à la 2ème ligne de ton if.
[^] # Re: .
Posté par Matthieu . Évalué à 2.
if (\t toto && truc &&
\t \t tutu && titi ){
}
comme ça mes conditions du if sont alignées, idem pour l'appel d'une fonction avec 50 paramètres
ma_fonction( \t toto,
\t \t \t \t titi );
[^] # Re: .
Posté par Vador Dark (site web personnel) . Évalué à 2.
[^] # Re: Problèmes d'indentation
Posté par Nicolas da Luz Duque . Évalué à 1.
Pour moi la meilleure solution présentée jusqu'à présent est celle de faire tourner indent par SVN sur chaque commit. On définit le standard pour le projet, et SVN se charge de le faire respecter. C'est la solution idéale.
[^] # Re: tabulations
Posté par Sébastien Koechlin . Évalué à 2.
- L'idée derrière est qu'il faut imposer un certain nombre de règles de codage, cela ne se limite pas à l'indentation.
- La règle est discutable. D'après Linus par exemple, le code doit être indenté avec des tabulations, si vous ne pouvez pas voir correctement votre code dans un éditeur tout bête (ceux qui place les tabulations tous les 8 caractères), c'est que votre code est mal fichu et que vous ne maitrisez pas le découpage fonctionnel du code.
Au boulot, les normes de développement impose la tabulation; ainsi que pratiquement une centaines d'autres règles de bonne conduite (pas de catch d'exception vide, un seul return par fonction, pas de membre d'objet qui soit publique...)
[^] # Re: tabulations
Posté par パパフラクス . Évalué à 6.
Ca me parait évident, mais c'est bon de le rappeler.
un seul return par fonction,
Ca par contre je trouve ça débile: ca augmente inutilement la complexité cyclomatique du code, et donc diminue la lisibilité
J'aime bien avoir des tests de gardes au début de mes méthodes pour éliminer les cas spéciaux ou triviaux, et retourner au plus vite, et ensuitre avoir le code du cas général.
Le même code écrit avec un seul return contient plus de niveau d'intentation, et est plus long: pour moi c'est moins bon.
[^] # Re: tabulations
Posté par Troy McClure (site web personnel) . Évalué à 6.
bah c'est pas compliqué, suffit de faire des goto vers le return unique!
void toto() {
blahblah;
if (truc) goto cassos:
burp;
if (machin) goto cassos;
blop;
cassos:
return;
}
[^] # Re: tabulations
Posté par CrEv (site web personnel) . Évalué à 1.
PMString MaClass::MaFonc() { PMString retval = ""; do { if(mon test pas glop) { break; } [...] } while(kFalse); return retval; }C'est des structures de ce type qui sont utilisées entre autre dans InDesign CS2 de Adobe (c'est l'un des rares endroit où j'en ai rencontré en tout cas)[^] # Re: tabulations
Posté par Sébastien Koechlin . Évalué à 4.
fonction f(...) { entier resultat si( situation1 ) { resultat = 1 } sinon si( situation2 ) { resultat = calcul compliqué } retourne resultat }Dans plusieurs cas, on trouve des solutions plus claires; mais le but est surtout d'éviter du code effroyable avec des sorties de boucle, des variables pas trop bien initialisées...Plusieurs des règles que l'on peut imposer résultent d'un compromis. Comme tu l'as visiblement bien compris en rédigeant ce journal, on a besoin de bonnes pratiques, et lorsqu'on est une entreprise, on essaye de les imposer aux fournisseurs. Les bonnes pratiques sont rarement universelles; mais dans l'ensemble, on essaye de les choisir afin d'avoir le code le moins buggé et le plus maintenable possible.En général, le jeune développeur qui débarque est complètement focalisé sur les performances; ensuite il y a un long travail pour lui faire comprendre que ce que l'on veut, c'est un code clair, simple et non buggé. S'il faut mettre un second serveur à coté à cause des performances, ça coûte toujours moins cher que coller trois hommes.mois pour résoudre les problèmes.# vocabulaire
Posté par Nicolas (site web personnel) . Évalué à 3.
J'ajouterais dans les bonnes pratiques:
- faire des tests (unitaires, fonctionnels)
- écrire de la doc
[^] # Re: vocabulaire
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
- ne pas coder comme un porc
- non, une fonction de 1000 lignes, ce n'est pas de l'optimisation.
(ceux qui code des fonctions de mille lignes, on devrait les pendre par les couilles ou non pire : les obliger de maintenir leur code à vie)
"La première sécurité est la liberté"
[^] # Re: vocabulaire
Posté par パパフラクス . Évalué à 3.
Oui je suis bien d'accord!
Ca va souvent de paire avec la programmation par copier/coller qui est une hérésie quand on utilise un langage objet (avec un autre langage aussi d'ailleurs)
[^] # Re: vocabulaire
Posté par CrEv (site web personnel) . Évalué à 4.
(vrai question, j'ai rencontré ça professionnellement et c'est pas évident... a oui, j'ai oublié, comment on fait quand c'est le chef qui code comme ça le tout sans mettre de commentaire ?)
Sinon, pour moi le mini vital c'est :
- svn (ou autre, faut pas être sectaire ;-) )
- bugtracker (j'aime particulièrement trac qui s'interface bien avec svn)
- des commentaires dans le code (objet, fonctions, ...) : utilisation de doxygen, javadoc, etc. C'est à mon avis le mieux car c'est très facile a écrire et à maintenir en même temps que le code *
- point très important, et souvent plus complexe que les problèmes techniques : se mettre d'accord dans l'équipe sur des conventions de codage : code en anglais, position des accolades (enfin c'est forcément à la fin de la ligne donc il n'y a pas a discuter ;-) ), ...
Sinon, j'irai plus loin sur le traitement des erreurs.
Tant que c'est possible (langage, lib externes, ...) toujours avoir - au moins en debug - le niveau de warning le plus élevé possible tout en rajoutant le traitement des warning comme des erreurs. Le résultat est que le programme ne compilera / se lancera jamais tant qu'il y a le moindre warning. C'est un peu contraignant mais ça oblige à lire les warnings et force a écrire du code correcte. Il n'y a rien de plus gonflant que de vouloir compiler un soft et d'être automatiquement noyé sous les warnings idiots.
(*) : Dans certains cas, on peut faire passer en tant que warning le fait qu'il manque un commentaire (sur un membre le nécessitant, membre public, ...). Associé au traitement des avertissements comme des erreurs, l'effet est immédiat : les commentaires apparaissent.
[^] # Re: vocabulaire
Posté par imalip . Évalué à 3.
Moi je suis sectaire, et je dis mort a SourceSafe. Les autres je gere, mais celui-la, non, vraiment, je peux pas.
[^] # Re: vocabulaire
Posté par CrEv (site web personnel) . Évalué à 4.
Toute personne ayant déjà utilisé sourcesafe sait que ce n'est pas un vrai gestionnaire de source mais simplement une blague que les personnes de crosoft on voulu faire mais que des idiots on décidé de prendre au sérieux...
(oui, 1 an de sourcesafe ça marque, j'avais fini par écrire un soft en ruby permettant de migrer sourcesafe vers svn mais j'ai quitté la boite avant de le finir totalement ;-) )
[^] # Re: vocabulaire
Posté par tuiu pol . Évalué à 2.
Mais mais mais .. on a bossé dans la même boite ??
[^] # Re: vocabulaire
Posté par imalip . Évalué à 2.
[^] # Re: vocabulaire
Posté par CrEv (site web personnel) . Évalué à 2.
Moi qui coryait être passé dans une exception ;-)
Le mieux ça a été leur tête quand j'ai demandé, lors de mon 2° jour dans cette boite, s'il y avait des conventions de codage et si oui lesquelles. J'ai compris un peu plus tard, quand j'ai vu leur code...
Ils ont du me prendre pour un fou ! ;-)
[^] # Re: vocabulaire
Posté par tuiu pol . Évalué à 3.
- pas de convention de codage
- des fonctions qui font facilement plusieurs milliers de lignes
- des prototypes de fonctions avec plusieurs dizaines de variables
- pas de typage fort
- pas d'indentation défini
- le nommage des variables dans le genre x, y, z ou toto, tata
- réutilisation des variables pour faire passer d'autres infos .. d'autres types
- ..
En fait c'est super formateur parceque c'est tout à fait à l'opposé de l'ensemble des bonnes pratiques :) Comme ça tu vois en vrai pourquoi il ne faut pas faire ça.
[^] # Re: vocabulaire
Posté par パパフラクス . Évalué à 2.
Pour les tests, ça me parait évident, bien que les test unitaires n'ont pas l'air d'être évidents pour tout le monde.
De la même manière utiliser un outils de suivi de bug me semble tellement indispensable que je m'aperçoit que je ne l'ai même pas mentionné.
Pour la doc, c'est important, mais il faut éviter de faire de la doc pour faire de la doc.
Moins il y en a et mieux c'est (il faut la maintenir à jour), mais il y a un minimum à fournir
.
Pour la forme, le wiki c'est pas mal (mieux qu'un tas de fichiers bien enfouis sur un lecteur partagé en tout cas)
Mais c'est pas optimal non plus, au bout d'un moment, les gens oublient de mettre à jour le wiki, et de plus les non-informaticiens ne sont pas toujours à l'aise avec.
[^] # Re: vocabulaire
Posté par imalip . Évalué à 2.
/me se rappelle avec nostalgie d'une de ses précédentes boites (penser télécom et Suede) ou il a passé 3 mois a écrire de la doc pour un wrapper entre 2 API qui a été codé et testé en une demi-journée.
J'ai démissioné au bout de 5 mois. Bon, j'avoue que c'est aussi parce que j'avais dans les mains une offre que je ne pouais pas refuser, mais j'étais soulagé de partir...
[^] # Re: vocabulaire
Posté par totof2000 . Évalué à 2.
[^] # Re: vocabulaire
Posté par vieuxshell (site web personnel) . Évalué à 0.
Un outil de gestion de version est un outil qui permet de faire de la gestion de configuration :)
# Alors, il faut générer ou pas ?
Posté par PachaFonk . Évalué à 4.
En ce qui me concerne, je remplacerais celle là par :
- Générer le code chaque fois que c'est possible.
pour moi, utiliser un générateur de code, c'est du même ordre d'idée que d'utiliser une bibliothèque externe.
Ne pas oublier non plus que les compilateurs sont des générateurs de code !!!
Alors, on les génère ou pas ?
[^] # Re: Alors, il faut générer ou pas ?
Posté par パパフラクス . Évalué à 2.
+1
Alors, on les génère ou pas ?
J'ai dis "éviter", pas interdire ;)
En fait je me pose pas mal de question la dessus.
A mon avis, si le langage permet de réutiliser le code, ou d'écrire du code générique pour le problème rencontré, il faut privilégier cette voix
En tout cas la génération de code pose problème pour les fichier qu'on doit retoucher ensuite:
- écrasement des modifs par la génération suivante
- les dév on peur de toucher le code généré
- générateur pas à jour -> procédure manuelle pour palier le problème.
Car bien souvent un générateur est complexe, et personne ne veux/peux le maintenir si la personne qui l'a mis en place n'est plus là.
Plus généralement je me pose aussi la question de l'utilisation des outils de "programmation visuelle".
J'ai plutôt tendance à avoir confiance dans une approche entièrement textuelle: le code fais foi,
mais j'arrive pas trop à me justifier la dessus.
[^] # Re: Alors, il faut générer ou pas ?
Posté par パパフラクス . Évalué à 1.
[^] # Re: Alors, il faut générer ou pas ?
Posté par PachaFonk . Évalué à 5.
il ne faut *JAMAIS* modifier à la main du code généré
ils ont bien raison.
Deux cas :
1) le générateur viens de l'extérieur :
Avant de se décider à l'utiliser, s'assurer qu'il existera toujours (vive le logiciel libre !!!) et s'assurer qu'il est suffisemment bien construit pour avoir une gestion fine du code généré.
2) le générateur est écris en interne :
Il faut le gérer comme le reste du code qui peut être complexe aussi !!!
# Vocabulaire
Posté par ritsz . Évalué à 1.
je ne suis pas développeur, et donc je suis gêné par le mot commiter. Je comprends le besoin d'adapter l'anglais "to commit", mais ne faudrait-il pas trouver un mot français qui va bien plutôt que ce franglais ?
[^] # Re: Vocabulaire
Posté par TNorth . Évalué à 3.
J'admets que c'est pas parfait, mais ça pourrait convenir....
[^] # Re: Vocabulaire
Posté par bios_qui_rote . Évalué à 6.
Guilbert: "C'est bon, j'ai soumis mes changements."
Raymond: "Hein ?! T'as fait quoi ??"
Guilbert: "J'ai commité."
Raymond: "Ah ok."
Conclusion, ça fait perdre du temps à Guilbert et Raymond.
[^] # Re: Vocabulaire
Posté par パパフラクス . Évalué à 3.
D'accord je sors!
Quoique parfois on peux se demander ;)
Cela dit, l'"outils linguistique" de google donne cette traduction, mais bon c'est pas forcément une référence
A mon avis le sens est plutôt confier (au système de gestion de versions)
[^] # Re: Vocabulaire
Posté par CrEv (site web personnel) . Évalué à 3.
La première raison (mais la moins importante) et que le jour ou j'ai utilisé un logiciel de gestion de source en français (c'était simplement une version de tortoise svn en français) j'ai rien compris du tout, les mots ne voulaient rien dire du tout pour moi (car j'avais déjà mis une connotation sur les mots anglais).
La deuxième raison est que presque tous les logiciels de gestion de source comportent les commandes en anglais (cvs/svn commit, checkout, ...) et donc si on apprend pas les termes anglais le jour où il faut utiliser un tel logiciel en ligne de commande on ne peut/sait pas...
[^] # Re: Vocabulaire
Posté par ola . Évalué à -5.
[^] # Re: Vocabulaire
Posté par CrEv (site web personnel) . Évalué à 2.
C'est une vrai question, il m'arrive régulièrement d'utiliser mon svn en ligne de commande sans aucun soucis.
Je trouve justement cette utilisation parfois plus pratique et plus rapide que par les gui classiques (j'utilise depuis quelques jours kdesvn et ça marche quand même pas trop mal)
Surtout que le jeu de commande de base est très succint et au moins on est certain de savoir ce que l'ont fait
[^] # Re: Vocabulaire
Posté par ola . Évalué à 2.
Bon apres, j'suis dev java, un repertoire par package, t'imagines vite le bordel a se fader des cd com/maboite/monprojet/package/souspackage, cd ../../../../../ etc.
M'enfin, l'idee est la quoi.
Sinon, syntaxe aride, commandes cryptiques, enchainement particulierement relou de commandes (pour supprimer un repertoire et son contenu, par ex), page man longue comme ma teub (i.e. : gros, tres gros ^_^) etc.
Lever un conflit de commit en ligne de commande, ben voila quoi.
Rien que pour supprimer un fichier : rm fichier cvs delete fichier, cvs commit, ca fait une operation de trop ('fin a mon gout, hein).
Un client CVS graphique decent t'affichera directement un diff graphique avec toute les facilites pour naviguer (perso, j'utilise enormement la perspective CVS/Team synchronise d'eclipse, ben quand meme ca simplifie la vie)
En tout cas dans une utilisation pro, CVS en ligne de commande me parait totalement inutilisable.
Techniquement, je l'ai fait, sur un petit projet ou j'avais une partie du boulot a faire en ssh sur une machine distante, avec 4-5 fichiers max a manipuler, c'etait deja penible, j'ose pas imaginer quand je commit mes 15 classes (en fait, dans ce cas la, j'aurais rappatrié les sources sur mon poste local et j'aurais commite dans mon eclipse).
Tres recemment, j'ai du me fader l'historique de mes commits pour retrouver un jar bien particulier : selection de la vue "historique", dnd du fichier dans la vue, ya plus qu'a click droit sur chaque revision, get Contents, double click et paf, j'ai ce qu'il me faut sous la main, le tout avec la date du commit, le ocmmentaire, le numero de verison etc sous les yeux et bien organise.
Va naviguer parmi les tags/branches etc dans un client ligne de commande.
Va checkouter une version anterieure a une certaine date en ligne de commande, entre un calendrier graphique et la saisie de la date manuellement ya pas photo, mon choix est vite fait.
Apres, si c'est juste pour faire un checkout d'un projet sur 'ternet, ./configure && make, c'est sur que c'est plus rapide que de sortir un gros client graphique.
Je connais pas du tout SVN, mais il m'a l'air tout a fait calqué sur CVS niveau utilisation.
[^] # Re: Vocabulaire
Posté par CrEv (site web personnel) . Évalué à 3.
Pour ma part, avec svn, c'est quand même plus simple (rien que du fait qu'il gère le repository et non simplement des fichiers)
Si je ne me trompe pas en svn pour supprimer il suffit de faire svn rm fichier && svn commit
Sinon, pour la gestion des rep, il suffit aussi de se def une variable correspondant à ton projet :-)
Attention, je ne dis pas qu'un client graphique est inutile, pour moi le meilleur client c'est simplement celui qui est intégré dans l'ide (dans la liste des fichiers). Mais je réagit surtout au fait qu'il faudrait être SM pour utiliser en cli.
Pour ce qui est des opérations de base (je sais pas vous, mais sur un projet "classique" je touche pas les branches toutes les 5 min et il "suffit" de tagger car ça ça se fait très rapidement, y compris le swap sur la tête) la ligne de commande peut suffire et est tout a fait utilisable.
[^] # Re: Vocabulaire
Posté par ola . Évalué à 1.
pffouuu..
ca fait chier. mon boulot c'est pas de me compliquer la vie alors que c'est le boulot d'une machine de gerer la presentation des infos.
D'autre part, je crois qu'on s'est mal compris, je parlais de naviguer dans une arborescence en ligne de commande : c'est pas pratique de naviguer dans un arbre avec une ligne de commande. Parce que tu n'as pas de vision globale.
je sais pas vous, mais sur un projet "classique" je touche pas les branches toutes les 5 min et il "suffit" de tagger car ça ça se fait très rapidement, y compris le swap sur la tête
ben chais pas, a chaque commit j'impacte bien 5 a 10 fichiers.
Et commiter sans verifier le diff pour chaque fichier, tres peu pour moi.
Bref le probleme vient plus d'une mauvaise presentation des infos du CVS (impossible de faire un diff lisible etc.) que du concept ligne de commande.
tout a fait d'accord avec toi par contre concernant l'integration a l'ide.
[^] # Re: Vocabulaire
Posté par jcs (site web personnel) . Évalué à 1.
Après c'est une question d'habitude. Moi aussi je développe en java. Mes outils : xterm + emacs et Netbeans de temps en temps. Maven pour la compilation. J'ai déjà utilisé le plugin SVN de Netbeans. Bien sûr ça marche bien mais je trouve que je ne gagne rien par rapport à la ligne de commande, plus rapide et plus pratique à mon goût.
Par contre sous windows, j'ai été très impressionné par TurtoiseSVN.
[^] # Re: Vocabulaire
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Ben interresse toi à SVN ! Car même si il reprend en (tres) gros les commandes, SVN a été grandement simplifié (c'était le but du projet d'ailleurs, qui, je le rappelle a été fondé par des anciens dev de feu CVS)
Avec CVS, moi aussi les commandes me rebutaient. Plein de switches et paramètres dans tout les sens. Obligé d'utiliser un outil graphique sinon ça m'énervait trop.
Quand je suis passé à subversion, les commandes sont tellement simples que je n'ai depuis jamais réutilisé d'outils graphique. Le tutoriel aussi est très bien fait, ce qui a certainement influencé mon appréciation. ( http://svnbook.red-bean.com/ )
Franchement, passe à SVN... C'est que du bonheur quand on a connu CVS.
[^] # Re: Vocabulaire
Posté par ola . Évalué à 1.
[^] # Re: Vocabulaire
Posté par パパフラクス . Évalué à 4.
En ce moment je suis contraint à utiliser wasd, qui n'est autre qu'un Eclipse customisé.
Tout a été francisé, ça m'a fait perdre pas mal de temps à chercher dans les menus et les préférences. Ah oui, parce qu'il ont modifié les raccourcis clavier aussi...
Sans parler de la débilité de certaines traductions:
par exemple le "go into" traduit par "suivant", qui ne veut rien dire,
ou bien "propager les modification" pour "refactor"...
[^] # Re: Vocabulaire
Posté par ritsz . Évalué à 2.
[^] # Re: Vocabulaire
Posté par Emmanuel C . Évalué à 1.
Non ?
[^] # Re: Vocabulaire
Posté par TImaniac (site web personnel) . Évalué à 2.
Valider la transaction ?
Valider les modifications ?
[^] # Re: Vocabulaire
Posté par golum . Évalué à 2.
On dit remettre un fichier comme on parle de l'extraire pour modification
(check-out)
# Impressionnant
Posté par kadreg . Évalué à 6.
# Et les tests, vous oubliez les test !
Posté par jemore . Évalué à 2.
- Une procédure d'installation documentée et automatisée du poste de développement. Utiliser la même version de l'IDE, du compilo etc, pour faire en sorte que ré-installer un poste de dev et compiler la dernière version ne prenne pas plus d'une heure.
- Un gestionnaire de LOG parametrable.
[^] # Re: Et les tests, vous oubliez les test !
Posté par パパフラクス . Évalué à 2.
Par contre ce qui est un vrai problème c'est d'écrire des test unitaires pour de l'existant qui n'en comporte pas: c'est quasi impossible, car le code n'est en général pas écrit de manière à être testable, et il est impossible de le modifier sans casser ce qui marche (car en fait on ne sait pas ce qui marche ou pas!!)
[^] # Re: Et les tests, vous oubliez les test !
Posté par Stephane Wirtel (site web personnel) . Évalué à 2.
Par contre, une approche tout aussi intéressante est le refactoring. Bien que couteux en temps, il s'avère fort intéressant à long terme.
L'intérêt du refactoring, est le nettoyage de code pour garder un code à jour.
Lire les articles de JoelOnSoftware et de Martin Fowler sont très instructif.
# À lire
Posté par Jb Evain (site web personnel) . Évalué à 2.
http://www.amazon.fr/Pragmatic-Programmer-Journeyman-Master/(...)
À lire, plusieurs fois.
[^] # Re: À lire
Posté par CrEv (site web personnel) . Évalué à 2.
Pour ceux qui ne connaissent pas, il y a aussi celui-ci que j'ai assez bien aprécié :
http://www.amazon.fr/Tout-sur-code-concevoir-logiciel/dp/210(...)
(n'ayez pas peur, c'est pas parce que c'est marqué microsoft press que c'est pas bien ;-) )
# Quand je programmais...
Posté par georgeswwbush . Évalué à 2.
http://www.canonical.org/~kragen/tao-of-programming.html
# Mon expérience actuelle
Posté par liberforce (site web personnel) . Évalué à 2.
Mon premier vrai dev provessionnel sous linux. C'est du C.
Avec tous les préceptes que j'ai découvert sur linuxfr et la communauté GNOME, je me suis mis à appliquer tout ceci:
* gestionnaire de versions : subversion
* bugtracking: trac (je m'en sers pour le wiki et le suivi des changesets subversion)
* génération: autotools (make check et make distcheck rulez)
* doc: doxygen
* tests unitaires: http://check.sourceforge.net
Quand je pense que je codais en MFC il y a 3 ans :-p
La règle primordiale quand tu codes: penses à ce que tu laisses à celui qui passe derrière toi ! Bien des fois, ce sera toi, 3 mois plus tard, et ça t'aidera bien à recomprendre ce que tu avais fait à l'époque.
Pour certaines de tes remarques, voici mon avis personnel:
Question de goût, quand tu sais utiliser les tabulations, tout devient plus facile. Des fois, j'ai l'impression que les paresseux ne cherchent pas à comprendre et utilisent les espaces systématiquement. Oui, ça fait gros con de dire ça.
Moyennement d'accord. C'est ce que je faisais et j'en ai eu marre de refaire 15 fois la même chose (que j'avais fait, puis effacé). Alors je mets du #if 0 pour marquer les bouts de code mort, et s'ils restent morts assez longtemps, je les vire. un grep permet tout de suite de les localiser, ce que tu ne peux pas faire avec un commentaire.
[^] # Re: Mon expérience actuelle
Posté par Sylvain Sauvage . Évalué à 2.
Tu n'as jamais pensé à /* Dead code, might be resurrected soon ou un truc du genre ?
[^] # Re: Mon expérience actuelle
Posté par liberforce (site web personnel) . Évalué à 2.
mais il est vrai qu'un #if DEAD_BUT_NOT_QUITE , ça le fait aussi ;-)
[^] # Re: Mon expérience actuelle
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Re: Mon expérience actuelle
Posté par Sylvain Sauvage . Évalué à 3.
[^] # Re: Mon expérience actuelle
Posté par jeje99 . Évalué à 3.
Pour la simple raison que si le code mort contient des commentaire le compilateur ne risque pas d'être perturbé et surtout le programmeur n'a pas à se prendre la tête.
Bien sur la mise en commentaire de code source est pour moi à utiliser avec modération. Mais est quand même très utile dans le cas d'un débugage par exemple. Mais aller de là à commiter du code mort ça me semble limite, généralement (attention j'ai bien dis généralement) quand on commit, ça que ça marche.... :-)
[^] # Re: Mon expérience actuelle
Posté par ola . Évalué à -1.
zavez jamais pense a utiliser un vrai ide, du genre qui vous permet de faire une recherche dans tous les fichiers du projet, plutot que de jongler avec 4 applis en permanence?
# Ne pas péter plus haut que son cul
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
_ Avancer petit à petit et valider au fur et à mesure
_ Faire des libs
_ Faire des tests
# Serveur de build de nuit
Posté par jeje99 . Évalué à 2.
En gros une tache cron qui checkout la dernière version du soft et la compile (d'où l'utilité de tout pouvoir compiler à l'aide d'un make).
Est - ce qu'il y en a parmis vous qui ont éprouvé cette solution, est - ce vraiment utile ?
[^] # Re: Serveur de build de nuit
Posté par phoenix (site web personnel) . Évalué à 1.
Mais si c'est un gros soft tu ne fais que des tests unitaire, et le build nocturne permet de rassembler le tout.
Tout dépend de la taille de ton projet
[^] # Re: Serveur de build de nuit
Posté par パパフラクス . Évalué à 2.
Ca permet d'avoir un retour rapide pour le développeur sur ce qu'il vient de commiter (oui encore cet anglicisme ;) et ces eventuels oublis.
Par exemple sur un projet on utilisait CruiseControl, qui compilait et executait les test unitaire après chaque commit, et envoyait un rapport aux developpeurs, c'est super utile, mais ça demande un peu d'éducation: j'ai vu des développeur filtrer les mail de rapports directement à la poubelle...
Et aussi, faire passer les test unitaire doit être une priorité
[^] # Re: Serveur de build de nuit
Posté par enzbang (site web personnel) . Évalué à 2.
L'idéal c'est de lancer les tests unitaires à chaque commit et des tests plus poussés toutes les nuits.
[^] # Re: Serveur de build de nuit
Posté par Stephane Wirtel (site web personnel) . Évalué à 1.
[^] # Re: Serveur de build de nuit
Posté par Stephane Wirtel (site web personnel) . Évalué à 1.
Générer la documentation de ton code
Compiler ton code
Réaliser les tests unitaires
Vérifier le rapport de tes tests unitaires
Packager tes binaires pour l'équipe de qualification qui doit vérifier ton code, avec un listing des améliorations et des bugs supplémentaires.
Y a plein de choses que l'on peut faire.
[^] # Re: Serveur de build de nuit
Posté par pasBill pasGates . Évalué à 3.
C'est extremement utile sur les gros projets car ca permet de tirer avantage du temps ou les gens dorment(la nuit) pour effectuer des etapes essentielles mais couteuses en temps (build qui peut prendre bcp de temps, tests unitaires qui peuvent prendre du temps aussi, ...)
Le desavantage c'est quand tu recois un coup de fil a 8h du soir d'un gars qui t'annonce que ton commit a casse le build et que tu ne feras rien d'autre avant que ce soit corrige...
# Parler anglais
Posté par Moogle . Évalué à 3.
- Quand on fait du code libre, c'est bien de pouvoir le diffuser au monde et pas seulement aux francophones.
- En anglais, y'a pas d'accents, et les accents dans les noms de variable, ça suxxx.
- Ca fait réviser l'anglais.
Et puis pas mélanger les langues. Je me souviens d'un projet de fac où j'ai fait tout une partie en angliche, et les autres tous en franchiche. Et bah c'était pas joli joli.
[^] # Re: Parler anglais
Posté par パパフラクス . Évalué à 3.
Oui sauf qu'en France les spec sont souvent écrites en Français, et les gens parlent entre eux en Français.
Traduire en anglais introduit une ambiguïté, et en plus en France on est pas très fort en anglais, et je t'assure que ça pose problème, entre ceux qui comprenne rien, et ceux qui introduise des traduction toute pourrie.
- Quand on fait du code libre, c'est bien de pouvoir le diffuser au monde et pas seulement aux francophones.
Tout à fait d'accord, et là je trouve que ça se justifie pleinement d'investir dans une conception en anglais. AMA il faut a tout pris éviter de concevoir en français pour traduire ensuite, il faut tout faire en anglais, dès la conception fonctionnelle.
- En anglais, y'a pas d'accents, et les accents dans les noms de variable, ça suxxx.
Les langages qui ne gère pas les accents, ça suxxx.
Bon, dans la réalité je n'utilise pas les accents dans le code, mais avec un langage moderne (Python, Java) ça ne pose aucun problème. D'ailleurs c'est un indice pour la gestion de l'internationalisation. Par exemple Ruby suxxx, à ce niveau là.
- Ca fait réviser l'anglais.
C'est bien ce que je dis, beaucoup de gens ne maîtrisent pas l'anglais, et sur un projet, ça peut faire mal.
Et puis pas mélanger les langues. Je me souviens d'un projet de fac où j'ai fait tout une partie en angliche, et les autres tous en franchiche. Et bah c'était pas joli joli.
Je suis d'accord, c'est moche, mais parfois c'est un moindre mal.
Dans le cas de spec en français, je garde le vocabulaire métier en français, et le reste en anglais et je les compose à l'anglaise.
Par exemple pour une méthode qui crée une facture, je l'appelle
createFacture, car tout le monde parle de "facture" quand on discute, et pas de "invoice"
Et de toute façon, il y a un certain nombre de dev qui ne connaissent pas le mot "invoice" et mettront "facture" dans leur code
[^] # Re: Parler anglais
Posté par Guinns . Évalué à 1.
Nan, sérieux ... qu'est ce que ca peux bien apporter (à part des problèmes) d'avoir un langage qui gère les accents ???
Avec les éditeurs qui ne gèrent pas encore tous les codages modernes de caractères (UTF et compagnie), avec le nombre important de polices de caractères nécessaires pour pouvoir afficher toute la panoplie des caractères unicodes (empreinte mémoire), quid de la relecture et de la compréhension du nom des fonctions/variables (on parle de favoriser l'anglais ... imagine du code en caractères asiatiques !) ...
Donc, ca apporte quoi ?
[^] # Re: Parler anglais
Posté par パパフラクス . Évalué à 3.
J'avais essayé dans Eclipse il y a un certain temps et ça marche,
pas mal pour rendre son code illisible ;)
Je suis d'accord, ça apporte pas grand chose, pour le code,
c'est d'ailleurs pour ça que je ne le fais pas.
Par contre pour les chaînes de caractères c'est indispensable.
[^] # Re: Parler anglais
Posté par jahrynx . Évalué à 2.
Bon ca s'applique peut-être pas à tous les environements de travail mais on est quand même à l'heure de la mondialisation ;)
# Source inépuisable
Posté par パパフラクス . Évalué à 2.
http://c2.com/cgi/wiki
Et aussi comme cité plus haut, Martin Fowler distille de sages conseille et n'est pas avare de son expérience
http://www.martinfowler.com/
# ce qu'il ne faut surtout pas faire
Posté par gst . Évalué à 1.
#define SEND_INFO \
if (data_size) \
if (send_rsp(dest, data)) \
print_error;
(et encore, celle-ci c'est une "gentille" comparé à ce qu'il a pondu)
et dans le fichier source d'appeller de telles macros plus ou moins toutes les 15/30 lignes... sur des fichiers de plus de 5000 lignes.. et bien entendu dans des fonctions différentes..
supeeeeeeeeeerrrrrrr - étonnament j'ai eu pas mal de confrontation avec ce gars justement pour ces questions de bonnes pratiques..
# et les assert alors ?
Posté par CrEv (site web personnel) . Évalué à 3.
Mais pas d'assetions...
Les assertions sont une bonne invention utile, voir même indispensable.
Peut-être que personne n'en parle car vous les utilisez, et dans ce cas c'est bien, mais j'ai rencontré il y a peu des personnes (oups, mes chefs en fait...) qui avaient du mal à comprendre ce que c'était et l'intérêt d'écrire des assertions... (et evidemment se plaignaient ensuite quand sa crash sans savoir pourquoi)
Evidemment certaines personnes ne comprenaient pas à quoi ça servait car ne lançait jamais leur programme en debug, toujours en release -> autre chose à ne jamais faire.
Pour ma part je fais exactement l'inverse, je lance tout le temps en release (y compris quand ça met 2-3 vrai minutes à se lancer) et en release une fois que le debug est correct.
[^] # Re: et les assert alors ?
Posté par Stephane Wirtel (site web personnel) . Évalué à 2.
# Résumé perso de la discussion
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Haypo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.