Je n'ai pour ma part en effet fait que du 2, essentiellement pour de petits outils/scripts ou le shell montrait ses limites…
Bonne chose que cela ait été corrigé en 3. Désormais, je passe un "expand -t 8" dès que je récupère un source pour voir visuellement si un truc se décale. Mais c'est vraiment fastidieux car cela oblige à comprendre chaque bout de source ou le problème se présente pour savoir de quel côté il faut mettre la/les lignes en question.
Astyle reformate n'importe quel code C au goût de celui qui le reprends, sans erreur possible.
Forcément, là le style on s'en fout car la grammaire est robuste.
Délimiter les blocs avec des indentations est LA très mauvaise idée du Python ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
Après cela, on a beau jeu de dire que le C est dangereux…
Ce qui éviterait d'avoir l'interpréteur qui exécute parfois un code qui n'est pas celui présenté visuellement à son auteur.
Ne pas avoir voulu mettre de délimiteur de bloc amène à cette situation. C'est certes volontaire pour pousser à présenter correctement, mais c'est hyper dangereux: Le nb de fois ou j'ai eu la fin d'un bloc qui était sorti du bloc après édition avec des éditeurs configurés différemment, sans que visuellement cela apparaisse.
Et sur un langage avec délimiteurs (genre {} en C), les outils automatiques permettent de reformater sans problème. Pas avec Python: Il faut avoir en tête ce que fait le programme pour savoir s'il y a un truc qui sort du bloc pour des questions de présentation ou non.
Le genre de "détail" qui flingue un langage pour une utilisation ou la fiabilité est fondamentale.
Se rendre compte qu'il y a un problème le jour ou la branche de code interprétée de travers (vs sa représentation visuelle) est exécutée, c'est vraiment un problème.
Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.
[^] # Re: Pourquoi je n'aime pas Python...
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 0.
Je n'ai pour ma part en effet fait que du 2, essentiellement pour de petits outils/scripts ou le shell montrait ses limites…
Bonne chose que cela ait été corrigé en 3. Désormais, je passe un "expand -t 8" dès que je récupère un source pour voir visuellement si un truc se décale. Mais c'est vraiment fastidieux car cela oblige à comprendre chaque bout de source ou le problème se présente pour savoir de quel côté il faut mettre la/les lignes en question.
[^] # Re: Retour sur des grosses applications
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 1.
Astyle reformate n'importe quel code C au goût de celui qui le reprends, sans erreur possible.
Forcément, là le style on s'en fout car la grammaire est robuste.
Délimiter les blocs avec des indentations est LA très mauvaise idée du Python ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
Après cela, on a beau jeu de dire que le C est dangereux…
[^] # Re: Pourquoi je n'aime pas Python...
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 3.
Ce qui éviterait d'avoir l'interpréteur qui exécute parfois un code qui n'est pas celui présenté visuellement à son auteur.
Ne pas avoir voulu mettre de délimiteur de bloc amène à cette situation. C'est certes volontaire pour pousser à présenter correctement, mais c'est hyper dangereux: Le nb de fois ou j'ai eu la fin d'un bloc qui était sorti du bloc après édition avec des éditeurs configurés différemment, sans que visuellement cela apparaisse.
Et sur un langage avec délimiteurs (genre {} en C), les outils automatiques permettent de reformater sans problème. Pas avec Python: Il faut avoir en tête ce que fait le programme pour savoir s'il y a un truc qui sort du bloc pour des questions de présentation ou non.
Le genre de "détail" qui flingue un langage pour une utilisation ou la fiabilité est fondamentale.
Se rendre compte qu'il y a un problème le jour ou la branche de code interprétée de travers (vs sa représentation visuelle) est exécutée, c'est vraiment un problème.
Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.