Reprise du message précédent :

Ce standard des années 80

putain retour a mon époque Qbasic  
obligé de choisir entre mode  
SCREEN 12 => 80*60 char ( 680*480 pixels) en 16 couleurs  
SCREEN 13=> 40*30 chat ( 320*200 ) mais 256 couleurs

Rigole pas, c’est encore implémenté dans certains clients mails.
Thunderbird le fait, je crois bien.

Années 80 => 80 colonnes par ligne
Années 2010 => 2010 colonnes par ligne      

Fortran 77 FTW, quand tu lit le code t'as l'impression d'avoir la pile de cartes perforées (à 80 colonnes) sous les yeux.
 
Par contre le code pondu par des incultes blindé de blocs COMMON  

80 colonnes par lignes, c'est pas si antique que ça

Dans certains IDE, il y a une ligne d'indication sur la droite. Sur Android Studio, elle se situe à 100 caractères. On peut la dépasser, mais j'ai déjà bossé pour des boites où il est interdit de la dépasser.
Il faut imaginer la scène : il y a un code review toutes les trois semaines. Ni plus. Ni moins. Toi, t'arrives, tout content, t'as livré ton code à temps. Il faut maintenant qu'il soit validé par cinq personnes. La première personne arrive, vois que tu dépasses sur une ligne, ne cherche pas plus loin, et rejette ton code. Trois semaines plus tard, t'as raccourci ta ligne, et toutes les autres. Le code passe de nouveau en code review. Là, le mec voit que tu dépasses pas. Il valide. Arrive alors la deuxième personne. Celle ci se rend compte que t'as retiré un saut de ligne en fin de fichier, après la fin de ta classe. Ca lui plait pas, il rejette ton code.
Trois semaines plus tard, la première personne revalide ton code, la deuxième voit que t'as rajouté le saut de ligne, et valide. Arrive la troisième personne. Là, les choses sérieuses commencent, elle va enfin analyser pour de bon ton code. Par exemple en vérifiant que tes tabulations sont bien formées de 4 espaces et non d'une tabulation.
Et après, le commercial de ta SSII arrive, furieux, car t'es en retard sur le planning et que le client est mécontent.
Histoire vécue, y'a même pas six mois, aucune exagération.
 

Euh mais les gars, la limite de 80 colonnes c'est tout à fait logique et très utilisé.

Il y a plusieurs raisons à cela, la principale étant la lisibilité et un standard de lecture, en aucun cas une limite technique. Quand vous bossez pas tout seul dans votre coin et que le code doit être édité/revu à plusieurs par exemple. Et ça facilite aussi beaucoup la lecture de diffs (car la plupart de temps les systèmes de versionning fonctionnent par lignes), dans des pull requests ou même du blame.

edit : et aujourd'hui beaucoup de ces trucs peuvent être validés automatiquement par une plate forme de CI, ou même en pre commit pour éviter de pousser du code qui n'est pas conforme à la syntaxe convenue dans l'équipe. Et les règles peuvent même être « inter » IDE/éditeur de code grâce à editor config. Bref, coder dans le XXI ème siècle quoi

C'est un peu vous les incultes là

C'est pour ça qu'il faut mettre en place des linters de code, comme ça tu chies pas à coté

ça doit être fabuleux comme métier    
 
"- T'as fait quoi aujourd'hui au boulot chéri ?    
- J'ai compté les espaces et les tabulations    
 Vivement demain, c'est mon tour de compter les retours à la ligne    

burn juste au dessus, à 10 secs

Heureusement que mes 5 ans d'études m'ont doté d'une bonne capacité d'analyse  

Excuse moi de ne pas être assez rapide

 
Excuses acceptées, Capitaine Needa  

En 2016 c'est quand même un peu léger 80 caractères. On code plus sur des VT100...

IntelliJ est configuré à 120 par défaut.

Pareil, dans ma Cogip on a un standard à 120 colonnes, ce qui à la grosse louche représente la moitié de la largeur d'un full HD 24 pouces avec une police de caractères lisible, donc ça laisse largement assez de place dans ton IDE pour avoir d'autres panels.
 
80 colonnes c'est franchement de la torture si on bosse avec du matos du 21ème siècle  

http://legacy.python.org/dev/peps/ [...] ine-length

