Oui ton exemple est lisible. Mais ça se lit quand même comme deux conditions séparées par un 'et' là où l'autre solution se lit immédiatement comme un intervalle (et c'est juste mieux, sans être transcendant évidemment)
Par contre, il y a un cas tordu : celui où la ligne est quand même plus grande, où le code est en prod, où il faut corriger à la vas vite un problème : et dans ce cas, parfois, l'une des deux variables seulement sera changée. Dans l'autre cas (intervalle) c'est pas possible. Alors oui, on va me dire que c'est pas vrai, que c'est parce que le dev est mauvais, etc. Oui. Mais la réalité c'est que ce genre de cas existe. Et qu'il y a un tas de choses bonnes à prendre pour éviter ce genre de problème.
Les mots clefs pour les conditions négatives […] ça apporte à peut près rien et ça permet d'écrire des conditions négative dans dans une condition négative et ça c'est bien moins lisible.
Déjà sur la fin : et alors ? On devrait refuser car il peut y avoir un mauvais usage, c'est ça ? Des mauvais usages il y en a tout le temps, et c'est pas l'ajout de unless qui va empêcher les mauvaises écritures, ni les favoriser.
entre
displayif!empty
ou
displayunlessempty
mon choix est vite fait, je préfère la deuxième solution. Et comme pour le premier problème, si je peux virer le ! c'est parfois préférable. Il m'est arrivé de voir des codes qui ne fonctionnaient pas, les développeurs ont cherché pendant pas mal d'heures, pour finalement, bien après, se rendre compte que c'était juste à cause du !. Alors idem, on va dire que c'est pas possible, que c'est des mauvais dev. Mais quoi qu'il en soit ce cas arrive. L'ajout de unless permet de gagner beaucoup en expressivité et est moins source d'erreur. Evidemment celui qui écrit unless !condition là il faut probablement le fouetter…
Mais évidemment là c'est des cas simples.
En js j'écris souvent :
if(!('id'inplop)){// ...}
et ce serait beaucoup mieux, plus lisible et moins source d'erreur d'avoir :
unless'id'inplop# ...
Après, parfois j'ai quand même l'impression que certains (je ne te vises pas forcément hein ;) ) sont tellement habitués à avoir des langages pauvres (et ne parlons même pas de java…) que le moindre ajout d'expressivité est mal perçu. Et c'est vraiment dommage.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par CrEv (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 2.
Oui ton exemple est lisible. Mais ça se lit quand même comme deux conditions séparées par un 'et' là où l'autre solution se lit immédiatement comme un intervalle (et c'est juste mieux, sans être transcendant évidemment)
Par contre, il y a un cas tordu : celui où la ligne est quand même plus grande, où le code est en prod, où il faut corriger à la vas vite un problème : et dans ce cas, parfois, l'une des deux variables seulement sera changée. Dans l'autre cas (intervalle) c'est pas possible. Alors oui, on va me dire que c'est pas vrai, que c'est parce que le dev est mauvais, etc. Oui. Mais la réalité c'est que ce genre de cas existe. Et qu'il y a un tas de choses bonnes à prendre pour éviter ce genre de problème.
Déjà sur la fin : et alors ? On devrait refuser car il peut y avoir un mauvais usage, c'est ça ? Des mauvais usages il y en a tout le temps, et c'est pas l'ajout de
unlessqui va empêcher les mauvaises écritures, ni les favoriser.entre
ou
mon choix est vite fait, je préfère la deuxième solution. Et comme pour le premier problème, si je peux virer le
!c'est parfois préférable. Il m'est arrivé de voir des codes qui ne fonctionnaient pas, les développeurs ont cherché pendant pas mal d'heures, pour finalement, bien après, se rendre compte que c'était juste à cause du!. Alors idem, on va dire que c'est pas possible, que c'est des mauvais dev. Mais quoi qu'il en soit ce cas arrive. L'ajout deunlesspermet de gagner beaucoup en expressivité et est moins source d'erreur. Evidemment celui qui écritunless !conditionlà il faut probablement le fouetter…Mais évidemment là c'est des cas simples.
En js j'écris souvent :
et ce serait beaucoup mieux, plus lisible et moins source d'erreur d'avoir :
Après, parfois j'ai quand même l'impression que certains (je ne te vises pas forcément hein ;) ) sont tellement habitués à avoir des langages pauvres (et ne parlons même pas de java…) que le moindre ajout d'expressivité est mal perçu. Et c'est vraiment dommage.