Discussion :

[souviron34]

Enfin l'indentation plutôt que les accolades te permet simplement de ne pas bousiller ton canal carpien inutilement et de rendre ton code plus lisible. C'est une amélioration claire et nette.
.

ch'sai pas, moi, mais que ce soit avec Xemacs sur Linux ou NotePad++ sur Windows, ou Eclipse sur les 2, ça me fait mes indentations proprettes sans que j'ai rien à faire..

Avec quoi écris-tu des programmes en C ???

[souviron34]

Si tu ne sépares pas ton code en headers et sources tu te retrouves avec des temps de compilation qui explosent.

euh.......

Voir plus bas...

J'avais oublié cette morgue bien mal placée qui te caractérise.

Relis, mon cher.. Rien de morgue, simplement une constatation, dénuée de toute arrière-pensée ou sous-entendu ou ton, je pense réellement et sérieusement ce que je dis, tellement tes arguments semblent de mauvaise foi par rapport à la pratique que j'en ai depuis presque 30 ans..

[Fr001]

finie la pluie de ; { } ... Ritchie marchera du tonnerre.
A mon tour de proposer un historique et une réflexion sympa
Web Apps: Past & Future, Michael Bromley 2015-11 http://slides.com/michaelbromley/deck-6#/

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

[gangsoleil]

Le C en lui-même est un langage dépassé en termes de fonctionnalité et productivité.

Mais il reste souvent le meilleur choix pour le bas niveau pour des raisons liées à l'écosystème et parce que très peu de nouveaux langages se sont attaqués à cette niche. Ce qui est heureusement en train de changer (Rust et Julia, et d'autres pour les systèmes critiques)..

Sans parler de bas niveau, les clients des entreprises dans lesquelles j'ai travaillé demandent du code qui tourne sous Linux, Solaris et AIX. Rust et Julia n'existent visiblement pas pour les deux derniers, c'est déjà une très forte limitation -- et je n'ai même pas spécifié des entreprises ésotériques qui feraient de l'embarqué sur des systèmes qui n'implémentent même pas le C standard.

Enfin, l'un des gros avantages du C est sa stabilité : il m'est régulièrement arrivé de modifier des codes qui avaient plus de 20 ans, et qui tournent toujours très bien, justement car le langage est stable, et qu'il n'y a pas besoin de se demander si le passage à la version 7.4.8.42 va tout casser par rapport à la 41. Je ne connais pas beaucoup de langages qui peuvent en dire autant, et encore moins les langages récents.
Après, pour ce qui est de faire un prototype, je suis d'accord sur le fait qu'il est probablement plus rapide, en théorie, de l'écrire dans un langage plus récent. Mais mon soucis est que la plupart des prototypes que j'ai écrits ou revus sont aujourd'hui en production chez les clients, tels quels, et ce pour encore pas mal d'années. Donc là encore, si je les avais écris dans un langage évoluant, je devrai me taper le portage régulièrement.

[chris_FR]

J'ai juste parcouru quelques exemples et ne suis pas entré dans le détail
mais c'est pas facile a lire comme langage
Si il y avait une chose a prendre dans python c'est sa lisibilité

[RPGamer]

Les exemples sont pour le moins dégueulasses.

Pas convaincus non plus par les choix fait.

[lafarge]

Pas de mots réservés, à redéfinir comme en Forth par exemple ?