jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Développeur

[10] Cooki3d : une première version GNU/GPL
[18] Nomination pour les Trophées du Libre
[48] D-Bus 1.0, future fondation de nos bureaux
[127] Java libre : un rêve devient réalité
[4] Base audio libre de mots chinois
[137] Mono passe en version 1.2
[31] Naissance du projet Armadeus
[0] Qt Jambi technology preview et concours
[0] Conférence PHP Québec 2007 : Appel aux conférenciers
[33] Lancement du projet GlobalGCC

Liens connexes

Time Breach (713 hits)
Mediabox404 (182 hits)
Labo-Linux (225 hits)

Dépêche modérée par

Nyco

Dépêche éditée par

Développeur : O.S.T.D.C. une introduction au Développement en équipe

Posté par Alexandre CABROL PERALES (page perso, ). Modéré le 22 novembre 2006.

O.S.T.D.C. pour Open Source Team Development Chart , autrement dit le développement open source en équipe pour les nuls.

Ce petit ouvrage devrait permettre à ceux qui souhaitent se lancer dans le développement open source de partir sur de bonnes bases.

Time Breach (713 hits)
Mediabox404 (182 hits)
Labo-Linux (225 hits)

> Lire la dépêche (44 commentaires, moyenne: 2,5).

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.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

PDF

Posté par wwp (page perso, ) le 22/11/2006 à 10:09. (lien). Évalué à 4.

Hello,

une version PDF est-elle dispo? (pas vu, mal vu?)

[^]Re: PDF

Posté par Axel () le 23/11/2006 à 08:02. (lien). Évalué à 1.
Une version pdf serait plus que la bienvenue!!!
- [^]Re: PDF
  
  Posté par Alexandre CABROL PERALES (page perso, ) le 23/11/2006 à 08:42. (lien). Évalué à 1.
  je vous prépare ça desuite
  
  --
  Kalden Time Breach Project Manager
  http://TimeBreach.SourceForge.net
  - [^]Re: PDF
    
    Posté par Alexandre CABROL PERALES (page perso, ) le 23/11/2006 à 10:21. (lien). Évalué à 1.
    en y regardant de plus prêt sur le site Time Breach, sur la page O.S.T.D.C., tout en bas vous avez un ptit logo pdf qui vous permet de générer un .pdf du document.
    
    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.
    
    --
    Kalden Time Breach Project Manager
    http://TimeBreach.SourceForge.net
    - [^]Re: PDF
      
      Posté par wwp (page perso, ) le 23/11/2006 à 14:53. (lien). Évalué à 1.
      Merki!
  - [^]Re: PDF
    
    Posté par syntaxerror () le 23/11/2006 à 10:44. (lien). Évalué à 1.
    Merci, c'est tout de suite plus lisible (et d'ailleurs on remarque tout de suite mieux le troll caché dans le document ;-)
    
    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 (Jabber id, ) le 22/11/2006 à 11:07. (lien). Évalué à 4.

