Le problème, c’est que la réalité, c’est presque toujours complexe. Donc, tout programme réel doit se positionner dans cette alternative :
Rester simple, mais se priver volontairement de cas d’usages légitimes.
Répondre à ces cas d’usages, mais augmenter la complexité.
Évidemment, selon l’utilisation réelle du programme, la balance va pencher plus ou moins d’un côté ou de l’autre. Si je développe un logiciel à mon seul usage, je peux ignorer tous les cas d’usage qui ne sont pas les miens. Si je développe le système informatique des impôts d’un pays, je dois impérativement couvrir tous les cas d’usage, quelle que soit la complexité informatique que ça apporte (j’ignore volontairement la question de l’inutile complexité fonctionnelle en partant du principe que le développeur du programme n’a pas la main dessus).
C’est le moment pour préciser que le développeur (au sens large) n’a jamais la légitimité pour nier le besoin fonctionnel d’un utilisateur. Il peut choisir de ne pas la prendre en compte (« Mon logiciel n’est pas adapté pour ton besoin et ne sera pas modifié en ce sens, trouves-en un autre ou adapte-toi. »), mais c’est tout.
Quant à l’illusion de simplicité, ce qui est beau @abriotde c’est que tu fournis ton propre contre-exemple avec CSV. Parce que CSV est l’exemple parfait du format qui a l’air simple, mais qui ne l’est pas. Je pars du principe qu’on utilise le CSV standard (séparateur de champs ,, séparateur décimal . – Excel en Français utilise respectivement ; et ,). Même avec cette hypothèse, le format a les pièges suivants qui font que la plupart des implémentations naïves sont cassées :
Le séparateur de lignes est \n ou \r\n selon le système d’exploitation (oui, il y a des implémentations pétées dès ce point).
Les données peuvent avoir N lignes d’en-tête mais le format ne les différencie pas des données normales, il faut un mécanisme dans le parseur pour les déclarer.
Idem avec des colonnes d’en-têtes, plus rares.
On veut pouvoir avoir n’importe quelle valeur dans les champs, dont des virgules. Il faut donc un délimiteur de champ supplémentaire, facultatif – généralement ".
Ça implique donc d’avoir un mécanisme d’échappement pour pouvoir avoir ce caractère à l’intérieur d’un champ – généralement on double le guillemet : un champ qui ne contient qu’un guillemet s’écrit donc """". Ça implique d’avoir une logique qui compte les " pour savoir quoi faire.
On voit déjà qu’il est possible de générer des fichiers CSV incohérents au-delà du simple nombre de champs par ligne, et donc qu’il faut gérer ces erreurs.
En fait on ne peut pas lire un CSV ligne par ligne, parce qu’un champ protégé par des " peut contenir des sauts de ligne, qui en CSV standard seront enregistrés dans le fichier comme des sauts de ligne indiscernables à priori de ceux qui séparent les séries de données (ça n’est pas des caractères échappés).
Et je ne parle même pas de la problématique de transformation des champs textes obtenus en données typées (nombres entiers et réels, dates...)
Sauf que... beaucoup de développeurs font comme toi dans ton argumentation, ne voient que la partie « simple » du CSV, ne cherchent pas plus loin, en font une implémentation naïve, qui explose en vol dès le premier cas d’usage imprévu rencontré. Un parseur CSV robuste, c’est un parseur à base de jetons et d’une grammaire (certes simple) – ou mieux, une bibliothèque qui gère déjà tous ces cas pénibles. Dans ma carrière, je crois que cette erreur a été faite par les 3/4 des développeurs qui ont dû implémenter du CSV (en lecture ou en génération), et ça a fini par casser à chaque fois (pas de chance, j’ai jamais eu à traiter du cas uniquement numérique en conditions maitrisées de bout en bout).
Là où c’est amusant, c’est que XML a justement comme avantage de pouvoir être traité, validé, filtré et transformé au fil de l’eau, sans tout monter en mémoire. Même si avec les capacités de traitement modernes, c’est un avantage qui n’a plus un intérêt énorme (en particulier, ça ne compense plus sa difficulté de lecture pour un humain et sa verbosité dans la plupart des cas).
[^] # Re: Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 6. Dernière modification le 25 février 2024 à 01:05.
Le problème, c’est que la réalité, c’est presque toujours complexe. Donc, tout programme réel doit se positionner dans cette alternative :
Évidemment, selon l’utilisation réelle du programme, la balance va pencher plus ou moins d’un côté ou de l’autre. Si je développe un logiciel à mon seul usage, je peux ignorer tous les cas d’usage qui ne sont pas les miens. Si je développe le système informatique des impôts d’un pays, je dois impérativement couvrir tous les cas d’usage, quelle que soit la complexité informatique que ça apporte (j’ignore volontairement la question de l’inutile complexité fonctionnelle en partant du principe que le développeur du programme n’a pas la main dessus).
C’est le moment pour préciser que le développeur (au sens large) n’a jamais la légitimité pour nier le besoin fonctionnel d’un utilisateur. Il peut choisir de ne pas la prendre en compte (« Mon logiciel n’est pas adapté pour ton besoin et ne sera pas modifié en ce sens, trouves-en un autre ou adapte-toi. »), mais c’est tout.
Quant à l’illusion de simplicité, ce qui est beau @abriotde c’est que tu fournis ton propre contre-exemple avec CSV. Parce que CSV est l’exemple parfait du format qui a l’air simple, mais qui ne l’est pas. Je pars du principe qu’on utilise le CSV standard (séparateur de champs
,, séparateur décimal.– Excel en Français utilise respectivement;et,). Même avec cette hypothèse, le format a les pièges suivants qui font que la plupart des implémentations naïves sont cassées :\nou\r\nselon le système d’exploitation (oui, il y a des implémentations pétées dès ce point)."."""". Ça implique d’avoir une logique qui compte les"pour savoir quoi faire."peut contenir des sauts de ligne, qui en CSV standard seront enregistrés dans le fichier comme des sauts de ligne indiscernables à priori de ceux qui séparent les séries de données (ça n’est pas des caractères échappés).Et je ne parle même pas de la problématique de transformation des champs textes obtenus en données typées (nombres entiers et réels, dates...)
Sauf que... beaucoup de développeurs font comme toi dans ton argumentation, ne voient que la partie « simple » du CSV, ne cherchent pas plus loin, en font une implémentation naïve, qui explose en vol dès le premier cas d’usage imprévu rencontré. Un parseur CSV robuste, c’est un parseur à base de jetons et d’une grammaire (certes simple) – ou mieux, une bibliothèque qui gère déjà tous ces cas pénibles. Dans ma carrière, je crois que cette erreur a été faite par les 3/4 des développeurs qui ont dû implémenter du CSV (en lecture ou en génération), et ça a fini par casser à chaque fois (pas de chance, j’ai jamais eu à traiter du cas uniquement numérique en conditions maitrisées de bout en bout).
Là où c’est amusant, c’est que XML a justement comme avantage de pouvoir être traité, validé, filtré et transformé au fil de l’eau, sans tout monter en mémoire. Même si avec les capacités de traitement modernes, c’est un avantage qui n’a plus un intérêt énorme (en particulier, ça ne compense plus sa difficulté de lecture pour un humain et sa verbosité dans la plupart des cas).
La connaissance libre : https://zestedesavoir.com