Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre émérite
    A l'heure des IHM élaborées, Linux se posent la question des 80 caractères par ligne en mode console. Ils me feront toujours rire : la ligne de commande, c'est le top...

  2. #22
    Membre expérimenté
    Années 80 caractères
    Citation Envoyé par Michael Guilloux Voir le message
    Citation Envoyé par Linus Torvalds
    nous ne programmons plus dans les années 80, et notre code source est donc fondamentalement plus vaste
    Dans les années 80, beaucoup utilisaient encore la programmation spaghetti, que ce soit en Basic ou en Cobol. Or, ce mode de programmation implique peu d'indentation: c'est bien plus facile de respecter la limite de 80 caractères quand les quinze premiers ne sont pas des blancs utilisés pour l'indentation!

    Du coup on va utiliser des fonctions pour réduire l'indentation... mais comme il parle de programmes en C, il a affaire à des programmeurs qui vont vouloir se concentrer les les performances brutes pour la moindre ligne de code, et donc vouloir réduire les appels à des fonctions!

    Citation Envoyé par SimonDecoline Voir le message
    Pour un projet un peu conséquent, il est indispensable de définir un "coding style". Si chaque dev utilisait son propre formatage, bonjour l'horreur à chaque commit (sans parler que des langages comme Python utilisent l'indentation).
    Beaucoup de projets libres imposent l'usage de checkstyle, et n’acceptent que les commits qui passent le fichier de règles sans encombre. Ou alors, Git permet de corriger le style dans un hook qui s'exécute au moment du commit.
    Un truc qui m'étonne par contre. On peut demander à Git d'ignorer les différences portant uniquement sur les espaces ou la forme des sauts de ligne. Alors pourquoi ne peut-on pas implémenter la possibilité d'ignorer d'autres détails de style, comme justement les sauts de ligne supplémentaires imposés par la limite des 80 caractères? Pourquoi ne peut-on pas implémenter la possibilité de faire un checkstyle aussi au moment du checkout? Comme ça, si je ne suis pas d'accord avec le style d'un projet, je pourrais demander à Git de sortir les fichiers au format qui me plaît, tout en reconstituant le style officiel du projet au moment du commit.
    Le seul inconvénient que je vois, pour reprendre un post précédent, c'est qu'en effet, un grep donnerait une réponse différente chez chaque utilisateur. Mais tout de même c'est rare qu'on partage le résultat d'un grep, en général on le fait pour soi.

    Linus a raison, il faut utiliser les outils de son temps. Et les outils d'aujourd'hui, ils savent reformatter du code.

  3. #23
    Expert confirmé
    Citation Envoyé par esperanto Voir le message
    Beaucoup de projets libres imposent l'usage de checkstyle, et n’acceptent que les commits qui passent le fichier de règles sans encombre. Ou alors, Git permet de corriger le style dans un hook qui s'exécute au moment du commit.
    Un truc qui m'étonne par contre. On peut demander à Git d'ignorer les différences portant uniquement sur les espaces ou la forme des sauts de ligne. Alors pourquoi ne peut-on pas implémenter la possibilité d'ignorer d'autres détails de style, comme justement les sauts de ligne supplémentaires imposés par la limite des 80 caractères? Pourquoi ne peut-on pas implémenter la possibilité de faire un checkstyle aussi au moment du checkout? Comme ça, si je ne suis pas d'accord avec le style d'un projet, je pourrais demander à Git de sortir les fichiers au format qui me plaît, tout en reconstituant le style officiel du projet au moment du commit.
    Le seul inconvénient que je vois, pour reprendre un post précédent, c'est qu'en effet, un grep donnerait une réponse différente chez chaque utilisateur. Mais tout de même c'est rare qu'on partage le résultat d'un grep, en général on le fait pour soi.

    Linus a raison, il faut utiliser les outils de son temps. Et les outils d'aujourd'hui, ils savent reformatter du code.
    Nous on fait ça. Si le commit d'une branche ne respecte pas toutes les étapes de la CI : formatage de code, build, etc. Tu mergeras pas ta branche. Après c'est dans gitlab pour ça.
    Dans git, tu peux passer par des hooks qui font ça, et si le hook passe pas il peut même refuser le commit. Ça évite d'avoir beaucoup de merdes et de mauvaises surprises.

    https://git-scm.com/book/en/v2/Custo...-Git-Git-Hooks

    Ha oui, on met aussi à disposition un fichier de règles de codage qui faire déjà une grosse partie du boulot. Le formatage automatique permet à tout le monde d'avoir la même chose. Ça évite que chacun fasse son truc à sa sauce : nombre d'espaces pour l'indentation par exemple.

    https://editorconfig.org/

  4. #24
    Expert éminent sénior
    Perso, je suis d'accord avec Linus qui refuse le coté obligatoire de la chose, car bien souvent on arrive à des trucs totalement absurde.
    Un exemple: Suite à un dev trop lent pour une mise à jour de donnée sur une table de base de donnée (la mise à jour prenait 5 jours), je m'étais fait mon propre dev qui avait réduit le temps à 2 heures. Ce code ne devait pas être utilisé en production mais comme ils en ont entendu parler, ils ont demandé à ce qu'on leur livre ce code plutôt que l'autre... Et là, le cauchemar commence: on me demande de livrer celui-ci mais avec les règles de l'art, donc toutes les obligations imposer par ce genre de script, comme la possibilité de reprises, remonter de log pour chaque action effectuer,...
    Résultat: le script rend le service voulu mais de 2 heures, passe à 7 heures.

    Et le script ne faisait pas grand chose: extraction d'une table => mise à jours des données (le temps passé est dans cette étape) => injection des données dans une table vide nouvellement créée.

    Donc, les règles c'est bien, mais les imposer systématiquement, c'est marcher sur la tête.
    Cordialement.

  5. #25
    Membre du Club
    80 caractères ... De mémoire, c'était la taille des cartes perforées ...
    Une survivance du passé.

  6. #26
    Modérateur

    Et puis 80 caractères ca va très très vite.
    Juste le fichier cpp que chez sous les yeux actuellement :

    3 namespace imbriqués , je perds déjà 12 caractères avant d'avoir écris la moindre ligne.
    Ensuite :
    Encore 17 caractères disparus pour un type (on évite le use std pour les effets de bords indésirables).

    Déjà 30 caractères et j'ai rien écrit d'intéressant...
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #27
    Membre éprouvé
    Citation Envoyé par SimonDecoline Voir le message

    Et puisqu'on parle des contraintes matérielles qui n'ont plus de raison d'être, pourquoi on n'alignerait pas les touches des claviers, au lieu de conserver ce décalage anti-ergonomique hérité des machines à écrire du 19e siècle?
    Certains le font, ça s'appelle des claviers matriciel (en Français) ou orthogonal en Anglais. Typematrix, XD75, ergodox, kinesis, maltron, Planck… il y'en a pleins.

  8. #28
    Expert confirmé
    Citation Envoyé par 4sStylZ Voir le message
    Certains le font, ça s'appelle des claviers matriciel (en Français) ou orthogonal en Anglais. Typematrix, XD75, ergodox, kinesis, maltron, Planck… il y'en a pleins.
    Oui. Sauf que la plupart coutent plus de 100 euros (et encore, pour les bas-de-gamme) et doivent généralement être achetés sur des sites spécialisés. Si tu en cherches un à moins de 100 euros et disponible sur un site classique comme amazon, ldlc, etc, bon courage...

  9. #29
    Membre émérite
    Bonjour.

    Citation Envoyé par moldavi Voir le message
    A l'heure des IHM élaborées, Linux se posent la question des 80 caractères par ligne en mode console. Ils me feront toujours rire : la ligne de commande, c'est le top...
    -9 pouces aujourd'hui, et pas un seul contradicteur qui me reprend. Il y a de bonne c... molle sur ce site, qui ne sont même pas capable de prendre le temps d'expliquer leur contradiction.

    Je demande juste aux 9 intellectuels qui m'ont mis un -1 d'argumenter un peu...

    J'attends 9 différentes réponses.

  10. #30
    Membre confirmé
    Oui mais d'un autre côté quand tu veux voir un diff sur ton écran de gauche à droite tu es bien content que tes lignes ne fassent pas 150 caractères autrement tu achète un écran 32/9.

  11. #31
    Expert confirmé
    Citation Envoyé par moldavi Voir le message
    J'attends 9 différentes réponses.
    Je me rappelle plus si j'ai mis -1, mais je vais quand même répondre.

    A l'heure des IHM élaborées,
    Pas vraiment de rapport avec le formatage de code.

    Linux
    Il ne s'agit pas de "Linux", mais du projet qui développe le kernel. Et en fait c'est surtout Linus Torvalds même.

    en mode console.
    Aucun rapport.

    Ils me feront toujours rire
    On s'en fout de ton humour.

    la ligne de commande, c'est le top...
    Aucun rapport.

    Donc pour répondre à ta question de pourquoi tout le monde te moinsse sans te répondre : parce que tu dis de la merde sans rapport avec le sujet.

  12. #32
    Membre émérite
    Bonjour.

    Citation Envoyé par SimonDecoline Voir le message
    Je me rappelle plus si j'ai mis -1, mais je vais quand même répondre.
    Du coup, je peux encore espérer avoir 9 réponses.


    Citation Envoyé par SimonDecoline Voir le message
    Donc pour répondre à ta question de pourquoi tout le monde te moinsse sans te répondre : parce que tu dis de la merde sans rapport avec le sujet.
    J'espère que parmi les 9 moinsseurs, la discussion sera plus élaborée et intéressante que juste :
    Aucun rapport, On s'en fout de ton humour, tu dis de la merde sans rapport avec le sujet
    J'avoue que j'ai un peu abusé avec
    c... molle sur ce site
    , et je m'en excuse. Je sens que cela t'a énervé. Mais en général, je prends le temps de répondre et d'argumenter, sauf si l'on me dit que je dis de la merde. A ce moment là je n'ai plus besoin de prendre le temps d'argumenter.

  13. #33
    Membre expérimenté
    Citation Envoyé par moldavi Voir le message
    A l'heure des IHM élaborées, Linux se posent la question des 80 caractères par ligne en mode console. Ils me feront toujours rire : la ligne de commande, c'est le top...
    Déjà faut arrêter avec le mythe du "hou, les linuxiens c'est des ringards ils en sont encore à la ligne de commande"

    La ligne de commande, je m'en sers beaucoup, elle me permet de faire en bloc des traitements sur beaucoup de petits fichiers en une seule fois, pas toujours facile sur une interface graphique surtout si les fichiers ne sont pas tous au même endroit. Et puis je le fais dans un terminal en mode graphique, pas en"mode console". Par contre j'édite mes fichiers avec un Kate ou KWrite, donc des éditeurs graphiques, pas avec Vi (sauf pour de très gros fichiers qui prendraient des plombes rien qu'à l'ouverture dans un éditeur graphique)

    Ensuite Linus Torvalds n'a pas défendu la ligne de 80 caractères, au contraire: il constate que beaucoup de ses contributeurs continuent de suivre cette règle et il leur demande d'arrêter. Est-ce que le fait que je te cite au début de ce post veut dire que je t'approuve? Non, c'est juste qu'il faut bien que je cite ce que je conteste. Exactement ce qui se passe dans le sujet de cet article.

    Tu vas sans doute dire que je n'ai rien compris à tes propos. Mais alors, puisque tu protestes sur les pouces en bas, dis-toi bien que je ne suis probablement pas le seul.

  14. #34
    Membre éclairé
    A l'heure des IHM élaborées, Linux se posent la question des 80 caractères par ligne en mode console. Ils me feront toujours rire : la ligne de commande, c'est le top...
    Alors :
    • Linux ne se posent pas la question, il contredit les gens qui maintiennent cet argument en 2020. Tu as donc complétement compris l'article de travers.
    • Quand tu administre des serveurs la ligne de commande t'as rien de plus en générale donc oui c'est toujours d'actualité. Et avec le Cloud, t'as autant moins de raison d'installer des packages d'UI sur ton serveur pour rien vu que chaque petit élément que tu utilises en cpu/ram te coûtent de l'argent.
    • Tu peux me faire l'IHM la plus élaborées du monde pour coder, si tu me mets des conventions de codages qui me rendent dingue ça va pas changer grand chose.

  15. #35
    Membre confirmé
    Citation Envoyé par esperanto Voir le message
    Déjà faut arrêter avec le mythe du "hou, les linuxiens c'est des ringards ils en sont encore à la ligne de commande"
    Tout à fait d'accords, j'ai mon petit script bash que de la ligne de commande pour faire mes mises à jour aux petits oignons...
    Heureusement que le terminal n'est pas mort .... Mais si je m'abuse sous Windows le terminal est aussi pour faire des réparations etc... Et aussi powershell mais c'est du pareil au même.

    bahhh moi 80 ou 120 je trouve que cela améliore la lecture dans beaucoup de cas, maintenant certain préfère le 80 ils ont des raisons que je ne discute pas. Qui peu faire le plus peu faire le moins mais pas le contraire.

    je développe pour du terminal 120 c'est top mais parfois je fais plus tout dépends du pourquoi....

  16. #36
    Membre expérimenté
    Citation Envoyé par JPLAROCHE Voir le message
    Heureusement que le terminal n'est pas mort .... Mais si je m'abuse sous Windows le terminal est aussi pour faire des réparations etc... Et aussi powershell mais c'est du pareil au même.
    Sous Windows, le terminal de base, de même que le langage des fichiers BAT, est quand même franchement limité. Il aura fallu attendre Powershell pour avoir quelque chose d'à peu près potable.
    Alors si les admins Windows n'utilisent presque pas la ligne de commande, ce n'est peut-être pas parce que c'est passé de mode, mais juste parce que celle de Windows n'a jamais vraiment été utilisable?

  17. #37
    Membre extrêmement actif
    Citation Envoyé par esperanto Voir le message
    Sous Windows, le terminal de base, de même que le langage des fichiers BAT, est quand même franchement limité. Il aura fallu attendre Powershell pour avoir quelque chose d'à peu près potable.
    Alors si les admins Windows n'utilisent presque pas la ligne de commande, ce n'est peut-être pas parce que c'est passé de mode, mais juste parce que celle de Windows n'a jamais vraiment été utilisable?
    je dirais plutot que rien n'incite à l'utiliser.

  18. #38
    Membre expérimenté
    Citation Envoyé par grunk Voir le message
    Et puis 80 caractères ca va très très vite.
    Juste le fichier cpp que chez sous les yeux actuellement :

    3 namespace imbriqués , je perds déjà 12 caractères avant d'avoir écris la moindre ligne.
    Ensuite :
    Encore 17 caractères disparus pour un type (on évite le use std pour les effets de bords indésirables).

    Déjà 30 caractères et j'ai rien écrit d'intéressant...
    Je pense justement que la limite des 80 caractères (ou un peu plus, chacun son truc après tout) est une bonne chose dans ce genre de cas verbeux, car cela force à définir des règles intelligentes de lisibilités.

    Par ex une règle assez standard que j'ai pu croiser est d'utiliser auto quand on peut déduire le type à l'oeil.

    Genre au lieu de faire la ligne a rallonge:
    std::shared_ptr<ItemMonsterAttribute> attr = std::make_shared<ItemMonsterAttribute>();

    On fait juste:
    auto attr = std::make_shared<ItemMonsterAttribute>();

    Y a aussi les typedef qui peuvent être utile quand on utilise beaucoup un type à rallonge.

    Perso la ou la limite des 80 char m'a permis d'être le plus carré, c'est tout bêtement pour les if avec des conditions a rallonge.
    Je me suis fixé la règle simple de sauter des lignes au besoin, et placer les && a gauche et les || a droite.
    Cela donne par exemple:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if((_flags[OptionPlaceholderL]
      && _flags[OptionPlaceholderR]) ||
      (!_flags[OptionPlaceholderL]
      && !_flags[OptionPlaceholderR])) {
    ou encore
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    if((_flags[OptionPlaceholderL]  && _flags[OptionPlaceholderR]) ||
      (!_flags[OptionPlaceholderL]  && !_flags[OptionPlaceholderR])) {
    Une fois habitué, on peut alors directement voir la structure de la condition (disjonction de conjonctions ici).

    Au lieu de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    if((_flags[OptionPlaceholderL] && _flags[OptionPlaceholderR]) || (!_flags[OptionPlaceholderL] && !_flags[OptionPlaceholderR]))
    que je trouve personnellement bien moins lisible.

    Niveau utilisation les 80 char on vraiment pas mal d'avantages, outre la meilleure lisibilité (car on force la découpe propre, si c'est pour faire ça salement autant ne rien faire de base).
    On peut utiliser des polices plus grosses sans se retrouver à devoir scroll horizontalement son code.
    On peut passer plus facilement sur des moniteurs à la verticale même avec du code fortement zoomé, ou encore split une fenêtre de code à la verticale (très pratique, surtout pour ceux qu'on n'ont pas de dualscreen) sans se retrouver avec le problème du scroll encore une fois.
    Des tutos de pixel art: https://twitter.com/OniMille

  19. #39
    Expert éminent sénior
    Perso, je ne me suis jamais posé la question sur la ligne de 80 caractères ou peut-être sur mon bon vieux amstrad qui selon le mode utilisé c'était 20,40 ou 80 caractères.
    Et des fois, faut arrêter d'être toujours celui qui doit s'adapter aux autres...
    Et sans être méchant, à en lire pas mal, on pourrait en déduire que vos sacro-saint IDE, c'est de la merde en boite, car depuis le temps, ils ne sont toujours pas capable de présenter un code d'un codeur selon les habitudes d'un autre codeur. Depuis le temps que les médias nous bassinent avec l'intelligence artificielle, il serait peut-être temps d'en mettre un peu dans les outils de dev, voir dans les terminaux aussi...

    Après, pour la ligne de commande, j'aime bien car ça ne change quasiment pas, c'est plus rapide qu'en clic (surtout pour la saisie des options de la commande) et j'aime bien utiliser le matériel dont je dispose, clavier compris

    Vive le vendredi
    Cordialement.

  20. #40
    Membre actif
    Et les identifiants
    Il faut limiter à 80 colonnes avec, bien sûr, des identifiants dont le libellé à 12 caractères minimum raconte ce à quoi sert la variable, la fonction ou quoi que ce soit&#8239;!
    Comme mentionné plus tôt, on a commencé avec 40 colonnes (d’accord, j’ai à peine vu du haut de mes 66 ans), mais on aurait dû y rester&#8239;!