Envoyé par Médinoc
Ou mettre les variables d'environnement LANG et LC_xxx a quelque chose qui te convient mieux.
Code : Sélectionner tout - Visualiser dans une fenêtre à part env LANG=C g++ ....
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ou mettre les variables d'environnement LANG et LC_xxx a quelque chose qui te convient mieux.
Code : Sélectionner tout - Visualiser dans une fenêtre à part env LANG=C g++ ....
Pas grave, tu m'as bien fait rire.Je me demande bien ce qui m'était passé par la tête lorsque j'ai posté tout-à-l'heure
Il n'y a pas de bons moyens de formater une fonction avec 24 arguments. Il faut changer ce constructeur.
Pour en revenir aux indentations, j'arrive à comprendre l'illusion qu'utiliser la tabulation permet d'adapter un code aux goûts de chacun.
Seulement, le problème est qu'au final les alignements (de paramètres, de commentaires, ...) ne sont valables que dans le cadre d'une taille d'indentation donnée.
Du coup, on a vite un code qui ne peut être visionné correctement qu'avec une taille d'indentation précise, ce qui lêve tout intérêt à la réindentation dynamique par modification de la taille de la tabulation. Où alors, il faut abandonner les alignements. Sans parler que certaines règles de qualité débordent sur la typographie et imposent la taille de l'indentation -- pourquoi alors jouer avec la taille de la tabulation dans ces cas là ?
Perso, je préfère pouvoir aligner ce qu'il me plait et tant qu'à faire utiliser simplement des outils qui utilisent une tabulation à 8, qu'elle soit configurable ou non.
PS: il n'y a pas de bonne solution. C'est juste qu'après divers essais, j'en suis revenu aux 100% de caractères espace.
PPS: cela a peut-être changé, je me souviens qu'avec les anciens forums, indenter à la tabulation était catastrophique après un copier-coller. Et des mails tabulés, n'en parlons même pas.
PPPS: Avec vim, je réindente sans me poser de questions avec un "simple" "gg=G". Vu mon .vimrc, les tabulations disparaissent aussitôt. Le seul défaut, une mauvaise compréhension des templates sur plusieurs lignes. Avec un réglage différent de 'expandtab', 'sw' et 'tabstop', le contraire (pour passer en 100% tabulation) est aussi simple à faire -- il s'agit de la même séquence de touches à taper.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Là encore, ça dépend de ce qu'on fait.
Mon code, avec un espace maximum de décalage, passe partaitement quelles que soient les tabulations.
Et les indentations par espaces uniquement, c'est ch***t comme tout à gérer...
Ça prend 4 fois plus de temps et fatigue 4 fois plus les doigts...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Ah ben. Quelle idée que de développer avec le bloc-note ?
Quand je tape je n'indente jamais rien explicitement: de saut de ligne en saut de ligne, je suis toujours au bon endroit. A la limite quand je refactorise et supprime des accolades (*), un simple "=i{" et le bloc courant est réindenté
(*) l'introduction d'accolades/if/for/while/... englobant(e)s réindente automatiquement avec mes macros.
PS: ca ne serait pas contraire à la règle d'utiliser la tabulation que d'avoir des espaces en plus ?
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
+1
J'ai pas les mêmes séquences de touches -- emacs oblige -- mais j'ai la même fonctionnalité. J'ai même en projet quelques fonctions qui me coupent toutes seules les lignes trop longues. Mais le résultat n'est pas encore d'une qualité acceptable à mon goût: il y a peut-être trop de facteurs non syntaxiques à prendre en compte.
Si on se contente comme adaptation de changer la taille de l'indentation, il y a moyen d'utiliser une combinaison de tabulations et d'espaces initiaux. J'ai l'impression que Médinoc utilise un cas particulier où il n'y a jamais qu'un espace initial.Pour en revenir aux indentations, j'arrive à comprendre l'illusion qu'utiliser la tabulation permet d'adapter un code aux goûts de chacun.
Mais il y a d'autres facteurs. Sans parler de la position des accolades et des labels et de l'éventuel alignement des identificateurs dans les déclarations, la taille totale de la ligne est très différente entre une indentation de 2 et une de 8. Hors il faut aussi une contrainte sur la taille de la ligne.
+1 aussi, tous les éditeurs de code un minimum corrects permettent d'indenter automatiquement comme on le demande, ou presque.
Mais certains, comme gedit, n'ont pas cette option par défaut...
Passionnant sujet, l'indentation ; si on ajoute le positionnement des accolades, ça donne plusieurs styles d'indentation.
Le titre de ce topic étant assez général, autant continuer avec :
- Le bon nommage des variables (nom significatif pour les variables ; utilisation de l'anglais ; pertinence ou non de la notation hongroise-type en C++)
- La casse à utiliser pour le nommage (unNomDescriptif ou un_nom_descriptif)
- L'utilisation de '_' en pré/postfixe pour les membres et méthodes non publics
- L'utilisation de ++ préfixe (++i au lieu de i++ si possible)
- ...
1) On s'en fout complètement à part pour le nom pertinent, c'est un point non pertinent.
2) Même chose que le point 1, ce n'est pas pertinent, sauf dans des cas où les templates peuvent jouer, mais là, dans tous les cas, il faut discuter, donc...
3) Interdit en préfixe, et pour le postfixe, c'est comme pour ce qui est au-dessus.
4) C'est pas une simplicité de lecture qui fait le choix, c'est une question d'optimisation, donc rien à voir.
Les premiers exemples que tu donnes sont expressément classés dans les "on s'en fout" de Sutter et Alexandrescu, il y a tout de même largement plus important que savoir si on utilise telle ou telle convention de nommage !
Je suis d'accord, mais alors, au vu des précédents messages, en quoi l'utilisation de tab/espaces est-elle plus importante que la convention de nommage ?
Je n'y participe pas parce qu'effectivement je trouve cela aussi inutile que les conventions de nommage, mais comme tu essayais de recadrer le sujet avec ces propositions...
Je n'ai pas lu le livre en question, mais dire on s'en fout, ça me semble exagéré.
Je travaille actuellement sur du code où chaque intervenant utilise ses propres conventions, et je trouve que ça rend le code quand même bien moins lisible. Je suis d'accord qu'on s'en foute que ce soit l'un où l'autre, et même qu'en s'en foute que ce soit l'un dans un module, l'autre dans un autre module, mais les deux mélangés dans le même module, je trouve que ça a un impact négatif.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Le choix des détails de la convention est relativement peu important. Le choix et le respect d'une convention est important.
Si je n'aime pas les tabulations, c'est surtout parce que j'ai constaté que l'utilisation des tabulations était un obstacle au respect. Peut-être pas avec une personne sur peu de temps, certainement avec beaucoup de monde sur une longue période.
Pour le "on s'en fout", disons qu'un ouvrage sur la qualité n'a pas à traiter cela. Ou pour être plus précis et exact, un ouvrage sur la qualité n'a pas à dire "ce choix est meilleur". Car il n'y a pas vraiment de meilleur choix. Juste des goûts.
En revanche sur un projet, il est quand même important qu'une convention spécifie un minimum ces choses.
Pour la notation hongroise, j'avais croisé un article sur joelonsoftware qui recadrait un petit peu la notation hongroise. 90% des codeurs croient que c'est un truc qui se rajoute au type des données (cette vision se retrouve dans le document de Linus Torvald donné plus haut), alors qu'en fait c'est un truc qui donne de l'information quand à la nature (kind) des données. La nuance est subtile et pas si négligeable.
Dans l'absolu, en C++ on pourrait exploiter à fond le systême de typage et rajouter autant de types que de choses que l'on manipule. Mais est-on vraiment prêts à avoir des types ColonneIdx, LigneIdx, ... alors qu'un simple int suffirait ?
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Ç'est ce qui se fait en Ada même si ce n'est pas obligatoire. Ça détecte des bugs à la compilation de temps en temps qu'en C++ il est parfois pénible de débugger. Ada et Pascal sont les deux seuls langages que je connais où c'est facile à faire. Il est possible que ce soit aussi le cas dans les modula (1, 2, 3), je ne sais plus: ce n'est pas des langages que j'ai pratiqués. Wirth a abandonné l'idée dans les Oberons.
Pour le faire en C++, il faudrait se bâtir une bibliothèque pour -- y compris des conteneurs. Quand j'ai commencé le C++, je l'aurais peut-être bien fait mais je n'avais pas à l'époque la maîtrise des templates pour le faire. Maintenant je ne suis pas sûr que les avantages vaille la peine de faire la bibliothèque et de se battre pour en imposer l'usage.
Répondre avec citation
Partager