Voila un post qui peut etre sympa si tout le monde s'y met.
Je m'explique : je ne supporte pas le code mal indenté, car je trouve qu'il est bcp moins lisible. Et Les gens qui font ça pour 'economiser' des lignes, je leur rie a la gueule. Apres, yen a d'autre, c parce qu'ils preferent. Là c chacun ces gouts.
Genre :
public int somme(int x, int y)
{
    return (x+y);
}
 
voila ça j'aime bien
public int somme(int x,int y){
    return x+y;
}
 
çà je trouve que c bcp moins lisible.
c pareil pour tout les blocs d'ailleurs; j'a

meeerrrde
bref pour tout les blocs, j'aime bien quand l'accolade est a la ligne au dessous, au meme niveau puis les lignes qui suivent sont indentées. Je trouve ça plus lisible.
 
Et vous, c quoi votre opinion ?

Moi j'ai toujours codé comme ton second exemple, mais maintenant que d'autres doivent lire le même code, je me suis mis à la première méthode.

La premiere methode est mieux, car quand tu as plein de blocs imbriques, tu vois tout de suite comment tout s'organise...
 
et d'ailleurs a ce propos emacs rulez -> de loin le meilleur editeur decode, meme s'il lui manque des facilites que d'autres ont (comme VC++ ou CW ou tu peux sauter directement a une fonction donnee, voire le prototype automatiquement quand tu fais un appel a une fonction...).

1ere methode meme si sun recomende la 2eme

c fou, tout le monde est d'accord avec moi, mais personne le fait ; je tombe toujours sur code sale... du coup, je passe 1/2 heure a le mettre en page avant meme d'essayer d'en lire une seule ligne ...

moi je fais comme ca :

 
parcontre tu as oublié encore une autre solution encore pire :  
 
public int somme(int x,int y){ return x+y; }

La première Méthode parce que c'est plus claire quand effectivement tu as plusieurs blocs imbriqués.

y'a celui là aussi :
 
public int somme(int x, int y)
{
    return (x+y);}
 
moi je le trouve lisible.

Pour être plus lisible, moi je fais ainsi :

 
Toutes mes variables sont "préfixées" de leur type.
 
Pour le fun, j'avais vu il y a qq temps des codes intentionnellement obscurs, un concours étant même organisé tous les ans. Un des must était un code qui s'exécutait en C et en Bash sans erreur.
Si je le retrouve je le poste.
A+

Perso
 
public CMyClass::m_fniSomme(int iX, int iY) {
     return (iX + iY);
}

[edit]--Message édité par VisualC++--[/edit]

[nom]lamatrice[/nom]
[citation]
y'a celui là aussi :  
 
public int somme(int x, int y)  
{  
    return (x+y);}  
 
moi je le trouve lisible.[/citation]
 
