Notez qu’il y a plusieurs autres dispositions de clavier qui permettent de saisir ce caractère directement : cf. cette galerie des dispositions clavier françaises (cherchez ensuite « … » dans la page).
Je viens de réaliser que ce serait peut-être plus simple de générer la doc à partir du code de test plutôt que l’inverse. C’est-à-dire utiliser l’approche programmation lettrée, où on mêlerait pure texte avec le langage de test plus formel, ce dernier étant ensuite remplacé par du texte à la génération de la doc ou exécuté quand on lance les tests. La différence avec l’approche présentée dans le billet est juste que le langage de test est clairement séparé et plus formel.
Dans un autre domaine, je me souviens de Catala pour les textes législatifs, vous connaissez ?
Très intéressant comme approche. Après question outillage cela dépend beaucoup du langage de programmation utilisé : pour ma part j'aime beaucoup l'approche d'une doc rédigée directement dans le code, avec des exemples qui sont testés pour 1) rester à jour avec le code 2) vérifier les propriétés attendues. La doc est ensuite générée pour avoir un manuel approprié et on peut tester la couverture du code testé et documenté.
Les véhicules légers (voitures particulières, 2 roues motorisés, véhicules utilitaires) concernés peuvent circuler le soir de 20h à 8h, les weekend et les jours fériés.
[^] # Re: …
Posté par DerVogel . En réponse au journal Des points et des points de code. Évalué à 2 (+2/-0).
Notez qu’il y a plusieurs autres dispositions de clavier qui permettent de saisir ce caractère directement : cf. cette galerie des dispositions clavier françaises (cherchez ensuite « … » dans la page).
Notamment :
- Bépo
- Ergo-L
- Le nouvel Azerty (Afnor)
# Et l’approche inverse ?
Posté par DerVogel . En réponse au journal Documenter ou tester, il faut trancher (j'ai pas trouvé de rime avec choisir...). Évalué à 2 (+2/-0).
Je viens de réaliser que ce serait peut-être plus simple de générer la doc à partir du code de test plutôt que l’inverse. C’est-à-dire utiliser l’approche programmation lettrée, où on mêlerait pure texte avec le langage de test plus formel, ce dernier étant ensuite remplacé par du texte à la génération de la doc ou exécuté quand on lance les tests. La différence avec l’approche présentée dans le billet est juste que le langage de test est clairement séparé et plus formel.
Dans un autre domaine, je me souviens de Catala pour les textes législatifs, vous connaissez ?
# Très intéressant commme approche
Posté par DerVogel . En réponse au journal Documenter ou tester, il faut trancher (j'ai pas trouvé de rime avec choisir...). Évalué à 2 (+2/-0). Dernière modification le 06 février 2025 à 06:10.
Très intéressant comme approche. Après question outillage cela dépend beaucoup du langage de programmation utilisé : pour ma part j'aime beaucoup l'approche d'une doc rédigée directement dans le code, avec des exemples qui sont testés pour 1) rester à jour avec le code 2) vérifier les propriétés attendues. La doc est ensuite générée pour avoir un manuel approprié et on peut tester la couverture du code testé et documenté.
Pour Haskell, il y ainsi doctest, très pratique.
[^] # Re: ferié
Posté par DerVogel . En réponse au journal ZFE, merdouilles ,et firefox. Évalué à 6 (+6/-0).
Bien vu, ça a l'air le cas :
https://www.metropolegrandparis.fr/fr/la-zone-faibles-emissions-metropolitaine