Bonjour à tous,

Ca pourrait être l'objet d'un débat, mais je voudrais surtout avoir votre avis. Dans quels cas utiliser (ou utilisez-vous) certains styles de codage plutôt que d'autres :

if ($foo == $bar) echo "foo bar";

$foo == $bar && echo "foo bar";

Dans le cas 2, j'ai remarqué plusieurs choses :

- en js, return à la place de echo dans l'exemple renvoie une erreur. A voir donc la raison (parce que mot clé ?)
- dans le cas d'un if, elseif, ce dernier s'arrête après avoir été évalué à vrai alors que le && non

Certainement plein d'autres trucs à dire. J'utilise beaucoup les if, et je me surprends des fois à coder avec && et ||. D'ailleurs pas mal de sources js les utilise. Dans quels cas ? Quelles restrictions ? Pourquoi ? Je suis tout ouï ...

Je trouve ta seconde méthode pas très lisible.
J'ai jamais eu à utiliser une telle écriture.

Une autre méthode si ça peut apporter de la diversité au débat :

echo ($foo == $bar) ? 'foo bar' : '';

Mais que je trouve bofbof, car cela impliquerai qu'on écrit du vide, donc qu'on fait quelque chose, en cas de test faux.

Dans le code, je privilégie la manière la plus lisible/intelligible plutôt que l'économie de caractères.

Le fait est qu'un bout de code sera bien plus souvent lu qu'écrit.

Dans le code, je privilégie la manière la plus lisible/intelligible plutôt que l'économie de caractères.

200% d'accord avec ça.
La 1ère syntaxe est intelligible même est la survolant alors que la seconde demande un petit effort supplémentaire de compréhension.

j'aime aucune des deux.

por moi une structure de contrôle ne peut pas se passer d'accolades, même si optionelles ça permet de garantir une lisibilité complête, ça et les opérateurs ternaires qui sont une hérésie quand on tient à la maintenabilité d'un code et un paquet d'autres choses comme ne jamais écrire un elseif parce que ca devrait être un switch, ne jamais mettre des return avant la fin d'une fonction, etc, etc.

Je trouve ta seconde méthode pas très lisible.
J'ai jamais eu à utiliser une telle écriture.

Une autre méthode si ça peut apporter de la diversité au débat :

echo ($foo == $bar) ? 'foo bar' : '';

Mais que je trouve bofbof, car cela impliquerai qu'on écrit du vide, donc qu'on fait quelque chose, en cas de test faux.

On peut tout à fait rajouter l'opérateur terniaire au "débat", mais comme tu le dis, il fait quelque chose quoi qu'il arrive. L'opérateur terniaire trouve naturellement sa place dans d'autres utilisations

Dans le code, je privilégie la manière la plus lisible/intelligible plutôt que l'économie de caractères.

Le fait est qu'un bout de code sera bien plus souvent lu qu'écrit.

Bien que j'utilise JSON pour le transfert de données, d'une part parce qu'il est plus "natif" (typage des données) et plus petit en taille, il ne me viendrait pas à l'esprit de l'utiliser pour écrire avec. Je me pencherais sur XML qui est plus verbal et donc plus facile à maintenir, plus lisible. Aucun débat là dessus, juste effectivement la lisibilité du code est ultra importante, et c'est à mon sens, ce qui pousse à utiliser l'objet plutot que le procédural, alors qu'il est plus gourmand en ressources.

Bref, la deuxième forme de codage pourrait donc avoir été utilisée en Javascript pour économiser de la place (bande passante) ... D'ailleurs, les variables sont "a", "b", donc les plus courtes possibles (je vous dis pas la concentration qu'il faut pour lire le code ...)

j'aime aucune des deux.

por moi une structure de contrôle ne peut pas se passer d'accolades, même si optionelles ça permet de garantir une lisibilité complête, ça et les opérateurs ternaires qui sont une hérésie quand on tient à la maintenabilité d'un code et un paquet d'autres choses comme ne jamais écrire un elseif parce que ca devrait être un switch, ne jamais mettre des return avant la fin d'une fonction, etc, etc.

Je ne partage pas ton avis sur les accolades, ma logique naturelle étant que je mets l'instruction unique toujours à coté de la structure. Par contre, si il y en a plus, toujours accolade et indentation.

