close
  • Li chevron_right

    Quelles seraient les meilleures règles de formatage de code ?

    news.movim.eu / LinuxFRJournaux · 4 days ago - 12:03 · 3 minutes

En programmation on a l’habitude, depuis quelque temps, de formater le code et notamment l’indenter.

L’objectif de ce formatage est généralement de faciliter la coopération, et de rendre le code le plus lisible possible.
Mais la lisibilité de code est forcément un critère avec de la suggestivité.

C’est notamment sur le sujet de l’indentation que j’ai vue passé le plus de désaccord plus ou moins cordiaux.

En ce qui me concerne j’ai toujours préféré indenter avec des tabulations plutôt que les espaces.
Déjà par habitude, j’ai beaucoup plus travaillé dans des bases de code où la règle c’est la tabulation.
Ensuite c’est un seul caractère à taper, stocker et supprimer contre généralement quatre espaces (rarement moins de deux).
Enfin la tabulation permet à chacun de choisir le nombre d’espaces équivalent en fonction de ses propres préférences, voir besoin.

Mais je suis conscient que ce n’est pas parfais, la tabulation à aussi des inconvénients.
Par exemple l’alignement d’un début de ligne avec un “milieu” d’une autre ligne n’est pas compatible avec le choix de la largeur des tabulations. (Bon je pense que c’est une fausse bonne idée pour d’autres raisons).

le formatage “parfait” ?

Du coup je me suis posé la question : si c’était à moi de choisir le formatage d’un projet, quel serais le meilleur ?

Aujourd’hui il y a des outils qui aident bien à conserver et unifier le formatage du code d’un projet. Mais il faut y penser si ce n’est pas automatisé, les assistants dans les éditeurs fonctionnent pas mal quand on écrit le code, souvent moins bien quand on en supprime.

Objectifs

Avant de pouvoir choisir le meilleur formatage, il faut déjà définir les objectifs.

En plus de la lisibilité intrinsèque du code, je souhaite que le formatage génère le moins de diff possible. En effet minimiser les diffs de code facilite les review de code pre et post commmit.
J’ai horreur des changements qui mélange des changements de code (logique) et des lignes avec seulement des changements “cosmétique”.
J’estime que la lisibilité du code a un instant t ne doit pas se faire au détriment de la lisibilité de l’historique.

ça m’est arrivé de travailler avec des personnes qui en C++ alignait le début du nom des variables d’un même groupe.
ça peut aider à la lisibilité du code à un instant t , mais ça demande un effort au programmeur et surtout ça demande de la maintenance quand le code évolue, du coup je classe ça en fausse bonne idée.
De la même manière aligner le début d’une ligne sur le contenu (milieu) d’une autre ligne, demande de la maintenance, cré des modifications de ligne “parasite” dans les diffs. => Fausse bonne idée.

Solution

Du coup, est-ce que le meilleur formatage ne serait pas un formatage “vide” : Aucune indentation, le strict minimum d’espaces ?

Et la lisibilité me direz-vous ?
Pourquoi ça ne serait pas à l’éditeur de code de s’en occuper ?

Avantages :
* plus besoin de taper, stoker et supprimer des caractères (tabulation ou espace) pour une question de formatage.
* la disposition pourrait être mise à jour de façon dynamique au fur et à mesure de la frappe, y compris quand l’utilisateur supprime du code.
* l’affichage pourrait être personnalisé par chaque utilisateur indépendamment vu que c’est l’IDE qui s’en occuperait.

L’inconvénient c’est que ça nécessiterait l’adaptation de nombreux outils ainsi que des changements d’habitudes important. Sans compter que basculer une code-base existante serais très délicat.

J’ai parlé principalement de l’indentation, mais on peut aussi réfléchir à la problématique de la longueur max des lignes de la même façon.

Et vous ?

Est-ce que vous avez déjà réfléchi à votre formatage parfais ? Que serait-il ?
Qui est chaud pour tester d’implémenter ça dans un formateur de code ?

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Li chevron_right

    Des concepteurs qui ont éteint trop tôt leur cerveau

    news.movim.eu / LinuxFRJournaux · 4 days ago - 10:43 · 2 minutes

Cela fait un moment que j'avais envie d'écrire ce journal qui dénonce grave.