Les gens sont libres d'établir les standards qu'ils veulent, c'est pas pour ça que ça doit être considéré comme parole d'Evangile. A plus forte raison quand c'est imposé sans le moindre début de justification, genre "Limit all lines to a maximum of 79 characters." (parce que le bullshit en-dessous j'appelle pas ça une justification non plus : ils misent tout sur le fait d'avoir deux fichiers ouvertrs l'un à côté de l'autre )
 
Je connais des types qui développent toujours des projets > 1M lignes avec vi, c'est pas pour ça que je vais les suivre  

Si c'est du python installe pep8

Je code pas, j'ai un écran 16:9
 
 
 
 
 

Dans ta boîte la review de la taille d'une ligne c'est fait par des humains ?      

Si une éditeur avec de quoi ouvrir des fichiers à gauche et une minimap à droite (Atom/Sublime par exemple, police par défaut), la moitié d'un écran HD ça fait environ 90 lignes. Donc 80 je trouve pas ça déconnant. Et comme je disais, c'est pas spécialement la raison : la lisibilité pour tous ainsi que les diff dans les PR ou les review.

De la torture, sérieux ? C'est beaucoup plus lisible, après si tu fais du Java avec des noms de classe qui font déjà plus de 90 caractères, je comprends ta douleur

edit : après t'es pas obligé de le forcer à vérifier cette limite non plus, tu peux avoir des bonnes pratiques sans être un nazi forcément

edit 2 : et je suis un convaincu, parce que perso avant j'en avais rien à foutre de cette limite, mais finalement en faisant quelques efforts, on se rend compte que c'est pas dénué d'intérêt, surtout lors de merge ou de lecture de PR

Ça fait plus de 5 ans que j'ai du WQHD, 2x120 ça passe sans problème.
 
Et le jour où je peux demander un nouveau moniteur je prends un 34" 21:9.

j'ai un 21:9 multiE/S à la maison, ça revient au meme qu'un dual1280 en fait

Perso je suis friand des hautes résolutions aussi, par contre c'est pas le cas de tout le monde (indirectement j'allais dire, parce que ça se trouve pas trop sur des petites dalles, et que ya pas mal de gens qui préfèrent des écrans < 24" pour bosser).

 
Entre ca :

 
et ca :
 

 
Je trouve le deuxième plus lisible (je code pas sur un écran minuscule   ), question de gout. Les conventions faut les prendre pour ce qu'elles sont, des conventions

J'étais comme toi avant, maintenant je visualise mieux sur plusieurs lignes

Maintenant mettons que ta des merges à faire ou des diff, et que quelqu'un ait fait une modif sur le deuxième open. Ça sera moins clair sur le deuxième exemple car ta ligne en contient deux

Les conventions c'est fait pour améliorer le travail d'équipe et pas perdre de temps. Et même que parfois ya des efforts à faire pour qu'on parle tous la même langue (espace vs tabs etc.) Un bon exemple c'est « standard » en JS, c'est pas toujours idéal mais en moyenne tu gagnes du temps à l'adopter en équipe.

Bref, c'était un peu pour mettre en perspective les goûts perso et regarder un peu au niveau du dessus, qui est arriver à produire un truc à plusieurs