le pb de cette solution c'est qu'on ne voit pas la fin du bloc (c genant qd yen a plusieurs d'imbriqués).
par contre, moi aussi je fais
if (truc)
    exe;
else
    autre;
 
je met pas d'accolade qd il n'y a qu'une seule instruction. (faut pas exagerer non plus)

Moi je préfère comme le premier exemple (et c'est ce que je fais d'ailleurs). Je pousse même le vice à séparer toutes mes opérandes de mes opérateurs par un espace et à mettre les virgules d'une certaine façon:
 
a = b + c;
 
public int somme (int x, int y, byte z)
{
  int resultat = x + y + (int) z;
 
  return resultat;
}
 
Ah oui j'ai oublié de dire: toujours une ligne vide avant le return et à chaque fois que je le sens dans mon code (notion différente, séparation de tâches (dans une même méthode, ...)
 
+ des COMMENTAIRES sur 12 lignes si j'estime çà nécessaire et celui à qui çà plait pas il a qu'à pas les lire

mmmm les commentaires... ça aussi j'utilise avec attention, car trop de commentaires alourdissent le code pour pas gd chose. Moi j'en met que pour des cas specifiques, sinon apres c de la paraphrase qui alourdissent.

Ouais ben j'ai déjà eu à reprendre du code à quelqu'un et t'es bien content de les avoir.
De toute façon, ca change juste la longueur du fichier et ca tu t'en fous. Ca passe direct à la trappe à la compil.

bah je dis pas le contraire, mais les trucs styles :
//x reçoit 1
x = 1;
 
bin c pourri

J'ai dit commentaires, pas crétineries

et dans la serie je veux que mon code soit (il)lisible
 
// definit le type INTEGER comme un type 'int' standard
#typedef int INTEGER;
 
// definit la variable INTEGER_i, qui est equivalente au type int (cf au dessus).  
// 1 est normalement un INTEGER (enfin un int), mais je precise que c'est un INTEGER des fois que le compilo me fasse des ennuis
INTEGER INTEGER_i= (INTEGER) 1;

Perso, si y a pas de spécifs, je fais comme ça :
 

 
mais en général, il faut toujours revenir à la ligne avant un {, ce que je fais sauf pour les if.

et pourquoi sauf pour les if ?

Moi j'aime bien l'indentation de l'editeur Grasp.
Il est vraiment bien fait !
 
Il gere le C/C++, pour le Java etc...
 
Et je prefere :
 
int toto()
{
   return 1;
}
 
Br@scoo

Dans JBuilder, tu peux lui dire un peu ton style? C'est pas mal mais ca pourrait être beaucoup plus précis.
Et puis il complète automatiquement les noms de fonctions: c'est pratique mais ca peut être très casse cou_lles quand il te met les parenthèses collées et vides si tu les préfères séparées et avec des paramètres ...

petoulachi a écrit a écrit : et pourquoi sauf pour les if ?

 
Le code est trop dispersé pour être lisible. On peut melanger avec un simple bloc imbriqué.

assez proche de nomad, mais j'indente un peu plus pour les conditions:
function cible(targ1,targ2)
 {
  if (targ1!=''&& targ2!='')
   {
   parent.leftFrame.location=targ1;
   parent.mainFrame.location=targ2;
   }
 }
Les accolades sous le if sont au même niveau pour eviter les erreurs si il y en a plusieurs, (comme je débute.. )

[edit]--Message édité par LeMegaBlaireau--[/edit]

moi en C/C++ j'ai tendance à faire des truc du genre
void fonction(int x, int y) {
   if(a) {
      ...
   } else {
      ...
   }
}
sinon en Delphi:
function fonction(x: integer; y: integer);
begin
   if a then
   begin
      ...
   end else
   begin
      ...
   end;
end;
et j'essaie de tj mettre les begin et end pcq sinon je me fais avoir à laisser un ; là où il faut pas.

[edtdd]--Message édité par antp--[/edtdd]

coucher et a l'envers

et ben moi je fais des trucs du style:
 
function rien(){
///////debut de la fonction rien()/////////////
 
for(i=0;i<12;i++){
                 if(i>=3){
                         j=36;l++;}
                               else{kedal[i]=2}
                                               }
///////////////fin de la fction riezn()////////////////////////
}
 
des fois ca prend des kilometres mais moi jje mi  retrouve:-))

petoulachi> L'indentation du code est quelque chose de très important. Mais une mauvaise taille d'indentation peut aussi rendre illisible. Des enquêtes sur le sujets ont montré que le meilleur compromis était 3 ou 4. 8 étant beaucoup trop, et 1 ou 2 pas assez. Par ailleurs, augmenter la "profondeur" du code (i.e. avoir un grand niveau d'instructions imbriquées) rend le code difficile à lire ; en général, à partir de 4 ou 5, ça commence à faire déjà beaucoup et il vaut mieux découper en 2 sous-routines.
 
Maintenant, dans ton premier exemple, plusieurs enquêtes ont montré que le premier code était meilleur du point de vue lisibilité, par ce qu'il implémentait la notion de bloc abstrait :

 
Par contre, les exemples d'indentation donnés par darkoli sont assez mauvais, car ils sont trompeurs : l'accolade fermante du then n'appartient pas au premier sous-bloc du if, mais au if lui-même. Idem pour celle du else.
Le problème de C, C++, Java et Pascal, c'est que certaines accolades (ou couples begin / end) sont parfois plus gênants qu'autre chose (essentiellement pour le if, d'ailleurs).

 
Et contrairement à beaucoup de personnes, je pense que l'opérateur ternaire de C, utilisé à bon escient, peut être plus facile à lire qu'un if classique :

Une des conditions pour qu'il reste lisible est que les 2 valeurs possibles pour la variable à laquelle une affecte une valeur restent simples à exprimer (en particulier, j'évite les new Machin()).
 
djfm> Désolé, mais ton code est très difficile à relire. On ne sait pas où se terminent tes if, tes for, etc. Or c'est précisément le but de la présentation du code : montrer visuellement la structure du code sans obliger le lecteur à lire chaque ligne de code.  
A mon avis, ce qui suit est un peu meilleur :

Sans compter que les noms de variables choisis ici sont à sauter au plafond...  

[edit]--Message édité par BifaceMcLeOD--[/edit]

men fous, y a ke moi ki les relis ;-))
oui je c c pas facile, mais g labitude de fere comme ca

 
Tu peux faire ça avec emacs, regarde du coté de CTAGS et speedbar