Vous avez sûrement déjà été confronté à un objet, à une invention, à un concept pas trop mal pensé, mais visiblement mal fini, avec une lacune tellement énorme que vous ne pouvez vous empêcher de penser que le mec qui l'a inventé ça a éteint trop tôt son cerveau.

Voici deux exemples qui devraient être assez parlants.

Le code d'identification des résines plastiques

Vous le connaissez forcément, c'est un numéro écrit dans un triangle, qui permet de savoir de quel type de plastique est fait un emballage. Eh bien, si vous regardez un peu ce que ça veut dire, c'est simple, les numéros de 1 à 6 désignent des plastiques particuliers, et le numéro 7 désigne tout le reste.

Quelqu'un a donc un jour imaginé ce code d'identification, numéroté 6 matières plastiques, et s'imaginer que c'était une bonne idée de réserver le numéro 7 pour tout le reste. Pire encore, d'autres gens ont validé cette idée, sans se rendre compte que :

  1. on n'allait pas s'arrêter d'inventer des matériaux, et que ce numéro 7 allait à l'évidence finir par en désigner beaucoup trop, rendant ce numéro d'identification inutilisable ;
  2. compter au-delà de 7 était certes très compliqué pour leur cerveau défectueux, mais que ça ne posait aucun problème aux gens normalement pourvus.

Le message d'avertissement du public des films

Si vous allez de temps en temps au cinéma, vous avez dû remarquer un message qui est affiché au début de chaque séance. Quelque chose qui ressemble à :

Avant d'assister à la projection d'une œuvre cinématographique, les spectateurs sont invités à vérifier à quelle catégorie de public elle s'adresse.

Sauf qu'au moment où ce message s'affiche, le spectateur, ou ses parents, etc., n'a plus aucun moyen de vérifier justement si le film n'est pas inadapté pour lui. On peut notamment se tromper de salle, arriver à une projection d'un film d'horreur bien trash, et ne s'en rendre compte qu'au début du film, voire plus tard encore.

Ce message répond à une obligation légale, qui a dont été écrite par un ministre, un député ou un assistant. À aucun moment, ce rédacteur ne s'est rendu compte qu'il serait peut-être pertinent, et qu'il ne coûtait pas plus cher, d'imposer au projectionniste d'indiquer dans le même message la catégorie de public visée par le film. Pire encore, lors de l'examen de cette loi, aucun député ne s'est rendu compte de cette grosse faille, si triviale à résoudre.

D'autes ?

Et toi, lecteur, as-tu d'autres exemples intéressants à partager ? Ça ne sert à rien, mais ça fait du bien de dénoncer grave, parfois.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Li chevron_right

    Comptes de 1999 qui êtes vous?

    news.movim.eu / LinuxFRJournaux · 4 days ago - 10:39

Quels sont vos réseaux?
De temps en temps je vais jeter un coup d'oeil a la page de stats de linuxfr pour voir si enfin mon compte est devenu le seul datant de 1999, parce que tel un highlander de pacotille il ne peut en rester qu'un.

Et a chaque fois c'est la déception. Je ne suis pas le seul. Il y a 26 autres pékins.

Donc j'aimerais bien savoir qui vous êtes, et ce que vous fichez encore ici?

Sans aucune arriérée pensée...

Commentaires : voir le flux Atom ouvrir dans le navigateur

Parmi les commentaires du journal précédent , cette réponse est la seule et unique qui soit pertinente, le reste est inutile.

Puisqu'elle est perdue dans la masse, je veux lui donner la place qu'elle mérite dans mon 'nal.

Pourquoi mettre en avant un commentaire qui n’est rien d’autre qu’un défouloir ?
Même si je peux comprendre qu’on ait envie de l’écrire, d’exprimer sa frustration, la partager.

En ce qui me concerne, je trouve ce commentaire rempli d’affirmations péremptoires, de jugements, et contient même des avis insultants.
- ça ne me parait pas très favorable à un meilleur vivre ensemble
- et ça ne me parait pas très constructifs.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Li chevron_right

    Quel serait les meilleurs règles de formatage de code ?

    news.movim.eu / LinuxFRJournaux · 5 days ago - 22:35 · 3 minutes

En programmation on a l’habitude, depuis quelque temps, de formater le code et notamment l’indenter.

L’objectif de ce formatage est généralement de faciliter la coopération, et de rendre le code le plus lisible possible.
Mais la lisibilité de code est forcément un critère avec de la suggestivité.