Salut,

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 (Jabber id, ) le 22/11/2006 à 11:08. (lien). Évalué à 2.
Avec les indentations...

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 (Jabber id, page perso, ) le 22/11/2006 à 11:25. (lien). Évalué à 1.
  On peut même pousser en trollant discutant du gain de lisibilité qu'il y aurait si les blocs étaient formés par l'indentation et non pas par les accolades, comme par exemple en python.
  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 (Jabber id, ) le 22/11/2006 à 14:46. (lien). Évalué à 2.
    En fait, pour la lisibilité, les blocs doivent être fait avec l'indentation, les accolades sont là pour le compilateur, mais si l'indentation est faite n'importe comment, de toute manière on lutte pour savoir où commencent et finissent les blocs.
    
    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 yann degat () le 23/11/2006 à 13:48. (lien). Évalué à 1.
      en ada, tu peux demander au compilateur de pas compiler si les règles d''indentation sont pas respectées.
      
      ça inclut le nb de ligne par procédure et celui par fonction
  - [^]Re: Saut de ligne avant l'accolade.
    
    Posté par Jean-Philippe (page perso, ) le 22/11/2006 à 18:55. (lien). Évalué à 5.
    Tu aurais pu être un peu plus pythonique dans ton code python, tu ne rend pas trop honneur à ce langage ici :)
    
    (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 (page perso, ) le 22/11/2006 à 11:26. (lien). Évalué à 2.
  Ce n'est qu'une question de convention.
  
  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 (Jabber id, ) le 22/11/2006 à 12:10. (lien). Évalué à 2.
    Oui, oui, je suis d'accord aussi, mais la question portait juste sur le fait de revenir à la ligne ou pas.
    
    Yth.
  - [^]Re: Saut de ligne avant l'accolade.
    
    Posté par Sylvain Sauvage () le 22/11/2006 à 12:46. (lien). Évalué à 5.
    Tant qu'on est sur les espaces, j'en mets un avant la parenthèse pour les mots-clefs, pour les différencier des appels de fonction :
    
    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 V. () le 22/11/2006 à 11:44. (lien). Évalué à 8.
  Perso ce serait plutôt :
  
  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.
  
  --
  Samuel V.
  Connaissez-vous les jeux d'aventure textuels (fictions interactives) ?
  Un des derniers jeux parus : Lieux Communs
  - [^]Re: Saut de ligne avant l'accolade.
    
    Posté par Yth (Jabber id, ) le 22/11/2006 à 12:36. (lien). Évalué à 3.
    Ben pour moi l'ouverture c'est l'instruction « while », c'est elle le sens du bloc.
    
    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 (page perso, ) le 22/11/2006 à 13:06. (lien). Évalué à 5.
      
      Ben pour moi l'ouverture c'est l'instruction « while », c'est elle le sens du bloc.
      
      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 V. () le 22/11/2006 à 13:27. (lien). Évalué à 6.
        Tout à fait, voilà qui explique avec des mots sensés ma préférence personnelle. Le but est de pouvoir parcourir le code du regard verticalement sans avoir à faire trop de lectures horizontales pour savoir si un bloc commence et pourquoi.
        
        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.
        
        --
        Samuel V.
        Connaissez-vous les jeux d'aventure textuels (fictions interactives) ?
        Un des derniers jeux parus : Lieux Communs
        
        [^]Re: Saut de ligne avant l'accolade.
        
        Posté par Yth (Jabber id, ) le 22/11/2006 à 13:56. (lien). Évalué à 4.
        dingue, moi c'est exactement l'inverse.
        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 (page perso, ) le 22/11/2006 à 13:29. (lien). Évalué à 6.
    Pour moi l'avantage de cette formulation (retour chariot avant l'accolade) c'est pour copier/coller/déplacer les accolades et leurs contenu.
    
    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 (page perso, ) le 23/11/2006 à 10:18. (lien). Évalué à 1.
      Pourquoi vous utilisez pas Astyle pour reformater le code comme vous le voulez ?
      
      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 (page perso, ) le 23/11/2006 à 14:07. (lien). Évalué à 3.
        Si chacun reformate à sa sauce du code géré par un gestionnaire de version (cvs, subversion, etc...), je te raconte pas le bordel pour repérer LA modification utile au milieu de toutes les modifications cosmétiques
        
        Il faudra forcément convenir d'une convention commune à toute l'équipe.
        
        [^]Re: Saut de ligne avant l'accolade.
        
        Posté par Alexandre Garel () le 23/11/2006 à 16:29. (lien). Évalué à 1.
        Moi je pense surtout qu'un belle amélioration serait que les outils CVS, subversion etc... n'utilisent pas un diff simple mais un diff qui serait spécialisé pour le code ! (bon ok c'est pas forcément simple).
        
        [^]Re: Saut de ligne avant l'accolade.
        
        Posté par David Sporn (page perso, ) le 24/11/2006 à 10:36. (lien). Évalué à 1.
        mouais, mais bon courage pour implémenter et maintenir le support de ***tous*** les langages de programmation, pour ne parler que des fichiers sources.

[^]Re: Saut de ligne avant l'accolade.

Posté par moksha () le 22/11/2006 à 12:26. (lien). Évalué à 2.
Je pense la même chose que toi. De plus on doit pas être les seul car il me semble que dans la doc du noyau linux, une section traite des conventions. Or il me semble que la convention pour l'indentation du while est celle que nous préférons :). A vérifier tout de même

[^]Re: Saut de ligne avant l'accolade.

Posté par sanao () le 22/11/2006 à 13:30. (lien). Évalué à 2.
Parce que le code c'est comme les animaux (homo sapiens compris), ça a besoin de respirer.

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 (Jabber id, ) le 22/11/2006 à 14:04. (lien). Évalué à 2.
  Le code peut « respirer », mais pas aux mêmes endroits.
  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 () le 22/11/2006 à 16:16. (lien). Évalué à 1.
    Perso, j'aime bien que les accolades soient alignées, ainsi dès qu'il y a un bloc d'instruction, je met des accolades, même si il n'y a qu'une seule instruction dans le bloc. Exemple :
```
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 (page perso, ) le 22/11/2006 à 14:07. (lien). Évalué à 7.
J'ai lu (il y a déjà un petit moment) un livre intitulé "tout sur le code" (chez crosoft press...) dont une partie traitait de l'épineux problème des accolades. A la différence de beaucoup d'autres discution sur le sujet, l'auteur se basait non pas sur l'espacement, la lisibilité mais sur le sens des blocs créés. Donc en gros trois manières :
```
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 est
```
while(1)
{
```
et la fin la deuxième accolade. Le bloc est donc parfaitement lisible Ce type de construction se rapproche en fait d'un
```
monbloc
BEGIN
	plop
	plop
END
```
et enfin
```
while(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
```
BEGIN mon bloc
	mon
	traitement
END
```
Tant que possible j'utilise cette troisième méthode. Un commentaire plus haut disait :
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.
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
```
if(null == monpointeur)
	fairececi();
```
alors qu'elles écriraient
```
if(null == monpointeur)
{
	fairececi();
	etcela();
}
```
Alors que les personnes écrivant
```
if(null == monpointeur) {
	fairececi();
	etcela();
}
```
écrivent plus souvent
```
if(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 (page perso, ) le 22/11/2006 à 14:09. (lien). Évalué à 2.
  (oups j'ai un peu loupé la mise en page...)
  /me s'enfuie apprendre l'usage des balises html
- [^]Re: Saut de ligne avant l'accolade.
  
  Posté par Yth (Jabber id, ) le 22/11/2006 à 14:30. (lien). Évalué à 2.
  Ouais, c'est bien expliqué ça. Et c'est d'accord avec moi en plus ^^ (pourquoi rater une occasion de flatter son ego ?)
  
  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 () le 22/11/2006 à 18:37. (lien). Évalué à 2.
    Ben justement, je trouve que son explication, associée a celle d'un commentaire précédent présente l'inconvénient de la notation
    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 (Jabber id, ) le 22/11/2006 à 20:00. (lien). Évalué à 3.
      Dans le premier exemple, le bloc est bien un bloc autour du « for », le « try » n'est qu'une surcouche.
      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 () le 22/11/2006 à 22:58. (lien). Évalué à 2.
        Je préfère également la manière dont tu as retranscrit la boucle et le try, c'est également la manière que je prendrais si je suivais cette notation. D'ailleurs CrEv l'a reprécisé plus bas, il n'a pas (du tout) l'air d'accord avec cette syntaxe. Soit. Ce n'était effectivement pas un très bon exemple. :)
        
        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 (page perso, ) le 22/11/2006 à 20:02. (lien). Évalué à 1.
      
      Dans le premier cas on croit que le début de bloc est for alors que c'est en fait try
      
      Justement, c'est pour ça que j'ai mis cet exemple, précédé de :
      
      Et enfin dans le genre très perturbant à mon avis :
      
      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
      
      if(...) try
      {
      ...// some code
      ]
      catch(...)
      [
      ...// come code
      }
      
      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 (page perso, ) le 23/11/2006 à 08:59. (lien). Évalué à 1.
        Bonjour,
        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.
        
        --
        Kalden Time Breach Project Manager
        http://TimeBreach.SourceForge.net

[^]Re: Saut de ligne avant l'accolade.

Posté par Alexandre CABROL PERALES (page perso, ) le 23/11/2006 à 09:06. (lien). Évalué à 1.
Actuellement aucune version française n'est prévu.

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.

--
Kalden Time Breach Project Manager
http://TimeBreach.SourceForge.net
- [^]Re: Saut de ligne avant l'accolade.
  
  Posté par Yth (Jabber id, ) le 23/11/2006 à 09:44. (lien). Évalué à 2.
  Justement, j'y songeais, mais j'ai préféré demander avant.
  
  Yth.

[^]Re: Saut de ligne avant l'accolade.

Posté par Sylvain Sauvage () le 23/11/2006 à 10:59. (lien). Évalué à 2.
En y repensant, j'ai l'impression que l'acuité visuelle du lecteur et la taille de la police utilisée (en mm) entrent aussi fortement en ligne de compte : quand c'est écrit plus petit, on en met moins par ligne et on aère plus (?).
Il y en a aussi certains qui impriment souvent et d'autres rarement…
- [^]Et puis vous vous sur troller le cerveau
  
  Posté par yann degat () le 23/11/2006 à 13:51. (lien). Évalué à 1.
  sous eclipse ou sous d'autres ide et pour presque tous les langages :
  
  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 BOTTIN () le 23/11/2006 à 14:25. (lien). Évalué à 1.
    Pour eclipse, il n'est pas nécessaire de sélectionner l'ensemble du fichier pour lancer le formatage. En revanche, si une partie seulement du contenu est sélectionnée, seule cette partie sera formatée.
    
    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 (page perso, ) le 22/11/2006 à 13:24. (lien). Évalué à 3.

Bonjour tous,

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 ?

--
Moi j'aime les fourmis !

[^]Re: Spécificité open source ?

Posté par Alexandre CABROL PERALES (page perso, ) le 23/11/2006 à 08:48. (lien). Évalué à 3.
En faite ce document se base sur des standards provenant de l'open source.

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.

--
Kalden Time Breach Project Manager
http://TimeBreach.SourceForge.net

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : O.S.T.D.C. une introduction au Développement en équipe

PDF

[^]Re: PDF

[^]Re: PDF

[^]Re: PDF

[^]Re: PDF

[^]Re: PDF

Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Re: Saut de ligne avant l'accolade.

[^]Et puis vous vous sur troller le cerveau

[^]Re: Et puis vous vous sur troller le cerveau

Spécificité open source ?

[^]Re: Spécificité open source ?