un lien que quelqu'un a donné sur ce forum il y a quelques mois :
 
http://www.mindprod.com/unmain.html
 
très instructif et très marrant

voici comment je code un if par exemple:
 
if ( (a == 1) && (b == 2) && (c == 3) )
{
     printf("test\n" );
}
 
remarquez l'espace aux extrémité:
if ( (a == 1) && (b == 2) && (c == 3) )
 
 
et puis des fois je ne met pas les {} pour une seule instruction mais lorsque je rajoute une ligne de plus, j'oublie de les mettres les {}  

[edit]--Message édité par End-i--[/edit]

End-i> Preuve qu'il vaut mieux toujours mettre des accolades ouvrantes et fermantes.    
 
Pour ton if, moi, je préfère :

Je sais, le coup des doubles espaces entre les conditions élémentaires, c'est bien peu orthodoxe, mais c'est ce que j'ai trouvé de mieux pour avoir un code le plus léger possible (les parenthèses alourdissent vite), tout en étant capable de repérer rapidement les conditions élémentaires (sans avoir besoin de faire l'effort de les lire, comme toujours)

comment je programme ? ... bien
 

c'était ma tartine. je veux en lire d'autres !

Justement, pas en anglais...
 
youdontcare> Pourquoi ton opérateur ternaire ne compile pas ?  

BifaceMcLeOD a écrit a écrit :   Justement, pas en anglais...   youdontcare> Pourquoi ton opérateur ternaire ne compile pas ?

damn ! j'étais pourtant sûr que c'était universel le double espacement pour les ponctuations avec deux signes ...
 
pour le ?, j'ai réessayé, ça compile ... cool j'avais dû essayer ça une nuit de fatigue totale.

youdontcare  

[edit]--Message édité par LeMegaBlaireau--[/edit]

Comme tout le monde met des bouts de code, j'en fait autant !
 
<?
// affichage des lignes du formulaire //
class FormLine {
 var $classname= "ligne";
 var $nom; // le nom du champ
 var $type; // le type de champ (menu déroulant, checkbox, champ texte etc...)
 var $size; // la longueur des champs texte
 var $option;  // les options à afficher pour les menus déroulants
 var $invalide; // ce qui rend le champ non valide (longueur 0 ou valeur de champ)
 var $obligatoire; // prend la valeur 1 pour obligatoire et affiche la coche bleu.
 var $value; // la valeur du champ
 
 function ligne($val1, $val2, $val3, $val4, $val5, $val6, $val7){
   $this->nom = $val1;
   $this->type = $val2;
   $this->size = $val3;
   $this->option = $val4;
   $this->invalide = $val5;
   $this->obligatoire = $val6;
   $this->value = $val7;
   ?>
  <tr>
    <td width=30" align="center" height="30"><? if ($val6==1) { echo "<img src=\"img/coche.gif\" width=\"21\" height=\"21\">"; }
      else { echo " "; } ?>
    </td>
    <td width="150" height="30"><? echo "$val1"; ?> :</td>
    <td width="69%" height="30">
      <?
if ($val2=='select') {
  echo "<select size=\"1\" name=\"$val1\" tabindex=\"1\">";
  $options = explode("-",$val4);
  while(list(,$option) = each($options)) {
    if ($option==$val7) {
      echo "<option selected>$option</option>\n";
    }
    else {
      echo "<option>$option</option>\n";
    }
 
  }
  echo "</select>";
}
 
elseif ($val2=='textarea') {
  ?><textarea name="<? echo "$val1"; ?>"><? if (isset ($val4)) echo "$val7" ?></texarea>
<?
}
else {
echo "<input type=\"text\" size=\"$val3\" name=\"$val1\" value=\"$val7\">";
}
?>
     </td>
   </tr>
<?
   }
}
// fin //
?>
 
Perso je préfèe les commentaires à droite de la ligne, mais je ne fait que du php  

[edit]--Message édité par Sh@rdar--[/edit]

c'est marrant en php j'ouvre une bonne fois pour toutes le code avec <? et tape tout dedans. n'importe quel bout d'html statique, par ex pour commencer une table, passe par un echo ... peut être plus lent certes, mais tellement plus pratique et lisible

bin moi ça dépends des fois ;-)
 
je trouve plus lisible ma page HTMl avec le code php dedans, toi tu fais l'inverse : de l'HTML dans du PHP