C’est notamment sur le sujet de l’indentation que j’ai vue passé le plus de désaccord plus ou moins cordiaux.

En ce qui me concerne j’ai toujours préféré indenter avec des tabulations plutôt que les espaces.
Déjà par habitude, j’ai beaucoup plus travaillé dans des bases de code où la règle c’est la tabulation.
Ensuite c’est un seul caractère à taper, stocker et supprimer contre généralement quatre espaces (rarement moins de deux).
Enfin la tabulation permet à chacun de choisir le nombre d’espaces équivalent en fonction de ses propres préférences, voir besoin.

Mais je suis conscient que ce n’est pas parfais, la tabulation à aussi des inconvénients.
Par exemple l’alignement d’un début de ligne avec un “milieu” d’une autre ligne n’est pas compatible avec le choix de la largeur des tabulations. (Bon je pense que c’est une fausse bonne idée pour d’autres raisons).

le formatage “parfait” ?

Du coup je me suis posé la question : si c’était à moi de choisir le formatage d’un projet, quel serais le meilleur ?

Aujourd’hui il y a des outils qui aident bien à conserver et unifier le formatage du code d’un projet. Mais il faut y penser si ce n’est pas automatisé, les assistants dans les éditeurs fonctionnent pas mal quand on écrit le code, souvent moins bien quand on en supprime.

Objectifs

Avant de pouvoir choisir le meilleur formatage, il faut déjà définir les objectifs.

En plus de la lisibilité intrinsèque du code, je souhaite que le formatage génère le moins de diff possible. En effet minimiser les diffs de code facilite les review de code pre et post commmit.
J’ai horreur des changements qui mélange des changements de code (logique) et des lignes avec seulement des changements “cosmétique”.
J’estime que la lisibilité du code a un instant t ne doit pas se faire au détriment de la lisibilité de l’historique.

ça m’est arrivé de travailler avec des personnes qui en C++ alignait le début du nom des variables d’un même groupe.
ça peut aider à la lisibilité du code à un instant t , mais ça demande un effort au programmeur et surtout ça demande de la maintenance quand le code évolue, du coup je classe ça en fausse bonne idée.
De la même manière aligner le début d’une ligne sur le contenu (milieu) d’une autre ligne, demande de la maintenance, cré des modifications de ligne “parasite” dans les diffs. => Fausse bonne idée.

Solution

Du coup, est-ce que le meilleur formatage ne serait pas un formatage “vide” : Aucune indentation, le strict minimum d’espaces ?

Et la lisibilité me direz-vous ?
Pourquoi ça ne serait pas à l’éditeur de code de s’en occuper ?

Avantages :
* plus besoin de taper, stoker et supprimer des caractères (tabulation ou espace) pour une question de formatage.
* la disposition pourrait être mise à jour de façon dynamique au fur et à mesure de la frappe, y compris quand l’utilisateur supprime du code.
* l’affichage pourrait être personnalisé par chaque utilisateur indépendamment vu que c’est l’IDE qui s’en occuperait.

L’inconvénient c’est que ça nécessiterait l’adaptation de nombreux outils ainsi que des changements d’habitudes important. Sans compter que basculer une code-base existante serais très délicat.

J’ai parlé principalement de l’indentation, mais on peut aussi réfléchir à la problématique de la longueur max des lignes de la même façon.

Et vous ?

Est-ce que vous avez déjà réfléchi à votre formatage parfais ? Que serait-il ?
Qui est chaud pour tester d’implémenter ça dans un formateur de code ?

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Li chevron_right

    La commande ack, one step beyond grep !

    news.movim.eu / LinuxFRJournaux · 5 days ago - 18:57 · 3 minutes

L'URL du site de la commande ack annonce la couleur 1 : https://beyondgrep.com/ . J'ai l'habitude d’agripper les motifs avec grep, mais je m'essaie depuis quelques temps à les acquérir avec ack 2 . Le deuxième et dernier journal sur cette commande datant d'avril 2013 (voir le tag ack ), il est temps de faire une piqûre de rappel aux citoyens du libre.

Version 3

En 2019, ack est passée en version 3. La version actuelle est la 3.5.0 (mars 2021), et la version disponible dans Ubuntu 21.10 est la 3.4.0. Les nouveautés sont résumées sur la page principale du site.

