Discussion :

[moldavi]

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...

[esperanto]

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!

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.

[Zefling]

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/

[disedorgue]

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.

[Doatyn]

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

[grunk]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::shared_ptr<>

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...

[4sStylZ]

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.

[Invité]

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...

[moldavi]

Bonjour.

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.

[Markand]

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.

[Invité]

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.

[moldavi]

Bonjour.

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.

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.

[esperanto]

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.

[walfrat]

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.

[JPLAROCHE]

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....

[esperanto]

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?

[DevTroglodyte]

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.

[onilink_]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::shared_ptr<>

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.

[disedorgue]

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

[Paul_Le_Heros]

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 !
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 !