Par contre, je ne partage pas ton avis sur les opérateurs terniaires. Et je ne partage pas spécialement l'avis de (qui?) d'écrire un switch dès qu'il y a un elseif, il m'arrive d'utiliser plusieurs elseif à la suite, par préférence au switch. Il m'arrive des fois d'utiliser switch, disons que je ne l'adore pas. Mais souvent mes if et elseif contiennent plusieurs conditions, et je fais alors naturellement ce qui me semble le plus clair pour moi, quitte à refactoriser ensuite (c'est l'expérience construire au fur et à mesure qui me guide dans mes choix, mais faut bien écrire qqchose ^^).

Pour le return avant la fin d'une fonction, cela peut s'expliquer par certains langages de programmation qui ne permettent qu'un seul return par fonction, comme JAVA. j'avais déjà fait l'expérience, et il fallait que je stocke ma valeur dans une variable pour que return la renvoie. Effectivement, ça a une certaine logique, certains codes sont imbouffables (mais eux ne respectent rien). Par ailleurs, le return a quand même l'avantage de terminer la fonction, permettant de réduire le plus vite possible la pile de fonctions dans le cas d'une récursivité, et de façon générale, de ne pas executer tout le code derrière en sachant que le résultat est déjà défini (c'est comme itérer 2500 items alors qu'on a trouvé ce que l'on cherche au 2ème ...)

j'aime aucune des deux.

por moi une structure de contrôle ne peut pas se passer d'accolades, même si optionelles ça permet de garantir une lisibilité complête, ça et les opérateurs ternaires qui sont une hérésie quand on tient à la maintenabilité d'un code et un paquet d'autres choses comme ne jamais écrire un elseif parce que ca devrait être un switch, ne jamais mettre des return avant la fin d'une fonction, etc, etc.

Je ne partage pas ton avis sur les accolades, ma logique naturelle étant que je mets l'instruction unique toujours à coté de la structure. Par contre, si il y en a plus, toujours accolade et indentation.

Sans les accolades pour une instruction unique c'est juste pas lisible, quand tu as des tonnes de code dans un même fichier les accolades systématiques améliorent sensiblement le fait que tu le repères directement.

//une ligne
if($cond) echo 'truc';

//lignes multiples
if($cond) {
	echo 'truc';
}

Par contre, je ne partage pas ton avis sur les opérateurs terniaires. Et je ne partage pas spécialement l'avis de (qui?) d'écrire un switch dès qu'il y a un elseif, il m'arrive d'utiliser plusieurs elseif à la suite, par préférence au switch. Il m'arrive des fois d'utiliser switch, disons que je ne l'adore pas. Mais souvent mes if et elseif contiennent plusieurs conditions, et je fais alors naturellement ce qui me semble le plus clair pour moi, quitte à refactoriser ensuite (c'est l'expérience construire au fur et à mesure qui me guide dans mes choix, mais faut bien écrire qqchose ^^).

Le switch est plus lisible dans tous les cas, regarde l'exemple bateau les conditions sont alignées naturellement tu as pas ça avec un elseif

switch(true) {
	case ($toto && $titi):
		echo 'stuff';
	break;
	case ($tutu || $tata):
		echo 'truc';
	break;
	default:
		echo 'prout';
	break;
}
//if elseif
if($toto && $titi) {
	echo 'stuff';
} elseif($tutu || $tata) {
	echo 'truc';
} else {
	echo 'prout';
}

Pour le return avant la fin d'une fonction, cela peut s'expliquer par certains langages de programmation qui ne permettent qu'un seul return par fonction, comme JAVA. j'avais déjà fait l'expérience, et il fallait que je stocke ma valeur dans une variable pour que return la renvoie. Effectivement, ça a une certaine logique, certains codes sont imbouffables (mais eux ne respectent rien). Par ailleurs, le return a quand même l'avantage de terminer la fonction, permettant de réduire le plus vite possible la pile de fonctions dans le cas d'une récursivité, et de façon générale, de ne pas executer tout le code derrière en sachant que le résultat est déjà défini (c'est comme itérer 2500 items alors qu'on a trouvé ce que l'on cherche au 2ème ...)

Ca se fait avec un break pas avec un return, le return ne devrait jamais faire autre chose que de renvoyer un résultat, c'est une utilisation détournée que je trouve non seulement moche mais qui mène à des incompréhension de code quand lu par un autre développeur.

Je trouve que

switch(true) { }

n'est pas lisible du tout puisque je dois dès le départ réfléchir bien plus à ce qu'il représente. Pour ce qui est du break c'est une remarque pour quoi ? J'ai parlé de fonction récursive, et une fonction qui ne renvoie rien, il est tout à fait logique d'arrêter son execution dès que plus besoin avec un return; ou return null; et pour les autres c'est pareil :

function math (type, valeurs)
{
if (type == addition) return valeurs[0] + valeurs[1];
....
}