Au final, pour clore ce « débat », 80 colonnes c'est pas ridicule ni une limite technique, mais une convention parmi d'autres (et là on est tous d'accord ). Bref, pas un truc d'incultes

Pour recentrer le topic, on peut discuter du génie de l'administration fiscale et sa confiance dans les logiciels métiers : si t'es un artisan et que tu bosses sur Sage ©, comme « c'est pas modifiable » © on te fait moins chier que si tu bosses sur un autre soft (Ciel par exemple).

« Les numéros de factures qui doivent se suivre absolument » parce que c'est une garantie que tu triches pas Heureusement que « ces gens là » bossent pas dans l'IT

 
+1  
Sans compter que ça évite aussi d'avoir cinquante niveau d'imbrications.
Dès que t'as 3 niveaux d'indentation tu te sens à l'étroit et ça te rappelle que tu es sûrement en train de faire le con, autant scinder ça et faire une fonction dédiée.
 

Tu codes comme un goret et en plus tu es persuadé d'avoir raison
Tu sais pas faire une review de ton propre code tout seul et revert ce qui n'est pas un changement pertinent ?
Tu sais pas configurer ton éditeur pour te conformer au coding style du projet ?
 
Rien de délirant ici, c'est même rare qu'une boite ait le courage d'aller jusque là.
Si y a un incompétent dans cette histoire c'est toi.

'tain tout ça pasque memaster62 met un retour chariot tous les 100chars

On peut pas avoir une nouvelle histoire de HC pour revenir dans le sujet ?

C'est pas toi qui impose des règles à la con du genre pas d'espace après une parenthèse ouvrante (ou avant une parenthèse fermante)? La limitation à 80 caractères je trouve que c'est pas pire...

C'est au bon vouloir et selon les goûts du mec qui a démarré et/ou maintient le projet, ou simplement de la politique de la boite.
Et par goût c'est pas juste que "c'est plus beau" mais qu'on repère mieux (selon l'avis de chacun) tel ou tel token, on suit mieux le flow d’exécution et les blocs, par exemple avec les accolades sur une nouvelle ligne ou à la fin des conditions.
 
Et quand tu arrives sur un projet qui utilise des conventions que tu n'aimes pas... Bein tu la fermes et tu t'y plies. Tu vas pas tout désharmoniser parce que toi tu préfères 2 espaces par indentation et non 4 Peu importe la décision, ce qui compte c'est que tout le projet soit uniforme pour prendre des habitudes de lectures et suivre le code en un coup d’œil.
 
Et comme dit plus tôt 80 c'était surtout pour la taille des vieux terminaux physiques. Aujourd’hui techniquement ça n'a plus aucun sens, à part éviter les lignes ultra longues, et faut bien décider d'une valeur si on veut imposer une limite. En plus de la raison que j'ai évoquée plus haut.

Ça c'est parce que c'est imposé par la norme des mails.  
En HTML tu passes outre, mais pour des mails en texte brut tu es obligé de limiter la longueur des lignes il me semble.

Tu me croiras peut-être pas, mais je suis parfaitement capable de suivre des règles de codage, même les très chiantes du genre préfixer les noms de variable avec une lettre qui rappelle leur type. Mais à tout prendre, les règles, je les préfère quand j'en vois l'intérêt. Limiter la taille des lignes à 80 car. ça peut paraitre extrême mais je vois ce que ça peut apporter en terme de lisibilité. Interdire l'espace après une parenthèse, non je vois pas.
Et pour ce qui est d'aligner les accolades ouvrantes et fermantes tu prêches un convaincu.

Si tu interdis pas, certains le feront, d'autres le feront pas et au final ça fait un code pas homogène.
Donc faut faire un choix.
 
Je te crois hein Moi aussi y a des règles que je trouve un peu idiotes, mais bon soit on change la règle et on remanie tout le code, soit on s'y plie. On en fait pas juste à sa tête.

+1 ... les règles sont (parfois) arbitraires, mais c'est pour le bien de tous (d'ailleurs les règles sont le résultat d'une consultation collective). Ça chouine au début, mais au bout d'un certain temps tout le monde est comme dans des vieilles charentaises.
 
Par exemple, effectivement moi je peux pas livrer mon code si y'a un espace avant une accolade fermante, ou si un fichier contient des tabs. Parce que si tu te contentes de warnings, au bout de 2 semaines personne n'en a plus rien à cirer.
 
Y'a malgré tout des règles qui datent du 14ème siècle (genre les 80 colonnes ou la lettre pour préfixer les noms de variables), qui n'ont plus aucune justification de nos jours et qu'on a donc bannies pour de meilleures alternatives.

Pas chez nous    
 
On doit préfixer le nom de la variable par son type:

 
Et on a pas le droit d'utiliser i,j    
 
Bon pour cette dernière j'ai dit  
ça c'est simplement de la pure connerie.

Préfixer le type d'une méta-donnée c'est ce qui a été fait sur les applis sur lesquelles je travaille et c'est vraiment plaisant d'avoir des st_s_name (ou tu vois tout de suite que tu as affaire à une string simple), c'est quelque chose que je garderais bien si j'avais des modèles de données à créer

T'as vraiment besoin d'un préfixe pour connaître un type de variable ? À moins de travailler avec un IDE en bois, mis à part la force de l'habitude c'est vraiment la règle qui sert à rien

Là c'est plus dans le cadre d'une bdd où tu surcharges un type système avec un sous-type contenant tes méta personnalisées pour ton appli