Du coup, la section Étendre SPIP - Règle de codage renvoie vers la rubrique où sont publiés les « standards SPIP » 
Le 02/09/2021 à 13:20, JamesRezo via Discuter de SPIP a écrit :
les 2 autres rulesets phpcs sont décrit ici :
Questionnement : vu la petitesse et la répétition du contenu, et le fait aussi qu’on peut mettre des sommaires aux longs articles : est-ce utile de multiplier les articles plutôt que tout mettre dans la même page avec des titres et un sommaire ?
–
RastaPopoulos
Ha vi, bonne idée, mais peut-être que @JamesRezo a pour projet d’automatiser tout ça par la suite, mais ça n’empêche pas de tout regrouper sur une seule page.
Oui, à moyen/long terme, je pense que ça pourrait être automatisé. C’est vrai que c’est court, mais mon idée à la base était d’avoir un article (donc 1 page web) par « standard ». Afin d’éditer un nouvel article quand un nouveau standard est défini et de n’avoir qu’un seul article à modifier si un standard évolue…
Mais bon, j’imagine qu’à coup de modèle on pourrait sans doute avoir un ensemble de pages un peu plus cool. La rubrique Règles de codage - SPIP est bien triste, je l’admets.
Je n’ai pas trop d’avis pour les articles, l’un et l’autre me vont. C’est vrai que les articles des standards php-cs sont assez courts…
à l’instar des standards eux-même ^^
mais bref, je suis un peu à court d’idée, mais oui, on va trouver un compromis. L’dée des modèles, ça vous paraît une bonne piste ?
Le 02/09/2021 à 12:41, JamesRezo via Discuter de SPIP a écrit :
Les règles de codage (SCS1) en preview : https://www.spip.net/fr_article6677.html?var_mode=preview
https://www.spip.net/fr_article6677.html?var_mode=preview
à suivre, les standards SPIP40 et SPIP41
C’est un beau boulot de s’outiller pour nettoyer le code.
Mais les actuels titres des articles de ces pages : « SCS1 », « SPIP40 » et « SPIP41 » sont ésotériques
et le contenu des articles sera très décevant pour qui tombera là par exemple après avoir cherché « SPIP 4.0 » ou « SPIP 4.1 ».
Par ailleurs est-ce que tout cela ne concerne pas plutôt https://programmer.spip.net ?
JLuc
Voir le sujet https://discuter.spip.net/t/coding-standards/155150/42 ou répondre à ce courriel pour répondre.
Réponses précédentes[tcharlss] tcharlss https://discuter.spip.net/u/tcharlss
Août 30Hmmmm, du code bien formaté
Merci @JamesRezo https://discuter.spip.net/u/jamesrezo[JamesRezo] JamesRezo
Août 30Bon, c’est mergé et reporté sur la branche 4.0.
Maintenant la documentation ^^
[b_b] b_b
Août 28Pour moi c’est bon, attendons l’avis d’autres personnes
[JamesRezo] JamesRezo
Août 28Donc, on merge ?
[JamesRezo] JamesRezo
Août 27La PR : #4868 - cs-autofixes - spip - SPIP on GIT https://git.spip.net/spip/spip/pulls/4868
les commits
- https://git.spip.net/spip/spip/commit/34800944 https://git.spip.net/spip/spip/commit/34800944
- https://git.spip.net/spip/spip/commit/ff5d833c https://git.spip.net/spip/spip/commit/ff5d833c
- https://git.spip.net/spip/spip/commit/f8fb36ee https://git.spip.net/spip/spip/commit/f8fb36ee
- https://git.spip.net/spip/spip/commit/1fa8208f https://git.spip.net/spip/spip/commit/1fa8208f
- https://git.spip.net/spip/spip/commit/3f575d98 https://git.spip.net/spip/spip/commit/3f575d98
Voir le sujet https://discuter.spip.net/t/coding-standards/155150/42 ou répondre à ce courriel pour répondre.
Vous recevez ce courriel car vous avez activé la liste de diffusion.
Pour se désabonner de ces courriels, cliquez ici
https://discuter.spip.net/email/unsubscribe/31cc9574f16e795590c7e8c8e9dbcb9d69c9911443c269a893ee56c511d30cd3.
J’ai répondu dans le forum privé de l’article.
Sans doute. J’ai documenté là où les règles de codage étaient publiées depuis 6 ans. Je n’ai rien contre le changement.
En attendant, que ces règles soient sur spip.net ou sur un autre site, je pense que les pages de contrib pourraient être supprimées, histoire d’éviter toute confusion à l’avenir.
Je ne suis pas sur que Programmer soit une meilleure place pour ces articles.
Il y a des articles sur le code et les contributions dans tous les sites…
Il me semble que pour l’instant on parle du code de SPIP « Core » et pas encore des plugins.
Enfin, tout ça pour dire que je ne suis pas sur que le positionnement de ces articles soit un problème majeur actuellement.
Par contre, c’est l’utilisation de ces outils qui me parait plus cryptique en l’état.
Personnellement j’utilise PHPStorm et sachant que PHPStan et PHPCode_Sniffer sont intégrables aux inspections ça serait pratique d’avoir un tuto pour les installer avec la bonne configuration. En plus, on est plusieurs dans l’équipe à l’utiliser.
Autre chose, PHPCSFixer que j’utilise a une configuration facile à définir dans un fichier réutilisable par tout le monde. Le mien va au-delà de PSR-je ne sais pas combien. Où a-t-on la liste exacte de la configuration pour comparer ? Par exemple, avec PHPStorm et PHPCSFixer je peux corriger les array(), les if else mal gaulés… C’est contenu dans les outils mis en place ?
Le 02/09/2021 à 18:37, Eric Lupinacci via Discuter de SPIP a écrit :
Par exemple, avec PHPStorm et PHPCSFixer je peux corriger les array(), les if else mal gaulés… C’est contenu dans les outils mis en place ?
Oui, tout a été montré dans la PR qui a fait les modifs il me semble :
–
RastaPopoulos
et puis, on en a causé dans ce topic en plus ! 
OK, je suis un peu de loin.
Mais quand même, si je lis l’article SCS1, il y a une liste de recommandations.
Soit, mais cette liste n’est pas l’ensemble des règles applicables.
Donc, comment je fais pour connaitre la liste des règles applicables, il faut toujours se relire les PSR-x?
A priori, oui, c’est exhaustif. Si ce n’est pas le cas, je corrigerai la doc.
Non, pas besoin de relire les PSR, d’autant qu’on ne les appliquent pas (je crois l’avoir écrit dans la doc, mais je peux reformuler si ce n’est pas clair). On déroge à un bon nombre des règles des PSR de coding (1, et 12), strictement parlant. D’où un autre nom pour un standard explicitement spipien, documenté et, je l’espère exhaustif, et, pour la partie technique, un « ruleset » spécifique qui reprend exactement, je l’espère aussi, les recommandations de la doc, pour phpcs car c’est l’outil avec lequel, il me semble l’avoir déjà écrit, c’est le plus simple pour distribuer un ensemble de règles.
Perso, j’utilise la ligne de commande et des hook git dans mes projets. j’utilise aussi, quand je peux, des Makefile pour automatiser certaines tâches et quand j’ai un service d’intégration continue je programme les étapes avec ce Makefile… ou j’utilise un fichier .gitlab-ci.yml … Mais c’est ce que je fais moi, personnellement. Alors, oui, des tutos, ok, mais :
Par rapport aux IDE :
PHPStorm est UN IDE. Soumis à licence dont tu as la chance de bénéficier. Ce n’est pas le cas de l’ensemble de la communauté. On a donc une bonne chance d’avoir des contributeurs qui utiliseront atom, vscode, emacs, nano, vim, eclipse, sublime_text, xcode, notepad++ ou que sais-je ? Je te le dis tout net, je ne ferai pas un tuto pour chacun d’entre eux. Toi non plus, je pense.
Tout ce que je me suis attaché à faire, c’est de fournir une méthode d’installation et d’utilisation « conventionnelle », que, justement, tous les plugins d’intégration d’IDE est susceptible de reconnaitre.
On pourrait, à l’extrême limite, et en s’écartant du sujet initial, retirer les lignes suivantes du fichier .gitignore (en fait, ça devrait être présent, au pire, dans le fichier $HOME/.gitignore_global des utilisateurs, mais c’est un autre sujet) :
/.buildpath
/.project
/.settings
/.idea/
/.vscode/*
Avec ça, on pourrait versionner dans git de la config jetbrain, vscode, eclipse, etc. (perso je trouve ça intrusif, surtout pour un projet public, mais bon, on peut en discuter dans un autre topic)
Par rapport à php-cs-fixer :
Voilà
Alors depuis des années je renouvelle une dizaine de licences PHPStorm qui nous sont offertes par Jetbrains pour le développement d’un projet open source et qui sont attribuées aux membres du Core.
Sinon, je pense que de ne pas fournir un tuto pour les IDE PHPStorm et VSCode serait dommage et rendra la mise en oeuvre de cette excellente pratique de codage peu utilisée par d’autres que les experts comme toi. Ce sera d’ailleurs surement mon cas car j’ai lu le descriptif d’installation et j’ai rien compris.
Donc je vais m’en tenir à mon PHPCSFixer en espérant être compatible avec SCS1 (à vérifier de mon coté un de ces jours).
Tu m’as mal compris
Moi, je n’utilise pas PHPStorm, je ne peux pas te faire ton tuto
Super pour les 10 heureu·se·s élu·e·s ! Sincèrement je trouve ça bien. C’est un bel effort de la part de Jetbrains et de la tienne. J’aurais aimé qu’il en soit de même pour sublime_text à l’époque, que je trouvais plus performant à l’usage, mais c’est pas une boite qui pouvaient se le permettre, j’imagine. Mais bon, quid des non-membres du core ? et des 20 autres membres du core ?
Je n’ai pas dit qu’il ne fallait pas de tuto, j’ai dit que j’ai fait ma part : la base. Je vais bientôt être out pour plusieurs semaines/mois et j’aimerais parler d’autres sujets, je peux ?
Pour installer :
git checkout master
git pull
composer install
puis, pour utiliser :
vendor/bin/phpcs
Un plugin d’IDE bien fait peut, a priori, être configuré projet par projet (parce qu’on ne fait pas tous QUE du SPIP dans la vie) pour préciser le chemin d’exécution de l’outil. Il existe peut-être des plugins composer pour IDE qui permettent de ne pas taper de ligne de commande, mais de faire des clic-droits, je ne sais pas, mais ça me surprendrait que ça n’existe pas.
Je ne suis pas un expert des IDE, loin de là. Je n’en utilise qu’un seul et très mal, excuse-moi pour ça.
Et désolé de n’être qu’un « expert » à tes yeux …
Loin de là, tu le sais bien ` et ce n’est pas à toi de créer les tutos bien évidemment.
Je dis juste que pour installer des habitudes il faut toujours en simplifier l’usage pour ceux qui n’ont pas l’habitude de ces outils et surtout de leur environnement autour de composer qui ne fait pas partie de SPIP nativement.
En fait, je viens de m’apercevoir que spip embarque maintenant un composer.json qui va intégrer ton outil de vérification avec un xml de configuration.
C’est pas immédiat pour moi ce type d’intégration.
Maintenant, si je fais composer install, je suppose que je vais intégrer un dossier vendor sous la racine spip ce qui est aussi un peu nouveau.
D’ailleurs depuis que j’ai up spip PHPStorm me sort un avertissement composer que je ne comprends pas…
Donc rien de dramatique, je me suis bien mis à Git et j’en suis content mais tu vois que ces notions ne me sont pas évidentes et que pour appréhender l’outil il faut avoir intégrer un environnement de dev qui m’est étranger actuellement. Et je ne dois pas être le seul.
La bise
1 « J'aime »
Bien sûr des bisous ! 
On est bien d’accord, c’est d’ailleurs pour ça que je n’ai pas parlé de généralisation aux plugins tout de suite, bien que le système (enfin … l’extension phpcs quoi) est prévu pour : créer/modifier le .gitignore, créer ou modifier composer.json, ce qui peut presque être automatisé. Créer le fichier phpcs.xml.dist et adapter le contenu au plugin, c’est plus compliqué.
À titre d’exemple, mise en place des outils de développement pour un plugin, passe d’autofix et baseline pour phpstan.
On peut appliquer à tous les plugins-dist si ça vous branche.
Gogogo
1 « J'aime »