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

Posté par  . Modéré par Nÿco.
Étiquettes :
0
22
nov.
2006
Doc
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. 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

  • # PDF

    Posté par  (site web personnel) . Évalué à 4.

    Hello,

    une version PDF est-elle dispo? (pas vu, mal vu?)
    • [^] # Re: PDF

      Posté par  . Évalué à 1.

      Une version pdf serait plus que la bienvenue!!!
      • [^] # Re: PDF

        Posté par  . Évalué à 1.

        je vous prépare ça desuite
        • [^] # Re: PDF

          Posté par  . É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.
        • [^] # Re: PDF

          Posté par  . É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  (Mastodon) . É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  (Mastodon) . É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  (site web personnel) . É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  (Mastodon) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (Mastodon) . É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  . É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  (site web personnel) . É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.
        • [^] # Re: Saut de ligne avant l'accolade.

          Posté par  (Mastodon) . É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  (site web personnel) . É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  (site web personnel) . É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.
              • [^] # Re: Saut de ligne avant l'accolade.

                Posté par  (Mastodon) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  (Mastodon) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (Mastodon) . É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  . É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  (Mastodon) . É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  . É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  (site web personnel) . É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  . É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.
    • [^] # Re: Saut de ligne avant l'accolade.

      Posté par  . É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.
    • [^] # Re: Saut de ligne avant l'accolade.

      Posté par  . É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  . É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  . É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  . É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 ?
    • [^] # Re: Spécificité open source ?

      Posté par  . É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.

Suivre le flux des commentaires

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