Salut,
La question est con.
Lorsque vous voulez ajouter la possibilité d’afficher ou non une instance d’un model (exemple, le model Article), est-ce que vous ajoutez un flag booléen hidden ou un flag booléen visible ?
Et à part le feeling, y a t’il un choix intelligent ?
Salut,
Si visible à true affiche, alors c’est visible.
Si hidden à true cache, alors c’est hidden.
Question de sémantique :)
Tu trolles ?
Si oui. Joli.
Si non. Je sais bien, la question est de choisir si on préfère sélectionner certaines instances et les passer à hidden = true, ou sélectionner ces mêmes instances et les passer à visible = false.
C’était pas un troll, mais j’ai peut être compris la question de travers.
J’aurais tendance à utiliser plutôt visible que hidden parce qu’hidden = false m’apparaît comme une double négation, mais suivant le contexte d’utilisation du composant (et son état nominal), je pourrais être amené à utiliser hidden (comme pour un champ caché par défaut).
Maintenant, si le langage le permet, je préfère nettement utiliser une énumération du genre visibility = VISIBLE ou HIDDEN.
Bonne question, mais à vrai dire, j’ignore s’il y a vraiment une réponse.
@bouquetf parle « d’état nominal » et je pense que c’est ce qui doit prioriser dans la décision.
Quand je développe côté front-end, je remarque souvent qu’on ajoute un flag hidden pour cacher le composant, plutôt qu’un flag visible pour l’afficher (exemple d’angular et polymer qui ajoutent un css pour cacher tous les composants qui ont un attribut hidden).
Côté back-end, si l’objectif est simplement de cacher/afficher, sans parler de sécurité d’accès (qui serait plus une notion de privé/public), j’aurais tendance à mettre un flag hidden pour rester cohérent.
+1 et ça règle la majorité des problèmes.
Il me semble que le cerveau humain a plus de facilité avec les énoncés positifs. Je mettrais plutôt VISIBLE = True/False.
Comme quoi il n’y a pas de réponse unique.
De mon côté, je dirais que cela dépend de ta valeur par défaut. Souvent (mais c’est language-specific) un nouvel attribut d’objet, de modèle, de ce que tu veux est initialisé naturellement à null (ou nil, ou undefined etc.) bref à une valeur falsy. Donc utilise un attribut pour que la valeur par défaut soit falsy.
Du coup, plutôt que de devoir gérer une valeur par défaut à la création (eg. visible=true, status='visible' etc.) tu peux te contenter d’ajouter le critère et de ne l’initialiser que pour les objets dont la valeur n’est pas celle par défaut.
En outre, je trouve que cela a du sens au niveau entropique : lorsque tu as une valeur par défaut (ex: hidden=false quelque part), c’est normal que ton programme se comporte de la même manière pour :
{
id: 1,
name: 'My object',
param: {}
}
et
{
id: 1,
name: 'My object',
hidden: false,
param: {}
}
Donc si les objets sont visibles par défaut (ce que j’imagine dans ton cas), j’utiliserais hidden, en revanche si c’est un article et qu’il n’est pas forcément prêt par défaut, j’utiliserais published et non draft.
My 2 cents : visible et hidden est une problématique front. Côté back je calerais un attribut genre status avec pour valeur published, draft, reviewing, etc. Quelque chose qui ajoute une valeur sémantique. Côté design pattern ça serait une state machine sur une string.
Imagine une interface admin : si tu veux lister tous les articles non-publié, c’est plus cohérent d’afficher les draft que d’« afficher » des hidden.
Perso je n’utilise quasiment jamais visible ni hidden, je suis plutôt partisan du enabled qui serait par défaut à true, ça me permet d’avoir la même syntaxe dans tous mes projets.
Et puis quelques bibliothèques (notamment certaines libs autour de Symfony) ont endance à utiliser aussi cette notion de enabled (notamment les doctrine behaviors/extensions) et du coup ça me permet aussi d’être synchro avec ces bibliothèques.
Mais sinon, si on reste dans l’optique visible/hidden, dans ce cas tout dépend de la valeur par défaut que tu lui donnes, et de la façon que tu as de gérer tes valeurs par défaut.Comme le dit @augustin, souvent, une valeur par défaut est falsy, donc false ou null dans la majeure partie des cas. Donc si l’état par défaut de ton élément est “visible”, autant utiliser une propriété hidden qui collera bien à la valeur par défaut (qui sera donc visible de base).
C’est une question qui suscitera sûrement pas mal de débats, parce que moi-même je pars du principe que, par défaut, j’utilise enabled=true, et il est évident que tout le monde ne pense pas pareil :D
Attention, car enabled != visible/disabled != hidden en terme de sémantique dans certains langages, projets (ex: HTML). Dans le premier cas, tu le vois, mais tu ne peux pas le modifier et dans le second, tu ne le vois pas. Mais le reste de ton message s’applique aussi pour visible/hidden ;)
Je rejoins @Pierstoval, mais ma réponse est concomitante au sujet évoqué.
Je suis plus partisan d’utiliser enable / disabled du point de vue de l’objet, du composant.
ET d’utiliser ensuite visible / hidden qui va traduire l’état enabled/disabled du point de vue de la représentation (HTML / CSS, …)
Idem que @Joris et j’ajouterais même, pour ajouter à mon argumentaire, que pour moi, enabled/disabled est plus une notion de logique métier , et donc au niveau backend, et que visible/hidden est une notion d’affichage, et donc de frontend.
Holala ça va loin, naming things is hard :)
Moi je pense que c’est par métier, objet, usage…
Pour un blog, on ne dit pas visible/caché, on dira published? ou draft?
Pour un site de vente de livres, je mettrais en_stock? ou épuisé?.
Et là je rejoins les énoncés positifs donc plutôt published.
Mais pour moi un booléen est un manque d’infos, on peut faire mieux.
Alors je mettrais pub_date ou published_at et je ferais méthodes et scopes pour traiter les articles publiés ou non.
Pour des factures payée?, ou même… une facture est intéressante pour qui (client, conseiller, manager, comptable…) et pour quoi (historique, paiement, audit…).
Je sais qu’on est là pour coder, mais on code mieux quand on a les enjeux métier. C’est un bon indice qu’il faut lancer une discussion métier :)
@abelar_s Pour une facture on met souvent un workflow d’état, avec un champ status qui sera “payé”, “en attente de paiement”, “litige de paiement”, “annulé”, etc.
Parce que parfois plusieurs paiement peuvent être associés à une même facture :D (règlement en plusieurs fois, trop-perçu, remboursements, etc.)
@abelar_s
exactement, en fonction du domaine métier (progiciel gestion, authoring CMS…)
la notion de visible/hidden ne portera pas le meme nom, et pas toujours une valeur binaire.
Tu cites à juste titre un blogpost : les états “brouillon” et “relecture” conduisent
tous les 2 au même état de réprésentation “hidden” (pour simplifier hein)
@pierstoval c’est une bonne piste mais pas assez :)
On peut agréger UN statut parmi X pour manager et client (visible dans l’histo, dans la zone de paiement, dans la zone de réclamations…) mais pour les comptables c’est sûrement un autre statut :)
@Joris oui, d’où l’idée de plusieurs champs qui s’agrègent dans une condition : publié c’est au moins sorti du brouillon et relu par un tiers voire validé par le juridique (si on parle d’une boîte où les articles de blog DOIVENT être relus).
Bref, visible pour qui, quand et pour quoi :)
Aah, un débat sur des choses sensibles qui se fait de façon cordiale et aimable, c’est pour ça que j’aime Human Coders :D
Globalement je trouve que toutes les interventions sont pertinentes, on n’arrive pas à avoir de conclusion nette sur le sujet, mais au moins, avec ce que je lis, je sais qu’il y a toujours moyen pour chacun de se faire sa propre opinion sur le sujet, ce qui est vraiment intéressant pour l’enrichissement et l’ouverture d’esprit que ça génère :D
*philantrope*