Discussion :

[maske]

et le jour ou ces gens retrouvent avec un bête éditeur de texte (genre vi)

Mais pourquoi tout à coup on retrouverait juste avec vi ? Dans la vie courante, on a généralement l'occasion d'utiliser un IDE qui fait tout ça pour nous : indentation, formatage de code, détection d'erreurs, débuggeur, etc., etc.

Je sais qu'il y a des puristes qui considèrent qu'on doit tout savoir faire «à la main sous vi». Mais sérieusement, t'es développeur t'as envie de perdre ton temps avec un truc futile comme ça qu'un outil peut faire à ta place ? Tu n'as pas plutôt envie de te concentrer sur le fonctionnement de ce que tu codes ?

Je sais : un jour, on se retrouve à débugger le programme sur une machine de prod ou de test qui n'est pas notre machine de développement donc pas d'IDE, juste les outils fournis par le système (vi ou autre...). Mais bon là y'aura pas que l'indentation qui posera problème.

[EDIT] Après réflexion, j'irai plus loin : à partir du moment où la plupart des outils font ces trucs chiants à notre place, alors oui moi en tant qu'ingénieur je râle si on ne me fournit pas la technologie qui sait très bien le faire et qu'on me force à m'occuper de futilités techniques.

[Tryph]

Mais pourquoi tout à coup on retrouverait juste avec vi ? Dans la vie courante, on a généralement l'occasion d'utiliser un IDE qui fait tout ça pour nous : indentation, formatage de code, détection d'erreurs, débuggeur, etc., etc.

on peut se retrouver sous vi pour éditer du code qui tourne sur une cible embarquée par exemple.
alors effectivement on peut récupérer le fichier sur notre poste, l'éditer dans un bel IDE et le renvoyer sur la cible. si j'ai de grosse modification, c'est même probablement ce que je vais faire, mais pour des modifications mineures, ça me parait quand même plus simple d'éditer le fichier directement sur la cible.
le problème ici, vient du mot en gras. généralement, tout va pour le mieux dans le meilleur des monde. mais de temps en temps, on peut pas faire comme on préférais. et dans ces cas faut bien savoir faire du boulot pas trop dégueulasse...

Je sais qu'il y a des puristes qui considèrent qu'on doit tout savoir faire «à la main sous vi». Mais sérieusement, t'es développeur t'as envie de perdre ton temps avec un truc futile comme ça qu'un outil peut faire à ta place ? Tu n'as pas plutôt envie de te concentrer sur le fonctionnement de ce que tu codes ?

