Ce petit ouvrage devrait permettre à ceux qui souhaitent se lancer dans le développement open source de partir sur de bonnes bases. Bonjour, c'est avec émotion et ptite larmichette à l'oeil que je vous annonce la naissance de l'O.S.T.D.C. pour Open Source Team Development Chart.
Ce document est une introduction visant à l'essentiel pour les personnes qui souhaiteraient se lancer dans le développement open source en équipe.
Ce petit ouvrage, de 15 pages seulement, présente succinctement les notions inévitables dans le développement en équipe et propose comme référence essentiellement des outils et normes provenant de la communauté open source.
Un grand merci à Albert Bruc, Romuald Conty et Pierre Delaunoy pour leur aide et leurs contributions. Cette charte est déja mise en place au sein du projet Time Breach et pourrait être appliquée sur d'autres projets comme MediaBox404 ou Videolan Live Regie .
Bonne lecture pour les nouveaux venus dans le développement Open Source et pour les anciens, vous pourrez dire: "RTFOSTDC" ^^
Petit détail, qui a son importance, ce document est placé sous licence Creative Common By Sa. Certains ont demandé pourquoi cette licence, tout simplement pour pouvoir l'intégrer directement dans les documents du projet Time Breach.
Aller plus loin
- Time Breach (5 clics)
- Mediabox404 (3 clics)
- Labo-Linux (4 clics)
# PDF
Posté par wwp (site web personnel) . Évalué à 4.
une version PDF est-elle dispo? (pas vu, mal vu?)
[^] # Re: PDF
Posté par Axel . Évalué à 1.
[^] # Re: PDF
Posté par Alexandre CABROL PERALES . Évalué à 1.
[^] # Re: PDF
Posté par Alexandre CABROL PERALES . Évalué à 1.
Mais au niveau de la mise ne page c'est trés foireu donc voici un lien vers un vrai pdf généré par Open Office. je place aussi la version ODT pour ceux qui le souhaite.
Vous trouverez deux ptit liens en tête de la publication un PDF et un ODT sur
http://timebreach.tuxfamily.org/modules/smartsection/item.ph(...)
J'espére avoir répondu à vos attentes.
P.S. c'est le lien Time Breach donné dans l'article.
[^] # Re: PDF
Posté par wwp (site web personnel) . Évalué à 1.
[^] # Re: PDF
Posté par syntaxerror . Évalué à 1.
Le doc est intéressant, mais pourquoi l'écrire en anglais parfois approximatif ? D'ailleurs puisque l'original est un doc Openoffice, tu pourrais passer dessus le correcteur orthographique après avoir changé la langue par défaut (outils/options/langues/langue par défaut pour le doc + seulement document actif)
# Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 4.
quelqu'un pourrait-il m'expliquer l'intérêt, l'avantage, ou la raison, qui fait que l'on choisisse de mettre les accolades ouvrantes seules sur leur ligne ?
En quoi écrire ça :
while(1)
{
malloc(1);
fork();
}
est-il meilleur que d'écrire ça :
while(1){
malloc(1);
fork();
}
Personnellement (mes goûts et mes couleurs), je préfère la deuxième manière de faire, la perte de place et d'énergie de la première me rebute, et de plus je la trouve nettement moins lisible, car trop étalée. Je trouve qu'on voit mal le fait que le contenu entre les accolades est ce qui est exécuté par le while.
En plus, j'ai un principe qui dit qu'une fonction qui dépasse de l'écran en hauteur est forcément mal codée et doit être réécrite ou découpée, repensée, bref changée, et cette perte d'une ligne est dramatique. Ce principe vient du fait que si on est obligé de scroller pour lire une fonction, on se fatigue beaucoup plus pour la comprendre et on a bien plus de mal à l'appréhender complètement.
Ce sont mes goûts et mes couleurs... Mais j'aimerai d'autres avis...
Sinon, rien à voir, mais il y a une traduction (française au moins) qui existe, est prévue, est en cours ?
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 2.
En quoi écrire ça :
while(1)
..{
....malloc(1);
....fork();
..}
est-il meilleur que d'écrire ça :
while(1){
....malloc(1);
....fork();
}
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 1.
Ainsi :
while (1):
....malloc(1);
....fork();
gagnerait une ligne sur :
while(1){
....malloc(1);
....fork();
}
Bon mais sinon, je suis d'accord avec toi. Je préjère également de loin mettre l'accolade ouvrante sur la même ligne que l'instruction conditionnelle.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 2.
Le Python impose simplement d'avoir une indentation propre puisque c'est ce même moyen, unique, qui est utilisé par le compilateur et le programmeur pour détecter les blocs.
J'aime beaucoup la syntaxe du python :)
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par gael s. . Évalué à 1.
ça inclut le nb de ligne par procédure et celui par fonction
[^] # Re: Saut de ligne avant l'accolade.
Posté par Jean-Philippe (site web personnel) . Évalué à 5.
(Si on considere que malloc existe en python bien) on obtient plutôt ceci :
while 1 :
....malloc(1)
....fork()
[^] # Re: Saut de ligne avant l'accolade.
Posté par chl (site web personnel) . Évalué à 2.
Par exemple, moi je mettrais une espace entre ton while(1) et ton accolade ouvrante, pour donner :
while(1) {
C'est carrément plus lisible que :
while(1){
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 2.
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Sylvain Sauvage . Évalué à 5.
while (test) {
for (int i = 0; i < N; ++i) {
comparé à :
juste_fais_le(11);
En tout cas, pour les accolades, je préfère
while (1) {
}
mais
while (1)
{
}
ne me gêne pas trop, du moment que l'on reste cohérent dans un projet, même si je vois moins que l'accolade correspond au while : quand je vois une accolade ouvrante seule sur sa ligne, je prends ça pour un bloc « RIIA »…
while (1)
{
}
me dérange plus : ça fait un niveau d'indentation supplémentaire, réservé aux accolades.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Samuel Verschelde (site web personnel) . Évalué à 8.
while(1)
{
....malloc(1);
....fork();
}
Je préfère ne pas identer les {}
L'avantage pour moi de cette manière de faire c'est que, bien qu'elle prenne plus de place, elle place ouverture et fermeture de bloc au même niveau, et en cas d'imbrications nombreuses, je m'y retrouve plus facilement.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 3.
while(1) { // ouverture
....malloc(1);
....fork();
} // fermeture
Et même en cas d'imbrications nombreuses ça reste clair.
while(1) {
....malloc(1);
....if(fork()) {
........printf("Je suis ton père\n");
....} else {
........printf("Noooooon !\n");
....}
....malloc(1);
}
Bref, uniquement une question de goût personnel donc ?
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Tian (site web personnel) . Évalué à 5.
Justement, ca demande un peu plus de reflexion et de temps pour identifier le marqueur de debut de bloc. Car dans ton cas, le marqueur de debut est while ou for ou if ou.... Alors que dans l'autre cas, c'est { et c'est tout.
Donc en mettant l'accolade a la ligne, on repere plus facilement le debut du bloc sans devoir se livrer a une petite conversion intellectuelle.
Et quant au fait d'avoir une regle absolue comme le fait de faire tenir une fonction sur une seule page. Puis de tout faire pour la respecter au detriment de la lisibilite, je trouve ca pire que tout ;)
[^] # Re: Saut de ligne avant l'accolade.
Posté par Samuel Verschelde (site web personnel) . Évalué à 6.
Le plus dur pour moi dans l'exemple donné plus haut, c'est ce passage :
....if(fork()) {
........printf("Je suis ton père\n");
....} else {
........printf("Noooooon !\n");
....}
Dans mon parcours vertical, je rencontre "if" qui démarre un bloc... Avec un peu d'entraînement je suis sûr que je pourrais comprendre aussi rapidement que si j'avais un :
if
{
mais cela m'ajoute déjà un peu de travail intellectuel.
Ensuite vient le pire :
....} else {
Sur la même ligne j'ai une fin de bloc et le début d'un nouveau bloc. Je suis obligé d'interrompre ma descente pour lire la ligne et comprendre que ce deuxième bloc est un bloc "else".
Quand on a un code aéré, la place que prend le code est largement compensée par la rapidité à laquelle on peut le parcourir :
while(1)
{
....malloc(1);
....if(fork())
....{
........printf("Je suis ton père\n");
....}
....else
....{
........printf("Noooooon !\n");
....}
....malloc(1);
}
Là, en un regard, je chope directement "malloc" "if" "else" "malloc" sans avoir à purifier le début de la ligne "else" des {} éventuelles.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 4.
Le saut de ligne me pollue, je suis obligé de regarder la ligne d'avant l'accolade, avec le while, le if ou le else, pour savoir ce que c'est que ce bloc qui commence.
Un bloc comme ça dans le vide, pour moi, ça n'a pas vraiment de sens.
S'il y a un bloc c'est qu'il y a une raison, la seule chose importante c'est cette raison.
Je trouve qu'on voit très très bien le début du bloc là :
while(1) {
....malloc(1);
....fork();
}
parce qu'il suffit de remonter l'indentation, au même niveau que l'accolade fermante, plus haut, après l'espace vide, j'ai un while, je sais donc immédiatement que j'ai un bloc « while » qui commence au while et termine à l'accolade fermante.
Dans ton long exemple d'indentation en bas, je ne vois rien du tout, les fonctions sont diluées dans l'indentation, et je suis incapable de voir d'un coup d'oeil ce que fait ce bout de code.
Mais c'est donc officiel, c'est uniquement une question de goûts.
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par David Sporn (site web personnel) . Évalué à 6.
Et puis il finallement cela aère le code. Cela a l'air de rien pour un bête "while (1)" mais quand la condition est très longue d'une part, et que d'autre part on limite la longueur des lignes de code, la ligne while s'étend sur plusieurs ligne, et l'accolade devient beaucoup moins visible :
//j'exagère... à peine
while ((condition 1 && condition 2)
......|| condition 3 || (condition 4 && condition5
......&& condition 6 && condition 7)) {
......faisUn(truc) ;
......etEncore(un_autre) ;
......caVousAPlu(on_continue);
}
//Plus plausible : une indentation différente
//indente plus la condition
while ((condition 1 && condition 2)
............|| condition 3 || (condition 4 && condition5
............&& condition 6 && condition 7)) {
......faisUn(truc) ;
......etEncore(un_autre) ;
......caVousAPlu(on_continue);
}
//Plus plausible bis: une indentation différente
//indente plus le code
while ((condition 1 && condition 2)
......|| condition 3 || (condition 4 && condition5
......&& condition 6 && condition 7)) {
............faisUn(truc) ;
............etEncore(un_autre) ;
............caVousAPlu(on_continue);
}
//Avec retour chariot avant
while ((condition 1 && condition 2)
......|| condition 3 || (condition 4 && condition5
......&& condition 6 && condition 7))
{
......faisUn(truc) ;
......etEncore(un_autre) ;
......caVousAPlu(on_continue);
}
[^] # Re: Saut de ligne avant l'accolade.
Posté par Gilles Crebassa . Évalué à 1.
comme ca, tous le monde est content , non ?
C'est qui code en java ne code pas pareil qu'en C++ parce que les standards ont voulu que ce soit differents et tous les bouquins qui parlent d'un language commence toujours par les standards utilisés par le devel et le language utilsé.
Ou alors, les exemples sont implicitement fait pour en utiliser un nouveau.
Rien qu'en regardant le formatage du code, on devine si c'est un spécialiste en c /java/perl/python/<language à vous>.
[^] # Re: Saut de ligne avant l'accolade.
Posté par David Sporn (site web personnel) . Évalué à 3.
Il faudra forcément convenir d'une convention commune à toute l'équipe.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Alex G. . Évalué à 1.
[^] # Re: Saut de ligne avant l'accolade.
Posté par David Sporn (site web personnel) . Évalué à 1.
[^] # Re: Saut de ligne avant l'accolade.
Posté par moksha . Évalué à 2.
[^] # Re: Saut de ligne avant l'accolade.
Posté par sanao . Évalué à 2.
Plus sérieusement, je trouve un code plus clair lorsqu'il n'est pas "compacté sur un timbre poste. Certains m'objecterons que l'on a n'a pas tous sous les yeux, mais je fait toujours en sorte d'avoir des fonctions/méthodes les plus courtes possibles (pas plus de 50 lignes). Dans ces conditions, on a tout sous les yeux.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 2.
Avec ce saut de ligne, je trouve qu'on l'écartèle, le rend bancal, qu'il est en déséquilibre et manque s'effondrer à chaque instant.
Sans ce saut de ligne, je le trouve cohérent, solide, construit, clair.
Après, je met des sauts de lignes dans mon code comme j'en met dans mes textes écrits : pour séparer des parties formant une entité de sens ou de raisonnement, pour marquer une étape du raisonnement (ou de l'algorithme).
La version « trollesque » c'est que je ne met pas des espaces n'importe où pour le plaisir d'en mettre, mais juste où il faut pour que le code soit clair et compréhensible.
« mais je fait toujours en sorte d'avoir des fonctions/méthodes les plus courtes possibles »
Là au moins on est d'accord.
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par sanao . Évalué à 1.
if(tata == tyty) { titi(); } else { toto(); }Idem pour les switch :switch(tata) { case 0: { titi(); break; } case 1: { tutu(); break; } default: { toto(); break; } }Sans les accolades je trouve cela moins évidents à voir. Maintenant, c'est une affaire de goût. PS : Oui, je sais, je manque d'imagination dans mes noms de fonctions.[^] # Re: Saut de ligne avant l'accolade.
Posté par CrEv (site web personnel) . Évalué à 7.
while(1) { malloc(1); fork(); }Dans ce cas, while et {} ne sont pas sur la même colonne et n'ont donc normalement pas le même sens. (en fait on se demande même que vienne foutre ses accolades ici, en plus de rajouter des indentations...)
Cette syntaxe est, en tout cas pour moi, assez perturbante et illisible (surtout si on enchaine les niveaux)while(1) { malloc(1); fork(); }Dans ce cas le début du bloc estwhile(1) {et la fin la deuxième accolade. Le bloc est donc parfaitement lisible Ce type de construction se rapproche en fait d'un et enfinwhile(1) { malloc(1); fork(); }Ce cas est à mon sens le plus lisible car on a pas une { qui perturbe. Le bloc est signalé en fait quasiment que par l'indentation, l'accolade fermante signale bien la fin mais sert pas à grand chose (on se rapproche un peu plus du style python mais c'est pas encore ça) Dans ce style on repère bien le début (while(1) {) et la fin du bloc (}) et le bloc est mis en évidence par l'indentation Tant que possible j'utilise cette troisième méthode. Un commentaire plus haut disait : Mais dans les deux cas il faut bien le lire le while, if ou for (car sans cela le bloc ne sert pas à grand chose... Enfin voilà, il faudrait que je retrouve le passage exact du bouquin, c'était bien expliqué car ne rentrait jamais dans des considérations "graphiques", de lisibilité mais s'attachait uniquement au sens. Pour finir sur des considération de style par contre, rien n'empèche de mettre les accolades en fin de ligne et de passer des lignes dans le code. Ce style permet d'écrire aussi aéré que les accolades en début de ligne, l'inverse n'étant pas valable... ps : On retrouve souvent chez les personnes écrivant avec les accolades en début de lignes des choses du genre alors qu'elles écriraientif(null == monpointeur) { fairececi(); etcela(); }Alors que les personnes écrivantif(null == monpointeur) { fairececi(); etcela(); }écrivent plus souventif(null == monpointeur) { fairececi(); }(cette dernière syntaxe ayant comme avantage de pouvoir rajouter très facilement "etcela();") Et enfin dans le genre très perturbant à mon avis :for(int i = 0, monautrevar = -1; i < masupercondition; i++, monautrevar++) try { // quelques // lignes // de // code } catch(...) { MessageBox("plop"); }a peluche[^] # Re: Saut de ligne avant l'accolade.
Posté par CrEv (site web personnel) . Évalué à 2.
/me s'enfuie apprendre l'usage des balises html
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 2.
Ca rejoint pas mal un truc que j'ai écrit un peu plus haut : on met des espaces là où ça fait du sens, on n'en met pas là où ça n'apporte pas d'information pertinente.
Mais bon, le plus important c'est de rester cohérent dans son programme, et donc de fait, de se faire une opinion sur cette question, ou à tout le moins de choisir une fois pour toutes. Et dans le cas d'un projet collaboratif, de fixer ces règles au début.
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Joël SCHAAL . Évalué à 2.
while(1){
....// code
}
Les deux cas qui montrent le côté bancal de cette notation sont les suivants d'après moi :
for(int i = 0, monautrevar = -1; i < masupercondition; i++, monautrevar++) try
....// quelques
....// lignes
....// de
....// code
}
catch(...)
{
....MessageBox("plop");
}
ainsi que :
while ((condition 1 && condition 2)
....|| condition 3 || (condition 4 && condition5
....&& condition 6 && condition 7)) {
....faisUn(truc) ;
....etEncore(un_autre) ;
....caVousAPlu(on_continue);
}
Dans ces deux exemples, on ne voit pas bien les débuts de blocs.
Dans le premier cas on croit que le début de bloc est for alors que c'est en fait try
Dans le deuxième cas, l'indentation ne permet pas de distinguer le début du bloc de la fin de la condition. Il faut regarder la première ligne qui ne commence pas par un opérateur pour pouvoir déterminer le début du bloc de code.
Et si en plus de cela on est dans ce cas :
while ((condition 1 && condition 2)
....|| condition 3 || (condition 4 && condition5
....&& condition 6 && condition 7)) {
....++i;
....faisUn(truc) ;
}
On pourrait confondre, en lisant un peu rapidement, la première ligne de code du bloc avec la fin de la condition.
Une variante de cet exemple serait le cas suivant :
unObjetAvecUnNomAssezLong.quiFaitQuelqueChose(avec,beaucoup,
....de, parametres);
if(monTest) {
....// du code
}
Personellement, quand je lis ce code en me disant 'Attention les accolades sont en fin de ligne', j'ai tendance à prendre la première instruction pour un début de bloc. Tandis que si je sais que le début d'un bloc sera clairement marqué par une accolade, je saurais directement que ce n'est qu'une ligne un peu longue qui est séparée en deux.
Après, je comprends que ce sont des cas qui ne justifient pas une occupation d'espace plus grande pour certains. Mais pour moi, ces cas reviennent assez souvent pour préférer l'autre notation, quitte à perdre un peu de place. Et je trouve que scroller n'est pas aussi fatiguant que lire du code 'ramassé', mais ca, bien évidemment, c'est tout à fait subjectif.
P.S.: désolé pour la mise en forme avec les points, les tabulations ne fonctionnaient pas chez moi...
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 3.
Au niveau du sens on a qu'il y a une boucle, et qu'on teste les erreurs dans l'exécution des éléments de la boucle.
A mon avis on aurait pu mettre ça aussi :
for(i=0; i<10; i++) {
....try {
........malloc(1);
........fork();
....} catch {
........fprintf(stderr, "Je meurs !\n");
........exit(0);
....}
}
Ceci dit, lui il dit de la notation de son dernier exemple « Et enfin dans le genre très perturbant à mon avis », j'étais aussi d'accord avec cette phrase, j'aime pas cette façon d'écrire, c'est mieux comme j'ai fait plus haut !
Pour le deuxième exemple que tu proposes tu y as fait des choix douteux qui couplés avec l'accolade sur la ligne du « while » donne un résultat peu clair.
Ecrit plutôt comme ça, en alignant les éléments de la condition du « while » les uns avec les autres :
while ((condition 1 && condition 2)
..............|| condition 3 || (condition 4 && condition5
..............&& condition 6 && condition 7)) {
....++i;
....faisUn(truc) ;
}
De manière générale toute instruction simple qui doit s'écrire sur plusieurs lignes va être moins lisible que si elle était écrite sur une seule. Mais on n'a pas toujours le choix, surtout si on met des noms de variable à rallonge et qu'on reste quand même avec une limite à 80 colonnes pour la lisibilité.
Pour le troisième exemple par contre, je ne vois aucun problème de lisibilité, au pire on a l'impression qu'il y a deux blocs qui se suivent, mais jamais qu'il y a un bloc qui commence sur l'objet et termine sur l'accolade, pour la simple raison qu'il y aurait alors un élément non indenté en plein milieu et que c'est évidemment impossible si l'indentation est correctement faite. Et si elle ne l'est pas c'est normal que ça soit illisible, ou au moins ça n'est pas surprenant.
« Et je trouve que scroller n'est pas aussi fatiguant que lire du code 'ramassé', mais ca, bien évidemment, c'est tout à fait subjectif. »
Ouaip, les goûts de chacun. Je suis rapidement arrivé à la conclusion que ces différentes notations étaient une pure question de goût.
Ce qui me rebute dans le fait de scroller c'est que j'ai un effort à fournir pour pouvoir tout lire, si il n'y a pas besoin de scroller, la fenêtre d'édition est toujours bien centrée, il suffit de bouger les yeux, et quand tu passes d'une fenètre à une autre, il n'y a pas d'effort à faire pour savoir si on est au début ou à la fin de la fonction.
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Joël SCHAAL . Évalué à 2.
Concernant le deuxième exemple, ca me paraissait illogique d'indenter le code de cette manière, mais finalement c'est ce qui rend le mieux. Ce qui me semblait surtout illogique, c'était que la suite de la condition est plus 'distante' (2 tabulations) du while que les instructions. Mais comme dit, au final ca rend bien.
Enfin pour le 3e exemple, je voudrais juste un peu reprendre mon propos, parce que je crois que ce n'était pas clair. Lorsque je lis les deux premières lignes, je ne vois pas tout de suite que ce n'est pas un bloc. En effet, je dois soit :
- lire la ligne suivante pour voir l'indentation ou la (non) présence d'une accolade.
- 'analyser le premier token' (hum, ca fait très compilo comme remarque, mais j'ai pas trouvé mieux) afin de déterminer si on est dans le cas d'une ouverture de bloc.
Pour moi ces deux solutions necessitent plus d'effort que de simplement vérifier si le premier caractère n'est pas une accolade.
Bon après, je dis pas qu'il n'y a pas de mauvaise volonté dans tout ça (habitude, quand tu nous tiens !) et que ce qui me parait plus fatiguant ne l'est pas une fois qu'on y est habitué.
Par contre ton dernier paragraphe j'ai pas trop compris, désolé...
Ce qui te rebute c'est que tu n'arrives pas à tout lire ? Mais est-ce que ce n'est pas plutot la fonction qui est trop grande ? je pense que dans une fenêtre tu ne dois pas gagner plus de 10 lignes en moyenne en passant d'une notation à une autre. Faudrait tester... Pour le passage d'une fenêtre à une autre, j'ai pas compris (Page Up / Page Down ?) ni le centrage de la fenêtre d'édition.
[^] # Re: Saut de ligne avant l'accolade.
Posté par CrEv (site web personnel) . Évalué à 1.
Justement, c'est pour ça que j'ai mis cet exemple, précédé de :
C'est justement un contre exemple (mais qui marche qu'on mette les accolades en début ou fin de ligne, c'est nul dans les deux cas)
J'ai trouvé cet exemple, ainsi que des
Et c'est tellement pourri comme type de code que je voulais le dénoncer haut et fort !! ;-)
[^] # Re: Saut de ligne avant l'accolade.
Posté par Alexandre CABROL PERALES . Évalué à 1.
pour ma part je préfére la vieille méthode
if(toto=titi)
{
try
{
//test
}
catch(exception)
{
//traitement
}
}
else
{
//code
}
Mais si j'ai mit cette méthode d'indentation c'est parcequ'elle est définit comme ça dans la GNU CODING STANDARD ACTUELLE.
J'ai noté aussi que ce sont les langages de haut niveau tel que Java .Net ou Php qui favorisent la nouvelle écriture alors que les langages plus anciens comme C C++ PASCAL DELPHI favorisent plus l'ancienne écriture. Etant dans un objectif d'introduction à des standards pérennes j'ai opté naturellement pour la notation la plus répendu et la plus ancienne.
De la même façon le SVNBOOK insiste sur l'utilisation du standard TRUNK,TAGS,BRANCHES utilisé par CVS alors que ce n'est pas obligatoire lorsque l'on utilise Subversion.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Alexandre CABROL PERALES . Évalué à 1.
L'objectif étant de faire un résumé des standards de façon générique, le français n'est pas trés approprié pour un standard.
Toutefois l'O.S.T.D.C. étant sous license CC-BY-SA n'importe qui peut le traduire de façon officiel dans la langue souhaité. C'est aussi pour ça que c'est fait.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . Évalué à 2.
Yth.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Sylvain Sauvage . Évalué à 2.
Il y en a aussi certains qui impriment souvent et d'autres rarement…
[^] # Et puis vous vous sur troller le cerveau
Posté par gael s. . Évalué à 1.
ctrl_A suivi de ctrl_shift_f avant de commiter.
tant que l'équipe à la meme conf.
tout va bien.
et on s'prend plus la tête.
[^] # Re: Et puis vous vous sur troller le cerveau
Posté par François B. . Évalué à 1.
Sinon, pour que tout le monde ait la même configuration de formatage, on peut maintenant partager cette config dans les propriétés du projet. Je ne sais plus exactement depuis quand on peut le faire, ça doit être autour de la 3.1.
Enfin, on peut aussi rajouter le plug-in checkstyle à eclipse pour qu'automatiquement on ait des alertes à chaque "erreur de style" (qui peut être du formatage, mais aussi des utilisation de méthodes interdites, des constructions risquées, du code mort...)
# Spécificité open source ?
Posté par Taku . Évalué à 3.
Juste une question bête ( mais bon je tente toujours, au risque qu'on me dise "comment peut-il te venir à l'idée de ne pas développer seulement de l'open-source ? ) : cette introduction est-elle relative au développement en équipe, spécifiquement open-source, ou bien relative au développement en équipe ?
Autrement dit, y aurait-il des raisons pour ne pas pouvoir/devoir déployer les méthodes enseignées ou indiquées dans le cadre de projet non-open-source ?
[^] # Re: Spécificité open source ?
Posté par Alexandre CABROL PERALES . Évalué à 3.
Mais ces standards peuvent trés bien être utilisé dans un cadre propriétaire.
Ce ne sont que des conseils et les conseils peuvent s'appliquer dans un cadre closed source ou open source.
Pourquoi l'open source est plus interessant que le closed source dans le développement en équipe?
Tout simplement parceque l'open source soriente vers un code lisible et réutilisable par le plus grand nombre.
Mais je suis persuadé qu'utiliser des méthodes open source éprouvé à l'international pour un projet propriétaire peut apporter beaucoup à la gestion et la maintenance du code.
J'espére avoir répondu à la question correctement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.