La commande est écrite en Perl 5 et les dépendances sont minimales :

$ apt show ack[...]Depends: libfile-next-perl (>=1.18), perl:anyBreaks: ack-grep (<=2.14-5~)Replaces: ack-grep (<=2.14-5~)[...]

Cela permet de la proposer facilement pour la plupart des systèmes d'exploitation : Linux, macOS, *BSD et Windows.

On voit également que dans Ubuntu la commande s'appelait auparavant ack-grep , soit 100 % plus long que grep . Devenue ack , elle prend l'avantage en étant 25 % plus courte ;-)

Usages

Chercher dans les contenus des fichiers

Étant écrite en Perl, ack utilise bien sûr les expressions régulières Perl 3 de façon native. L'usage en est très simple :

ack [options] PATTERN [FILE...]

Un des avantages de ack sur grep est qu'elle utilise par défaut un certain nombre d'options utiles : récursion des répertoires, affichage des numéros de lignes, coloration syntaxique et surbrillance du motif recherché (sauf redirection)… De plus, elle ignore par défaut de nombreux fichiers (images, archives, sauvegardes, PDF…) et répertoires ( .git , __pycache__ , CMakeFiles …), ce qui participe à sa rapidité. La commande ack --dump vous en donnera la liste avec une syntaxe limpide.

Les principales fonctionnalités de ack et d'autres alternatives à grep sont résumées dans ce tableau . Voici une courte sélection personnelle parmi les nombreuses options disponibles :

-l, --files-with-matches      Print filenames with at least one match-i, --ignore-case             Ignore case distinctions in PATTERN                             -w, --word-regexp             Force PATTERN to match only whole words-m, --max-count=NUM           Stop searching in each file after NUM matches-C [NUM], --context[=NUM]     Print NUM lines (default 2) of output context.-t X, --type=X                Include only X files, where X is a filetype,                                e.g. python, html, markdown, etc-s                            Suppress error messages about nonexistent or unreadable files.

Notez que l'option -t peut être utilisée encore plus simplement, par exemple :

$ ack LinuxFr --markdown

L'option peut facilement être inversée pour au contraire éviter certains fichiers : --nomarkdown .
Pour déterminer le type d'un fichier, la commande se base non seulement sur les extensions des noms de fichiers mais aussi sur les shebang. Les types disponibles peuvent être obtenus avec à nouveau la commande ack --dump .

Chercher dans les noms ou les types de fichiers

Avec l'option -g , on peut chercher le motif dans les noms des fichiers plutôt que dans leur contenu. Par exemple, cherchons des fichiers de configuration cachés :

$ ack -g ^[.].*rc$

Avec l'option -f on pourra par exemple afficher simplement la liste des fichiers d'un type donné présents dans une arborescence :

$ ack -f --shell

Personnalisation

Pour personnaliser le comportement de la commande, on peut créer un fichier de configuration contenant toutes les options et paramètres définis par défaut :

$ ack --create-ackrc > ~/.ackrc

Exemple concret, j'aime bien utiliser des terminaux avec caractères noirs sur fond jaune clair mais par défaut ack affiche les numéros de ligne en jaune. J'ai donc simplement ajouté dans mon .ackrc la ligne suivante :

--color-lineno=Red

Conclusion

ack est le genre de commande que l'on risque d'adopter rapidement après essai : simple, rapide, efficace, agréable à utiliser, comportement facilement personnalisable… Il est même possible de l'appeler depuis certains outils tels que vim ou emacs.

Mais il est vrai que grep bénéficie de la prime au premier entrant. Pour un script à distribuer, grep a l'avantage d'être installée sur tous les systèmes libres, même si ses variantes peuvent éventuellement introduire quelques problèmes de compatibilité.

En tout cas, pour votre usage quotidien vous risquez vraiment d'être séduit(e)s par ack.

Acknowledgements

ack est essentiellement l'oeuvre d' Andy Lester , alias petdance sur GitHub . Elle est sous licence Artistic License 2.0 .