je sais pas si je suis en train de passer pour un puriste qui considère qu'on doit tout savoir faire sous vi, mais ce n'est clairement pas le cas.
en général, je code sous Eclipse. quand j'utilise vi, c'est en général pour m'epargner des "soucis" pire que l'utilisation de vi.
sinon, sans parler de vi (parce que c'est un peu extrème) je bosse tous les jours avec des personnes qui codent sous Notepad++, et à ma connaissance, celui-ci n'est pas capable de te refaire une indentation complète. dans ce cas aussi c'est bien de savoir se passer de l'assitance.

Je sais : un jour, on se retrouve à débugger le programme sur une machine de prod ou de test qui n'est pas notre machine de développement donc pas d'IDE, juste les outils fournis par le système (vi ou autre...). Mais bon là y'aura pas que l'indentation qui posera problème.

tout à fait et c'est pas parce que l'indentation ne sera pas le seul problème que je ne dois pas savoir/vouloir m'en occuper. parce que à ce compte là, étant donné qu'on n'a rarement qu'un seul problème, on peut se servir de ce pretexte pour tout ignorer...

[EDIT] Après réflexion, j'irai plus loin : à partir du moment où la plupart des outils font ces trucs chiants à notre place, alors oui moi en tant qu'ingénieur je râle si on ne me fournit pas la technologie qui sait très bien le faire et qu'on me force à m'occuper de futilités techniques.

ça a l'air pas mal d'être ingérieur, on peut se permettre de râler pour tout et n'importe quoi

[e-ric]

Mais pourquoi tout à coup on retrouverait juste avec vi ? Dans la vie courante, on a généralement l'occasion d'utiliser un IDE qui fait tout ça pour nous : indentation, formatage de code, détection d'erreurs, débuggeur, etc., etc.

Panne de système et intervention en ligne de commande seulement, ça existe aussi. En outre, les serveurs ont assez souvent le minimum vital et donc pas d'outils de développement sophistiqués (hors activité sur ces machines)

Je sais qu'il y a des puristes qui considèrent qu'on doit tout savoir faire «à la main sous vi». Mais sérieusement, t'es développeur t'as envie de perdre ton temps avec un truc futile comme ça qu'un outil peut faire à ta place ? Tu n'as pas plutôt envie de te concentrer sur le fonctionnement de ce que tu codes ?

tu as sans doute une conception de l'informatique assez idéale mais dans la pratique... Utiliser Vi n'empêche pas de se concentrer sur ce que l'on a à faire, affirmation gratuite.

[maske]

Vi est un éditeur bien plus que basique : tu peux très facilement faire indentation, formatage de code, détection d'erreurs, débuggeur, etc., etc. (oui oui débogueur pas à pas, lis ici si tu ne me crois pas)
C'est juste ceux qui n'ont pas envie de se donner les moyens (et je reste très poli mais j'ai du mal) qui sortent "autant utiliser un truc qui me fait tout". Parce que vim fait tout et bien plus encore.
Note que je travaille presque à temps plein sous PyCharm, mais qu'il faut savoir faire bien plus que << "vim" + "i" pour être en mode notepad >>...
Allez je te laisse sous Visual Studio .

Oh mais j'ai déjà fait du debug sous vi, il y a longtemps. Aucun intérêt si ce n'est le destin qui le force (production...).

Mais je réitère ma question : pourquoi je me «donnerai les moyens» (pour rester poli également) pour maîtriser un truc qui demande beaucoup d'efforts alors que pycharm par exemple est presque fourni clé en main ?

Moi j'ai besoin de bosser efficacement, pas de montrer qu'avec vi on peut tout faire et perdre mon temps dessus.

Conclusion : je ne veux rien paramétrer puisqu'on sait faire des outils qui gèrent tout. À la limite, des petits tunings pour la couleur et l'organisation de l'IDE. Par exemple je ne pense pas que je ferais du smalltalk s'il n'y avait pas les systèmes qui vont avec, parce que ça nécessiterai trop d'efforts et que je laisse ça aux passionnés (et ce n'est pas péjoratif). Même remarque pour vi.

Dans la vie professionnelle, on n'a pas toujours le temps ni les moyens de se former au dernier gadget sorti, la pertinence de l'outil doit être établie. Si le langage apporte des constructions nouvelles et réellement utiles (j'ai par exemple aimé les nouveautés de Python par rapport à Pascal), je ne conteste pas l'idée. Ce n'est pas tant le changement de syntaxe qui me dérange mais la création d'un outil qui sur le fond n'apportera pas grand chose. Ce qui me semble le cas pour Ritchie, la syntaxe est éloignée du langage qu'il est censé remplacer, cela aura sans doute du mal de convaincre les développeurs C.

Je comprend mieux et suis d'accord, le problème c'est l'apport et le problème que ça adresse et là c'est pas clair du tout.

Redéfinir des éléments syntaxiques : ne risque-t-on pas d'introduire des problème de compatibilité entre des sources d'origines différentes.

Pas s'il s'agit d'un DSL - si c'est pas un DSL ça n'a pas de sens - sinon ça s'adresse à un domaine spécifique et donc les utilisateurs finaux seront forcément beaucoup moins nombreux que ceux d'un langage généraliste. En conséquence ça n'a pas beaucoup d'impact et probablement que les différentes sources resteraient plus ou moins cloisonnées.

Quand on travaille dans le développement, il n'y a pas que le langage de programmation, il y a aussi la connaissance de l'activité pour laquelle on travaille, cela prend aussi du temps. Les acquis permettent de travailler plus vite, tout simplement. Il faut comprendre outils au sens large (langage, IDE, bibliothèques et autres utilitaires). Tu tournes les arguments des autres d'une manière assez sournoise: penses-tu réellement que qu'en tant que développeur, on cherche à éviter de réfléchir, c'est une bien piètre opinion de notre métier.

Le domaine métier n'est pas lié à la syntaxe du langage. Un nouveau langage comme celui là *pourrait* adresser un besoin particulier pour un domaine métier spécifique - ce qui reste à prouver ici. Donc ça se range dans la catégorie «outils». Se plaindre de la syntaxe (qui en plus est simple) pour justifier de se concentrer sur les langages «qu'on connait déjà», oui c'est de la fainéantise. Notre métier c'est bien de s'adapter et de savoir jongler intellectuellement entre beaucoup de choses...

[e-ric]

Salut,

Bon un nouveau langage de plus... Je ne suis pas trop convaincu de l'intérêt de la chose. Il va falloir finaliser le langage, écrire les bibliothèques, créer l'écosystème et par là même dissiper des développeurs concentrés sur d'autres sujets ... Mon avis est qu'il aurait sans doute mieux valu optimiser un langage existant (comme Python puisqu'il est cité).

En outre, le monde des langages de programmation est déjà bien encombré. Pour le compilateur, l'annonce indique que l'environnement produit du langage C facile à comprendre, tant mieux cela apporte de la portabilité mais la lisibilité du code produit n'est pas un avantage significatif.

Enfin, introduire une syntaxe exotique risque d'être un inconvénient pour son adoption.

@foetus: l'indentation obligatoire de Python poursuit deux objectifs:
- forcer une présentation standard et rigoureuse du code,
- alléger la syntaxe en se débarrassant des symboles de début et fin de bloc d'instruction ({ et }, begin et end...)
Perso, cela ne m'a jamais dérangé même si je n'ai pas une très grande expérience de Python. Je trouve ton analogie rigolote mais mal fondée, ne pas mettre de porte serait un manque fonctionnel et non une simple contrainte (bien qu'on puisse se le permettre sur certaines voitures de course).

Cdlt

[maske]

Bon un nouveau langage de plus... Je ne suis pas trop convaincu de l'intérêt de la chose. Il va falloir finaliser le langage, écrire les bibliothèques, créer l'écosystème et par là même dissiper des développeurs concentrés sur d'autres sujets ... Mon avis est qu'il aurait sans doute mieux valu optimiser un langage existant (comme Python puisqu'il est cité).

Pas convaincu non plus mais pas pour les mêmes raisons. Une seule en fait : c'est quoi l'intérêt ? Je ne trouve pas plus de détails, à part que c'est fait par un «entrepreneur-consultant» et des étudiants.

Enfin, introduire une syntaxe exotique risque d'être un inconvénient pour son adoption.

(sans parler de la syntaxe un peu tordu inutilement a mon gout, cela va faire fuir les utilisateurs)

C'est quoi une syntaxe exotique ? C'est quoi une syntaxe tordue (inutilement) ?

C'est quand c'est pas du Java ou du C ? C'est quand on comprend pas ?

[e-ric]

@maske

C'est quoi une syntaxe exotique ? C'est quoi une syntaxe tordue (inutilement) ?

C'est quand c'est pas du Java ou du C ? C'est quand on comprend pas ?

J'apprécie les syntaxes "classiques" à la java, python par la force de l'habitude, des expressions du type:

Code ritchie :

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

1
2
3
4
5
6
 
Integer : factorial Integer n
    result = 1
    i for 1,n+1
        result = result * i
    -> result

sont certes originales mais n'apportent pas grand chose, la rupture de forme (le for suit la variable) n'a pas, à mon sens, une grande utilité et peut augmenter inutilement le temps d'assimilation de la syntaxe et possiblement décourager son adoption.

Enfin, je suis contre la profusion des langages de programmation qui ne font que dissiper les développeurs, je pense qu'il vaut mieux renforcer les outils existants. Mais si le langage apporte réellement quelque chose de nouveau et d'utile ou qu'il se rapporte à un domaine spécifique alors je ne conteste pas.

Cdlt

[maske]

@maske
J'apprécie les syntaxes "classiques" à la java, python par la force de l'habitude

Sommes nous d'accord pour dire que justifier quelque chose par l'habitude c'est tout sauf un argument ? =)

En outre, il n'est pas plus facile de maîtriser la syntaxe du java que celle du Caml par exemple. Tout repose sur la fainéantise des développeurs. Donc «syntaxe exotique» = définir pourquoi ou abandonner l'argument.

Code ritchie :

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

1
2
3
4
5
6
 
Integer : factorial Integer n
    result = 1
    i for 1,n+1
        result = result * i
    -> result

sont certes originales mais n'apportent pas grand chose, la rupture de forme (le for suit la variable)

C'est peut-être fait pour permettre la redéfinition d'éléments syntaxiques qui sont fixes dans d'autres langages. Le problème c'est qu'en fait on sait pas. Pas de doc. Pas de publications sur le langage.
Après le code est extrêmement simple à comprendre sur ces petits exemples, et pas du tout moins simple qu'un exemple en C ou en Python.

n'a pas, à mon sens, une grande utilité

C'est à dire ?

peut augmenter inutilement le temps d'assimilation de la syntaxe et possiblement décourager son adoption.

Affirmation gratuite. Évidemment, ça ne va pas encourager les feignasses et les débiles. Mais sinon ça ne repose sur rien.

Enfin, je suis contre la profusion des langages de programmation qui ne font que dissiper les développeurs, je pense qu'il vaut mieux renforcer les outils existants.

Alors techniquement, ça ressemble de loin à un DSL - donc un outil. Sinon je ne comprend pas le sens de ta phrase. Tu dis qu'il vaut mieux éviter de réfléchir à trop de choses pour se concentrer sur nos acquis ?

Mais si le langage apporte réellement quelque chose de nouveau et d'utile ou qu'il se rapporte à un domaine spécifique alors je ne conteste pas.

Je suis d'accord. Là ça ressemble à un exercice de style (et bon bof...).

[e-ric]

Sommes nous d'accord pour dire que justifier quelque chose par l'habitude c'est tout sauf un argument ? =)

En outre, il n'est pas plus facile de maîtriser la syntaxe du java que celle du Caml par exemple. Tout repose sur la fainéantise des développeurs. Donc «syntaxe exotique» = définir pourquoi ou abandonner l'argument.

Dans la vie professionnelle, on n'a pas toujours le temps ni les moyens de se former au dernier gadget sorti, la pertinence de l'outil doit être établie. Si le langage apporte des constructions nouvelles et réellement utiles (j'ai par exemple aimé les nouveautés de Python par rapport à Pascal), je ne conteste pas l'idée. Ce n'est pas tant le changement de syntaxe qui me dérange mais la création d'un outil qui sur le fond n'apportera pas grand chose. Ce qui me semble le cas pour Ritchie, la syntaxe est éloignée du langage qu'il est censé remplacer, cela aura sans doute du mal de convaincre les développeurs C.
Redéfinir des éléments syntaxiques : ne risque-t-on pas d'introduire des problème de compatibilité entre des sources d'origines différentes.

L'exemple de benchmark cité ne vaut absolument rien, juste des chiffres, il aurait fallu donner au moins les sources des programmes de tests. Un programme bien codé en Python peut donner de très bonnes performances bien qu'il soit interprété, Ritchie est compilé, la comparaison est donc baveuse.

Affirmation gratuite. Évidemment, ça ne va pas encourager les feignasses et les débiles. Mais sinon ça ne repose sur rien.

Merci pour les feignasses mais le monde du développement, pourtant jeune par rapport à d'autres activités, est peuplé de langages qui n'ont pas eu une très longue carrière, les développeurs/entreprises qui ont investi dessus (cela prend du temps) peuvent se retrouver dans l'ennui. L'innovation est valable si pertinente.

Alors techniquement, ça ressemble de loin à un DSL - donc un outil. Sinon je ne comprend pas le sens de ta phrase. Tu dis qu'il vaut mieux éviter de réfléchir à trop de choses pour se concentrer sur nos acquis ?

Quand on travaille dans le développement, il n'y a pas que le langage de programmation, il y a aussi la connaissance de l'activité pour laquelle on travaille, cela prend aussi du temps. Les acquis permettent de travailler plus vite, tout simplement. Il faut comprendre outils au sens large (langage, IDE, bibliothèques et autres utilitaires). Tu tournes les arguments des autres d'une manière assez sournoise: penses-tu réellement que qu'en tant que développeur, on cherche à éviter de réfléchir, c'est une bien piètre opinion de notre métier.

Je suis d'accord. Là ça ressemble à un exercice de style (et bon bof...).

un bel exercice intellectuel sans doute mais peut-être aussi une perte de temps.

[gangsoleil]

En outre, il n'est pas plus facile de maîtriser la syntaxe du java que celle du Caml par exemple.

Entièrement d'accord, chaque langage a sa syntaxe propre, ses manières de gérer, etc...

Néanmoins, je maintiens que le fait de mettre les mots-clefs-qui-n'en-sont-pas-mais-qui-en-sont-quand-même après le test / la variable, je n'ai rencontré ça dans quasiment aucun langage -- seules quelques constructions de perl me font penser à ça (dans lesquelles on peut mettre le test après le code conditionnel, mais même dans ce cas, la lecture du test reste naturelle).

Alors certes, il existe certainement un ou plusieurs langages très peu connus dans lesquels on lit/dit/écrit "fait beau SI picnic ALORS", mais ce n'est pas l'ordre linguistique naturel (si des gens ici peuvent me confirmer que dans des langues non indo-européennes cette construction est respectée -- ou non -- j'en serai bien content).

[PhiLho]

Ça me fait penser à Nim (anciennement Nimrod) qui a des objectifs similaires :

"Native code generation (currently via compilation to C), not dependent on a virtual machine: Nim produces small executables without dependencies for easy redistribution."
"Modern type system with local type inference, tuples, variants, generics, etc."
"Statements are grouped by indentation but can span multiple lines."
Etc.

Sauf que Nim a une syntaxe... moins exotique.

[Aiekick]

c'est la tuile pour python cette histoire si ca marche.

c'est le python tuile quoi

[Forthman]

"Ritchie n’a pas de mots réservés, tout peut être redéfini."
Pour moi c'est une très mauvaise idée, chaque programmeur va prendre ses habitudes, et ça va compliquer
la lecture de codes écrits par d'autres

[foetus]

"Ritchie n’a pas de mots réservés, tout peut être redéfini."
Pour moi c'est une très mauvaise idée, chaque programmeur va prendre ses habitudes, et ça va compliquer
la lecture de codes écrits par d'autres

Moi je le vois plus comme un ensemble de surcouches [si le langage fonctionne ]: une surcouche C, une surcouche Java, , une surcouche Lisp, ...

D'autant plus que le langage adopte une syntaxe [sujet verbe COD-COI "je-ne-sais-pas-quoi"], donc une syntaxe caméléon ... du moins sur le papier.

[FCWilk]

Le Julia n'était pas déjà fondé sur ce principe ?

[ChristianRoberge]

Je trouve un peu enfantin de compter les nombre de caractères d'un code surtout à l'ère de l'auto-complétation dans tous les compilateurs. Si cette affirmation serait vrai, l'APL règnerait en roi et maitre dans le monde informatique car du point de vue concision on n'a jamais fait mieux ni même approcher cette concision. LA concision n'est pas un critère d'après moi. Nous devrions parler plutôt de clarté du code...

[Amnael]

Je trouve un peu enfantin de compter les nombre de caractères d'un code surtout à l'ère de l'auto-complétation dans tous les compilateurs. Si cette affirmation serait vrai, l'APL règnerait en roi et maitre dans le monde informatique car du point de vue concision on n'a jamais fait mieux ni même approcher cette concision. LA concision n'est pas un critère d'après moi. Nous devrions parler plutôt de clarté du code...

Tous les codes concis ne sont peut être pas clair, en revanche je pense que tous les codes clairs sont concis.

C'est pas pour rien qu'il y a des conventions pour le nombre max de char dans une ligne de code (80 si je me souviens bien ?) et le nombre de ligne max dans une fonction. Il me semble qu'on considère qu'une fonction ne doit pas faire plus d'une page. Sinon il faut la découper en sous fonction. Mais j'ai l'impression que sur ce genre de choses tous le monde y va un peu à sa sauce et qu'au final, les conventions n'ont de conventions que leur nom...un peu comme avec le code de la route tant que tu te fais pas attraper par la patrouille...

[Logan Mauzaize]

C'est pas pour rien qu'il y a des conventions pour le nombre max de char dans une ligne de code (80 si je me souviens bien ?) et le nombre de ligne max dans une fonction. Il me semble qu'on considère qu'une fonction ne doit pas faire plus d'une page. Sinon il faut la découper en sous fonction.

Tu codes sur une imprimante ?

[Tryph]

Il arrive donc assez fréquemment que mes instructions tiennent sur une plus d'une ligne et avoir la liberté de les présenter correctement est vitale pour la bonne visibilité.

Je vois pas en quoi le fait d'avoir une indentation forcée empèche de présenter correctement une instruction multiligne.
Bon j'ai peut être bien écrit que les caractères blancs en début de ligne comptaient pour l'indentation en Python. En fait c'était pas tout à fait exact, il s'agit des caractères blancs en début d'instruction.
mais pour l'exemple, le bout de code si-dessous est parfaitement valable en Python et je pense pas qu'il soit particulièrement mal présenté:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
if un_résultat_quelconque == une_fonction_au_nom plutôt_long(
        avec, un, paquet, de, paramètres, qui, portent, des,
        noms, à, la, con):
    instruction_1
    instruction_2
    appel_fonction_quelconque(
        avec, encore, une, fois, une, profusion, de, paramètres)
    appel_d_une_autre_fonction_quelconque(avec, encore, une, fois, une,
                                          profusion, de, paramètres)
    instruction_3

ce code pourrait même passer sans problème l'épreuve de pylint (qui vérifie des conventions de codage) et on remarquera qu'aucune ligne ne dépasse les 80 caractères (je vais y revenir).

Mais j'ai probablement tort à cause de mon manque d'expérience dans le milieu^^

fais pas attention aux "anciens" qui te parlent de ton manque d'expérience pour contrer tes arguments et dis toi que s'ils te contrent sur ça c'est qu'ils ne peuvent pas te contrer sur quelque chose de plus pertinent.

Tu codes sur une imprimante ?

c'est "amusant" ces messages qui dépassent rarement une ligne qui commencent par une moquerie et qui se finissent pas un "ptdr"... la plupart du temps ils en disent plus sur leur auteur ce que ce dernier souhaiterait.
en l'occurence tu vois pas l'intérêt de coder uniquement (dans la mesure du possible) des lignes de moins de 80 caractères. tu t'es sans doute trouvé très malin en la sortant celle là, mais elle montre juste que tu ne sais pas qu'on peut parfois se retrouver à lire du code sur une machine distante via une console qui n'affiche pas plus de 80 caractères par lignes.
et quand on on a 80 lignes d'affichage pour lire un code qui contient des lignes de 120 caractères par exemple, bah on galère.
c'est pour ça que la plupart (tous?) les éditeurs récents permettent de faire apparaitre un guide, en général au 80e caractère et parfois affiché par défaut, qu'on évite de dépasser quand se soucis de cette problématique.
en tout cas, ça m'arrive en moyenne bien une ou 2 fois par semaine d'avoir à le faire et je peux t'assurer que le non dépassement du 79e caractère est une convention très respecté dans "mon" équipe. et on ne code pas sur imprimante...


bon en tout cas ça fait plaisir de voir un "débutant" se soucier des bonnes pratiques et des conventions de codage. ça fait un peu plus flipper de voir des "anciens" lui répondre qu'on s'en fout.

[Logan Mauzaize]

Je vois pas en quoi le fait d'avoir une indentation forcée empèche de présenter correctement une instruction multiligne.
Bon j'ai peut être bien écrit que les caractères blancs en début de ligne comptaient pour l'indentation en Python. En fait c'était pas tout à fait exact, il s'agit des caractères blancs en début d'instruction.

Merci pour cette précision Et dans ce cas rejoint mon argumentaire : tant que les blancs n'ont pas de sens sémantique pas de problèmes !

fais pas attention aux "anciens" qui te parlent de ton manque d'expérience pour contrer tes arguments et dis toi que s'ils te contrent sur ça c'est qu'ils ne peuvent pas te contrer sur quelque chose de plus pertinent.

Lol merci pour les accusations gratuites et sans fondements ...

c'est "amusant" ces messages qui dépassent rarement une ligne qui commencent par une moquerie et qui se finissent pas un "ptdr"... la plupart du temps ils en disent plus sur leur auteur ce que ce dernier souhaiterait.

Il faut se détendre. Il s'agit d'une blague et non d'un quelconque réquisitoire, jugement, etc. Quand on parle de 80 colonnes et de pages, cela fait quand même largement penser à de l'impression. Si tu vois pas le rapprochement, c'est autant dommages que tes remarques gratuites et légèrement acides.
(oui là il y a jugement )

en l'occurence tu vois pas l'intérêt de coder uniquement (dans la mesure du possible) des lignes de moins de 80 caractères. tu t'es sans doute trouvé très malin en la sortant celle là, mais elle montre juste que tu ne sais pas qu'on peut parfois se retrouver à lire du code sur une machine distante via une console qui n'affiche pas plus de 80 caractères par lignes.

En admettant que j'ai émis quelque part l'idée une règle interdisant une limite à 80 caractères par colonne : je vois pas en quoi tes cas particuliers M'interdiraient d'être plus laxiste là où TES contraintes ne s'appliquent pas.

Par ailleurs, hormis les émulateurs 3270 (qui sont limités à 100 colonnes de mémoire), je ne connais pas d'autres consoles qui possèdent cette limite. Donc pour du JCL et du COBOL, ca ne pose pas de problèmes puisque les langages imposent la taille des lignes.

et quand on on a 80 lignes d'affichage pour lire un code qui contient des lignes de 120 caractères par exemple, bah on galère.
c'est pour ça que la plupart (tous?) les éditeurs récents permettent de faire apparaitre un guide, en général au 80e caractère et parfois affiché par défaut, qu'on évite de dépasser quand se soucis de cette problématique.
en tout cas, ça m'arrive en moyenne bien une ou 2 fois par semaine d'avoir à le faire et je peux t'assurer que le non dépassement du 79e caractère est une convention très respecté dans "mon" équipe. et on ne code pas sur imprimante...

Et les éditeurs modernes permettent également de splitter visuellement une ligne à une colonne donnée et d'avoir un affichage bien lisible des lignes qui dépassent cette limite ...
En tout cas j'admire une équipe qui respectent les conventions établies, c'est encore relativement rare

bon en tout cas ça fait plaisir de voir un "débutant" se soucier des bonnes pratiques et des conventions de codage. ça fait un peu plus flipper de voir des "anciens" lui répondre qu'on s'en fout.

Les conventions sont propres à chaque équipe et doivent naître, se développer et évoluer dans un contexte donné. Voilà ce que savent les "anciens" et même certains "débutants".


Certains ("débutant" ou non) ont conscience qu'il leur manque des informations et que le doute est toujours permis. D'autres ("ancien" ou non) ne semblent ne jamais en prendre conscience ... A méditer !