Evidemment, c'est un super exemple car là tu vas utiliser elseif, mais c'est pour l'exemple.

Bref, si on peut en revenir sur le cas 1, ou alors on peut aussi discuter sur est-ce que return devrait toujours n'être présent qu'une seule fois dans une fonction. N'oublions pas que avec une bonne programmation, une fonction est censée être courte. C'est donc plus sur "Qu'est ce que fait cette fonction, ce qu'elle retourne" qui est important. Le "comment" l'est beaucoup moins.

Moi c'est un peu comme Nagol mais ça dépend de la longueur du code. Si un peu long je mets des accolades mêmes pour des conditions simples et j'utilise le switch assez souvent.
Par contre j'aime bien les opérateurs ternaires car je trouve pratique de voir les variables définies en tête de ligne. Parfois même je les empiles mais toujours avec des structures simples par ex:

$lang_navig = explode(",",$_SERVER['HTTP_ACCEPT_LANGUAGE']);
$lang_navig = strtolower(substr(rtrim($lang_navig[0]),0,2));

$lang =  !empty($_COOKIE['lang'])? $_COOKIE['lang'] : $lang_navig;
$lang =  !empty($_SESSION['lang'])? $_SESSION['lang'] : $lang;
$lang =  !empty($_GET['lang'])? $_GET['lang'] : $lang;

$lang = in_array($lang, $lang_traduites)? $lang : 'en';

switch a vraiment sa place, mais le coup du switch(true) j'avoue c'est la première fois que je le vois. En soit c'est pas mal, mais le switch n'est pas très lisible en mon sens (pas d'accolade, risque d'oublier break; etc).

Par contre, pour de la comparaison d'un élément, c'est nikel :

if ($foo < 0) echo "solide";
elseif ($foo >= 0 && $foo <= 100) echo "liquide";
else echo "gazeux";

donc déjà on peut :

if       ($foo < 0)                          echo "solide";
elseif ($foo >= 0 && $foo <= 100) echo "liquide";
else                                            echo "gazeux";

et bon, il n'y en a que deux + un défaut mais c'est tout à fait mon cas switch préféré :

switch ($foo)
{
   case < 0:
...
}

D'ailleurs connaissez-vous un moyen de diminuer cela :

if ($foo > -1 && $foo < 101)

en :

if ($foo > -1 && < 101)

Un between quoi ? Bon, faut avouer, ça reste pas le principal dans une application

switch a vraiment sa place, mais le coup du switch(true) j'avoue c'est la première fois que je le vois. En soit c'est pas mal, mais le switch n'est pas très lisible en mon sens (pas d'accolade, risque d'oublier break; etc).

portenaouak, déja je vois pas le rapport entre lisible et "pas d'accolade" ou "risque d'oublie un break" un switch si tu sais l'écrire y'a pas de soucis de break ou d'accolades c'est une question d'habitude faut croire, après le switch true c'est pas courant mais c'est puissant, on s'habitue vite à ces choses la, j'aime bien aussi le while(true) pas tellement que ca serve mais c'est rigolo de jouer avec le feu

bon sinon tes remarques sur le fonctions récursives je comprend pas une fonction récursive c'est une fonction qui s'appelle elle même exemple tarte à la crème:

function listdirs($path) {
	$result = array();
	$subdirs = glob($path . '/*', GLOB_ONLYDIR);
	foreach($subdirs as $dir) {
		$tmp = array();
		$tmp['name'] = str_replace($path . '/', '', $dir);
		$tmp['content'] = listdirs($dir);
		array_push($result, $tmp);
	}
	return $result;
}

la on peut très bien imaginer pour une fonction de recherche par exemple que l'on break dans le foreach sans faire l'appel récursif, c'est à ça que je faisais référence, la récursivité c'est jamais qu'une boucle (basée sur goto à bas niveau d'ailleurs) et une boucle ca s'interrompt avec un break, le return est la pour "retourner" une valeur c'est tout à fait différent.

Bonjour,

J'aime bien le "switch (true)" avec des "return false" pour chaque "case" dans le cas des contrôles de la saisie des utilisateurs.
Cela permet un code très lisible dans ce cas particulier dans la mesure ou la première ligne du "case" contient le message d'anomalie.

Pour moi le plus important est de respecter un nombre de lignes limitées qui permet de voir le début et la fin d'un block sur la même page

Et le plus drôle, avec le switch, c'est qu'on peut s'amuser à enlever certains breaks pour faire un goto amélioré..

En parlant de ça, et pour la première fois, j'ai utilisé un goto en Php, il y a quelques jours.