Références


  1. Prince Buster, One Step Beyond , 1964.

  2. Auverlot Olivier, "Ack, le super grep", Linux Pratique, HS n°52, octobre 2021, https://connect.ed-diamond.com/linux-pratique/lphs-052/ack-le-super-grep

  3. Bernard Desgraupes, Introduction aux expressions régulières, Paris : Vuibert, 2e édition, 2008, ISBN 978-2-7117-4867-9.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Li chevron_right

    Merci LinuxFr

    news.movim.eu / LinuxFRJournaux · 5 days ago - 18:16 · 3 minutes

Parmi les commentaires du journal précédent , cette réponse est la seule et unique qui soit pertinente, le reste est inutile.

Puisqu'elle est perdue dans la masse, je veux lui donner la place qu'elle mérite dans mon 'nal.

Un 'nal que LinuxFr.org me permet de gérer en toute liberté, d'en lire les commentaires en les filtrant à ma guise selon un seuil de note allant de -42 à 5, d'y répondre ou pas, de les pertinenter ou pas, de les moinser ou pas, et de royalement ignorer ou pas les trolls qui viendraient lancer des cabales et des anathèmes.

MERCI LINUXFR.ORG

Assimiler la critique du passe à une volonté de contamination, chapeau !

Ben si c'est critiquer le passe pour aller teufer en boîte de nuit entre gens non vaccinés, oui, c'est exactement ça, c'est défendre le droit de se contaminer stupidement les uns les autres.

Le passe sanitaire est hautement critiquable.
Mais pas vraiment la volonté d'endiguer la pandémie.

Pour rappel, le ministre de santé avait affirmé que « si on était tous vaccinés, le virus ne circulerait plus » : https://youtu.be/fQvKWWiJS14 à 0:28

Et si on était vraiment tous vaccinés, on serait nettement moins embêtés par ce virus à la con.
Parce que oui, le vaccin :
- diminue les chances de contracter la maladie ;
- diminue les chances de la transmettre si on l'a contractée ;
- diminue les chances d'avoir une version grave, et potentiellement mortelle, de la maladie.

Les vaccins de manière générale c'est ce qui a permis de doubler l'espérance de vie en 150 ans. Il y a 150 ans, j'aurais déjà dépassé mon espérance de vie et je serais dans le bonus de celle-ci, alors que je suis encore largement très loin de la retraite.

Si il y avait moins d'antivax-pour-le-principe-de-contester, moins de gens qui rejettent sans réfléchir deux secondes, ce que propose le gouvernement, le passe sanitaire serait inutile.

Et oui, dans un monde où tout le monde est vacciné, le passe sanitaire ne sert strictement à rien, puisque de manière générale il vérifie qu'on est vacciné, et marginalement qu'on a eu un test négatif récent.
Alors, moi, aujourd'hui, à cause d'un paquets de connards qui croient lutter pour la liberté alors qu'ils ne font que s'opposer stupidement au gouvernement - par principe, parce que c'est Macron, et que moi non plus je ne peux pas le piffer, mais ça n'a rien à voir - et ben je suis obligé de montrer un putain de passe sanitaire quand je vais au cinéma, ou au restaurant.

Et je l'ai eu le Covid, et je l'ai eu deux mois après avoir été vacciné, et cette semaine là, où j'étais potentiellement contagieux, j'aurais pu aller où je voulais avec mon passe sanitaire à la con !
Parce que c'est une mauvaise solution au problème, mais que c'est la plus simple à mettre en œuvre quand il y a trop d'abrutis qui refusent de se faire vacciner sans raison valable et réfléchie.

Oui : la majorité des antivax sont embarqués dans des dérives complotistes témoignant d'un manque profond de réflexion, ou le font juste pour faire la nique au gouvernement et dire « moi j'l'ai pas fait, fuck l'état et Macron », ce qui est le degré zéro du vivre ensemble.

C'est un billet d'humeur ici ?
Un caca nerveux sur un sujet ultra-clivant de la société en général, et qu'on se rend compte qu'il clive dans toutes les strates, y compris les plus progressistes ? (Si tant est que linuxfr représente réellement une frange plus progressistes de la société, mais bon moi aussi j'y crois.)

Alors la voilà mon humeur, noire, et énervée :
Si le fait qu'un sujet de société - qui enflamme tout le monde partout - ne fait pas VOTRE unanimité sur un site dont le thème est COMPLÈTEMENT autre chose, alors que ceux qui veulent partir partent, et embarquent toute leur intolérance avec eux.

Yth.

Commentaires : voir le flux Atom ouvrir dans le navigateur