Citation:
Envoyé par Médinoc
Ou mettre les variables d'environnement LANG et LC_xxx a quelque chose qui te convient mieux.Code:env LANG=C g++ ....
Version imprimable
Citation:
Envoyé par Médinoc
Ou mettre les variables d'environnement LANG et LC_xxx a quelque chose qui te convient mieux.Code:env LANG=C g++ ....
Pas grave, tu m'as bien fait rire.Citation:
Envoyé par spidermario
Il n'y a pas de bons moyens de formater une fonction avec 24 arguments. Il faut changer ce constructeur.Citation:
Envoyé par Médinoc
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.
Là encore, ça dépend de ce qu'on fait.Citation:
Envoyé par Luc Hermitte
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...
Ah ben. Quelle idée que de développer avec le bloc-note ?Citation:
Envoyé par Médinoc
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é :P
(*) 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 ?
+1Citation:
Envoyé par Luc Hermitte
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.Citation:
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.Citation:
Envoyé par boromir73
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 ?Citation:
Envoyé par Miles
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.
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 ?
Ç'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.Citation:
Envoyé par Luc Hermitte
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.