La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix.
Les réponses multiples sont interdites pour les mêmes raisons.
Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses.
76,78 % des personnes sondées estiment que ces sondages sont ineptes.
Ceci est un sondage qui nous a été proposé par Hervé. Merci à lui.
Sachez que nous avons reçu pas mal de proposition ces derniers temps, donc si vous ne voyez pas la vôtre tout de suite, c'est normal, la file d'attente est assez remplie et si on s'en tient à http://linuxfr.org/poll/send,204.html il ne devrait changer que tous les 15 jours.
J'avais proposé le même sondage il y a quelques mois, avec comme choix supplémentaire la taille des indentaions (3 / 4 / 8 ...) Le refus implicite, c'est parce que c'est trop compliqué de proposer des choix avec des nombres à une moule?
Il y a quelques mois, les messages envoyés à sondages@linuxfr.org n'étaient pas reçu. Ce point a été corrigé depuis quelques semaines seulement.
Ce sondage a été proposé il y a une douzaine de jours et on l'a publié. On préfère juste procéder en deux fois. Le prochaine concernera donc la taille des indentations.
existe t il une liste quelque part des sondages en attentes ?
Histoire de pas re-proposer des trucs qui ont déjà été proposé, vérifier que la proposition qu'on a fait a été reçu, voir dans combien de temps la proposition qu'on a fait sera en ligne...
ca sert peut etre pas à grand chose mais bon .... ;)
Non, ca n'existe pas. Enfin si, dans la boite email des admins.
Tout comme pour les dépêches, je ne suis pas sûr que la visibilité avant publication soit la meilleure des choses. Il y a du spam, des conneries, etc. et parmi les propositions, on peut souvent fusionner deux propositions intéressantes sur le même sujet pour un tirer un sondage plus sympa que si un seul des deux était proposé.
Pour l'accusé de réception, j'essaye de répondre quand le msg a été reçu.
Quant à savoir quand elle sera en ligne, c'est plus dur... la file d'attente est déjà pas mal remplie...
« […] et parmi les propositions, on peut souvent fusionner deux propositions intéressantes sur le même sujet pour un tirer un sondage plus sympa […] »
Justement, si les sondages proposés étaient ouverts aux commentaires, cela permettrait des améliorations en collaboration avec tous les contributeurs, plutôt que seulement celles des admins. Non ?
On parle juste de sondage dont, je le rapelle, 76,78% des sondés estiment qu'ils sont ineptes ! L'équipe de modération du site a déjà pas mal à faire avec les autres contenus après leur soumission.
L'effet pervers que je vois est qu'on arriverait à des contenus policés, tous issus d'un consensus mou si l'on devait ouvrir aux commentaires les contenus proposés avant publication. Pas très propice aux tro^W débats :)
Ou pas : chacun viendrais mettre son grain de sel puis l'équipe qui publie les sondages prendrait sa décision. Probablement pas plus policée que ce qui se fait actuellement. Sauf qu'un peu plus de petites mains, affairées sur leurs claviers, auraient eu l'occasion d'abonder de leurs idées.
Non, je n'ai pas répondu « les deux » : c'est une pratique aberrante. Mais je trouve amusant que ce soit le réglage par défaut de Vim et d'Emacs, de faire un affreux mélange de tabulations et d'espaces. Ceux qui font ça devraient être, euh, condamnés à faire du Lisp tout leur vie.
> les tabulations restent indispensables pour les Makefile.
Pas vrai. Tu peux utiliser la variable .RECIPEPREFIX pour changer le préfix des règles :
http://www.gnu.org/software/make/manual/make.html#Special-Variables
Et là, tu commences sérieux à rendre le Makefile pâteux. Déjà que c'est pas simple à lire...
De mon coté, depuis mes débuts avec le Lattice C dans les années 80, j'ai réussi à m'en tenir au Whitesmiths, qui est de loin le plus visuellement parfait.
Parce l'indentation représente un nouveau contexte empilé, et que c'est l'intérieur des accolades qui a un contexte particulier. Les accolades elle-mêmes ne font que grouper les instructions qui sont dedans, en tant que telles elles sont juste une instruction normale.
Mais non voyons, seul le style lisp est raisonnable ! Comment peux-t-on imaginer en utiliser un autre ! Lisp RuLZ !
Sérieusement, l'un des avantages du style lisp, c'est d'économiser la place. Et ça pour la mise en forme de sujets d'examen de programmation, c'est essentiel. Sinon, ça restreint aussi les nécessités de déplacements pour observer des morceaux de codes.
Sans le savoir je faisais du Contextual style ...
j'ai donc involontairement copié Milan Adamovsky, Ou peut-être est-ce lui qui aurait copié sur moi ??
et il y a des éditeurs de texte qui gèrent ça où il faut le faire à la main ?
Parce qu'effectivement, c'est le style idéal d'indentation je trouve. Mais très contraignant (car nécessite de changer le tabsize et ça bugge avec certains)
Les tabulations et les espaces c'est mal, parce que dès que l'indentation et les aligements de commentaires d'un utilisateur A passent mal chez l'utilisateur B qui n'a pas configuré ses indentations pareil.
Nick Gravgaard a inventé les « elastic tabstops », qui pourraient se traduire par « tabulations élastiques ». L'idée est que le même texte puisse apparaître correctement quel que soit les préférences d'indentation de chacun. C'est à dire qu'une tabulation sert vraiment à indenter, et que l'alignement des commentaires ou de code sont garanties d'une ligne sur l'autre, quel que soit le texte écrit avant.
Avec un vrai éditeur, il est possible de définir la taille des indentations directement dans le fichier, comme ca c'est indépendant des réglages de l'utilisateur, donc le source est toujours formaté tel que l'a voulu d'auteur.
par exemple, des commentaires à placer a la fin d'un fichier C++, pour emacs :
// Local Variables:
// mode: c++
// tab-width: 8
// End:
Et la meme chose pour vim :
// vim: set ts=8 sw=4 filetype=cpp
Evidemment, on peut mettre les deux simultanément, comme ca tout le monde est content...
Un vrai éditeur devrait être capable de déterminer automatiquement le type d'indentation et de le reproduire, même si il n'est pas indiqué explicitement.
Oui c'est assez compliqué, si on veut un résultat fiable et précis, sachant qu'il existe pas mal de variantes possible.
Non, je ne connais aucun éditeur ou outil qui fasse cette reconnaissance... à part un bout de code dans mon home, qui ne marche pas très bien et sur lequel il faudrait que je passe plus de temps... c'est pas gagné.
>> Un vrai éditeur devrait être capable de déterminer automatiquement le type d'indentation et de le reproduire, même si il n'est pas indiqué explicitement.
Ça demande qu'on écrive un analyseur syntaxique pour chaque langage…
C'est pas gagné…
N'exagérons rien... la taille des tabulations, l'utilisation d'espace uniquement, la taille des niveaux d'indentation peuvent être déterminées globalement. Ensuite, il y a effectivement des subtilités suivant les langages comme l'indentation Smart Tab en C, mais il n'y a pas besoin pour autant d'un analyseur syntaxique... à moins que tu penses à un exemple précis?
Désolé, mais ce genre de choses me choque complètement... J'ai des collègues qui indentent avec des tabs à 2 espaces. Avec une indentation aussi "subtile", je ne vois strictement rien à la structure du code. Donc je règle mes tabs à 6 ou 8 charactères. Et je n'ai pas à leur imposer mes choix...
Le boulot d'un bon éditeur n'est pas de m'imposer la façon dont je dois voir le code, mais de faire que l'indentation s'adapte à mon souhait, et que les alignements soient respectés. D'où mon choix d'indenter avec des tabs et d'aligner avec des espaces (la version "elastic tab stops" du pauvre).
Les tabulations et les espaces c'est mal, parce que dès que l'indentation et les aligements de commentaires d'un utilisateur A passent mal chez l'utilisateur B qui n'a pas configuré ses indentations pareil.
Oui et non. Cela dépend du style adopté pour l'alignement des paramètres d'une fonction par exemple. Si tu codes comme ceci, pas de problème:
void ma_fonction (int param1, int param2, int param3)
{
}
Mais dans de nombreux projets, on met les paramètres d'entrée et de sortie sur des lignes différentes pour voir plus facilement ce qui a changé lors d'un diff. Et là tu as des styles différents...
1. ceux qui alignent les paramètres entre eux (chose que tu ne peux faire qu'avec des espaces)
void
ma_fonction (int param1,
int param2,
int param3)
{
}
Ou bien
2. tu décides que seuls les paramètres 2 à n seront alignés entre eux, et tu utilises un nombre fixe de tabulations (en général 2) pour les indenter.
void
ma_fonction (int param1,
int param2,
int param3)
{
}
Le cas 1 est un exemple classique de où un utilisateur habituel de tabulations est obligé d'utiliser des espaces. Et le résultat fonctionne quelque soit la configuration. Pour faire du relatif -> tabulation, pour faire de l'absolu -> espaces.
Perso, je préfère le cas 2. Il n'oblige pas à toucher à des lignes sans autre raison que changer l'indentation, comme par exemple quand on change le nom de la fonction et qu'il devient plus long ou plus court.
Je préfère écrire dans mon code personnel. Je n'aime pas mettre les , à la fin de mes phrases, je ne les vois pas. void
ma_fonction
( int param1
, int param2
, int param3
) {
/* ... */
}
On peut faire le cas 1 avec des tabulations, et tout restera bien aligné.
Il suffit de mettre une tabulation après la parenthèse ouvrante.
void
ma_fonction( int param1,
int param2,
int param3)
{
}
Cela dit, il m'arrive d'utiliser aussi des espaces, par exemple pour aligner sur plusieurs lignes une condition de test compliquée (avec plein de &&, de || et de parenthèses).
On peut faire le cas 1 avec des tabulations, et tout restera bien aligné.
Justement non, c'est bien pour cela que je dis que c'est le seul cas où on est obligé d'utiliser des espaces.
Soit x la largeur d'une tabulation. En général x = 4 espaces. Dans ton exemple, "int param1" commence à 12 + x. 12 est le nombre de caractères de "ma_fonction(". Or si tu as quelques connaissances en algèbre, tu te rendras vite compte que cela ne fonctionne pas.
La ligne suivante avec des espaces vaudra 14. Avec que des tabulations vaudra n*x où n est un entier. Tenter de faire 12 + x = 14 te fait déduire que x = 2, or chaque éditeur ou utilisateur peut régler la taille des tabulations. Un utilisateur qui utilise autre chose que la largeur de 2 espaces pour une tabulation ne verra plus les variables alignées.
Le seul moyen c'est même nombre de tabulations et d'espaces sur chaque ligne avant les éléments à aligner...
Je fais exactement pareil et voici comment s'en servir: la tabulation indique la "profondeur" du bloc d'instructions, et les espaces (situés après des caractères de tabulation) servent pour l'alignement à l'intérieur du bloc.
Pourquoi ? c'est simple: l'alignement à l'intérieur du bloc doit se faire au caractère prêt, et la taille du caractère de tabulation peut changer d'un éditeur à l'autre. Résultat: quelque soit la configuration de l'éditeur utilisé, le code source est correctement visible peu importe les préférences de la taille de la tabulation.
Et il semblerait d'après un commentaire plus haut que c'est la méthode d'indentation utilisée par le kernel linux (https://linuxfr.org/comments/1173156.html#1173156 qui montre aussi un exemple du concept )
Les espaces sont généralement peu fréquent car ils servent pour les lignes trop longues ou autres cas rares.
Par contre, ceux qui indentent qu'avec des espaces négligent totalement les préférences d'indentation des utilisateurs (j'ai déjà vu du 8 espaces qui est trop pour moi, ou 2 pas assez, chacun ses préférences ceci dit).
Personnellement je n'ai jamais compris l'intérêt d'indenter avec des espaces (d'ailleurs, je parle normalement de tabulation, ce n'est pas pour rien). Je trouve ça peu pratique au possible. Le pire ce sont ceux qui indentent du code avec un ou deux espaces.
C'est marrant, car le kernel exige une indentation de 8, mais pour la même raison... car si il y a trop de niveau d'indentation, c'est que le code est mauvais et doit être réécrit.
« J'imagine qu'avec des espaces il aura toujours la même tronche (la longueur de la tabulation peut varier d'un environnement à un autre). »
Justement, c'est tout l'intérêt ! Ainsi chacun peut lire le code avec ses propres préférences. Par exemple toi qui n'aime pas le code fortement indenté tu peux régler ta taille de tabulation à 2, tandis que ton voisin la mettra par exemple à 8.
Je sens venir l'argument : « oui mais si on change la taille ça fait n'importe quoi ». Quand ça arrive ça veut dire que soit il y a un mélange de tabulations et d'espaces (beuargh), soit le programmeur a fait la connerie d'aligner avec des tabulations. Les tabulations c'est pour indenter, pas pour aligner.
Sauf que un point habituel dans les règles de codage est la taille max de la ligne, souvent fixée à 80 caractères : si un type s'amuse à coder avec des tabs de 2 ou 4, il risque de dépasser cette limite sans s'en apercevoir.
De plus, s'amuser à vouloir changer la taille des tabs, ça casse forcement l'indentation dans des cas précis : int.moule(void).{......//.cette.fonction
------->return.0;......//.renvoie.toujours.0
}
L'autre point, c'est que les éditeurs ne gère pas très bien cette fonctionnalité. À part Emacs, vous connaissez quel éditeur qui la gère?
La limitation à 80 caractères, ca vient surtout de la taille des cartes perforées ... et donc du FORTRAN (77 et antérieur). Même une vénérable VT100 peut afficher 132 colonnes.
Je suis d'accord qu'il faut des lignes de taille raisonnable, mais j'ai tendance à mettre une limite floue, quelque part vers 120 colonnes, voire plus si le besoin s'en fait sentir.
En tout cas, cumuler des tabulations à 8 espaces et une limitation à 80 caractères par ligne, c'est se tirer une balle dans le pied. Dès qu'on imbrique deux tests et un switch, hop, on est coinçé pour utiliser des noms de variable un peu explicites. Et les retours à la ligne automatiques sont à mon avis un remède bien pire que le mal, en terme de lisibilité.
Un autre problème de dépassement de ligne survient avec les chaînes "longues". Il y a quelque chose que j'aime bien en C, c'est la possibilité de "découper" les chaines sans incidence sur le programme lui-même :
char * string = "blablabla"
"bliblibli"; /*équivalent à "blablablabliblibli"*/
Je ne sais pas si c'est le préprocesseur qui s'en occupait ou le compilateur, mais je trouvais cette fonctionnalité bien pratique, dommage qu'elle n'ait pas été conservée (sauf erreur de ma part) pour d'autres langages à la syntaxe proche.
c'est quand même le truc super chiant quand tu cherche quel code fait ce #$%^^& de message d'erreur, vu que grep ne matche plus! char* error = "FATAL ERROR NUMBER 123"
"456";
Note que l'avantage pour un langage compilé est qu'une telle syntaxe, n'influe pas sur les performances à l'exécution (je sais, ça sert à rien, mais c'est une question de conscience :)).
Bah moi c'est le contraire, je n'utilise que des espaces (deux). Au moins c'est toujours la même largeur, quel que soit l'éditeur.
J'utiliserai des tabulations lorsque leur largeur sera fixée à 2 (ou 3, à l'extrême rigueur) dans tous les éditeurs et que cette valeur ne sera pas modifiable par un utilisateur sadique.
Et au fait en typographie c'est unE espace, pas un espace.
L'intérêt d'indenter, c'est de rendre le code lisible, et d'éviter les fonction avec trop de profondeur (genre 10 boucles imbriquées, ou des conditions qui n'en finissent plus).
8 espaces, qui est la valeur d'origine de la tabulation, c'est effectivement trop. Je trouve personnellement que 4 c'est la taille idéale pour du code source. Au premier coup d'œil je repère l'indentation, et je n'ai pas à trop bouger la tête pour associer l'instruction d'introduction du bloc au bloc. Efficacité, fainéantise, etc.
D'ailleurs, c'est l'efficacité qui me fait haïr l'indentation par les espaces. Je ne vois pas la différence entre 3 espaces et 4 espaces.
En dehors du boulot, le seul endroit où j'utilises des indentations avec des espace c'est dans des fichiers de données (XML, JSON, etc).
Et au boulot, mon source est truffé d'indentation à 4×n+3 parce que entre 7 et 8 tabulations, je ne vois pas la différence. Et Vim (malgré >>) ne m'aide pas beaucoup sur ça. Et l'indentation, en Python, c'est assez important.
« Et au boulot, mon source est truffé d'indentation à 4×n+3 »
Il ne suffirait pas de configurer ton éditeur pour qu'il insère/supprime autant d'espaces que nécessaire à chaque tab/backspace? laisse moi deviner... ton éditeur n'en est pas un, c'est juste un étron modelée en forme d'éditeur, mais tu n'as pas le choix? Dans ce cas, toutes mes condoléances.
J'avoue préférer de loin l'indentation uniquement à base d'espace, car ça limite les grands n'importe quoi, lorsque pleins de personnes touchent au code, chacune avec leur éditeur configuré différemment... mais il existe un cas tordu, relevé dans un commentaire ci dessus, celui des makefiles qui veulent à tout prix des vraies tabulations.
Le soucis c'est que je ne veux pas que mon Vi fasse ça. Quand je demande à Vi de supprimer un caractère, je veux qu'il en supprime un, pas plus. Sinon ça devient rapidement la fête du slip. Mais oui, il faudrait que je modifie le fichier de syntaxe python pour qu'il rougeoie à la vue d'une indentation malformée.
Moi, je code en Python. Pas d'accolades, pas d'ambiguïté, pas de guerre d'indentation possible : l'indentation est obligatoire et se suffit à elle-même.
La question était à propos du style d'indentation. En python, l'indentation se compte en nombre d'espaces, ou équivalent-espace (quand on mélange avec des tabulations, miam).
# Proposition de sondage
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
Sachez que nous avons reçu pas mal de proposition ces derniers temps, donc si vous ne voyez pas la vôtre tout de suite, c'est normal, la file d'attente est assez remplie et si on s'en tient à http://linuxfr.org/poll/send,204.html il ne devrait changer que tous les 15 jours.
Merci à tous pour vos propositions.
[^] # Re: Proposition de sondage
Posté par calandoa . Évalué à 3.
[^] # Re: Proposition de sondage
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 2.
Ce sondage a été proposé il y a une douzaine de jours et on l'a publié. On préfère juste procéder en deux fois. Le prochaine concernera donc la taille des indentations.
[^] # Re: Proposition de sondage
Posté par cram51 . Évalué à 3.
Histoire de pas re-proposer des trucs qui ont déjà été proposé, vérifier que la proposition qu'on a fait a été reçu, voir dans combien de temps la proposition qu'on a fait sera en ligne...
ca sert peut etre pas à grand chose mais bon .... ;)
[^] # Re: Proposition de sondage
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Fais une demande sur le suivi.
Ah, on me dit que trop tard, c'est déjà fait… [https://www.linuxfr.org/tracker/1025.html]
[^] # Re: Proposition de sondage
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 2.
Tout comme pour les dépêches, je ne suis pas sûr que la visibilité avant publication soit la meilleure des choses. Il y a du spam, des conneries, etc. et parmi les propositions, on peut souvent fusionner deux propositions intéressantes sur le même sujet pour un tirer un sondage plus sympa que si un seul des deux était proposé.
Pour l'accusé de réception, j'essaye de répondre quand le msg a été reçu.
Quant à savoir quand elle sera en ligne, c'est plus dur... la file d'attente est déjà pas mal remplie...
[^] # Re: Proposition de sondage
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1.
Justement, si les sondages proposés étaient ouverts aux commentaires, cela permettrait des améliorations en collaboration avec tous les contributeurs, plutôt que seulement celles des admins. Non ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Proposition de sondage
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 2.
L'effet pervers que je vois est qu'on arriverait à des contenus policés, tous issus d'un consensus mou si l'on devait ouvrir aux commentaires les contenus proposés avant publication. Pas très propice aux tro^W débats :)
[^] # Re: Proposition de sondage
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Les deux…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
[^] # Re: Les deux…
Posté par Lutin . Évalué à 6.
[^] # Re: Les deux…
Posté par ymorin . Évalué à 4.
Pas vrai. Tu peux utiliser la variable .RECIPEPREFIX pour changer le préfix des règles :
http://www.gnu.org/software/make/manual/make.html#Special-Variables
Et là, tu commences sérieux à rendre le Makefile pâteux. Déjà que c'est pas simple à lire...
[^] # Re: Les deux…
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Les deux…
Posté par Anonyme . Évalué à 4.
Du elisp tu veux dire, avec ingestion de la référence.
[^] # Re: Les deux…
Posté par Anonyme . Évalué à 2.
# une seule ligne
Posté par Jeanuel (site web personnel) . Évalué à 10.
[^] # Re: une seule ligne
Posté par alpentux . Évalué à 6.
Ca me rappelle Hebdogiciel...
Ca nous rajeunit pas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: une seule ligne
Posté par gaaaaaAab . Évalué à 4.
[^] # Re: une seule ligne
Posté par Jeanuel (site web personnel) . Évalué à 4.
nan, je fais le con.
[^] # Re: une seule ligne
Posté par gaaaaaAab . Évalué à 3.
# lequel ?
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 1.
[^] # Re: lequel ?
Posté par riba . Évalué à 1.
Comment tu peux aligner un mélange d'espace et de tabulation, dont tu ne contrôles pas la taille!
Quand je vois du code comme ça (en tabsize=2, ça se voit tout de suite), je @#$%^ essaye de rester calme et poli, mais c'est dur.
# et pour le C ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
De mon coté, depuis mes débuts avec le Lattice C dans les années 80, j'ai réussi à m'en tenir au Whitesmiths, qui est de loin le plus visuellement parfait.
Et vous ?
[^] # Re: et pour le C ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
[^] # Re: et pour le C ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1.
Pourquoi ?
[^] # Re: et pour le C ?
Posté par Anonyme . Évalué à 7.
[^] # Re: et pour le C ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Lisp vaincra (même si ce n'est que dans le style)
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Sérieusement, l'un des avantages du style lisp, c'est d'économiser la place. Et ça pour la mise en forme de sujets d'examen de programmation, c'est essentiel. Sinon, ça restreint aussi les nécessités de déplacements pour observer des morceaux de codes.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: et pour le C ?
Posté par Lutin . Évalué à 2.
Tous mes repères s'écroulent !
[^] # Re: et pour le C ?
Posté par Lutin . Évalué à 5.
[^] # Re: et pour le C ?
Posté par M . Évalué à 2.
[^] # Re: et pour le C ?
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 0.
KNF Style dans la place \o/
[^] # Re: et pour le C ?
Posté par windu.2b . Évalué à 3.
[^] # Re: et pour le C ?
Posté par ymorin . Évalué à 2.
Et quelque soit le langage utilisé : shell, awk, C, C++
[^] # Re: et pour le C ?
Posté par Anonyme . Évalué à 3.
[^] # Re: et pour le C ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Très bonne idée. Je vais essayer de rédiger l'AAV qui va bien.
[^] # Re: et pour le C ?
Posté par Mali (site web personnel) . Évalué à 1.
j'ai donc involontairement copié Milan Adamovsky, Ou peut-être est-ce lui qui aurait copié sur moi ??
[^] # Re: et pour le C ?
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Re: et pour le C ?
Posté par Mathias Bavay (site web personnel) . Évalué à 4.
[^] # Re: et pour le C ?
Posté par Mildred (site web personnel) . Évalué à 1.
Parce qu'effectivement, c'est le style idéal d'indentation je trouve. Mais très contraignant (car nécessite de changer le tabsize et ça bugge avec certains)
# Et les elastic tabstops ?
Posté par zerkman (site web personnel) . Évalué à 5.
Nick Gravgaard a inventé les « elastic tabstops », qui pourraient se traduire par « tabulations élastiques ». L'idée est que le même texte puisse apparaître correctement quel que soit les préférences d'indentation de chacun. C'est à dire qu'une tabulation sert vraiment à indenter, et que l'alignement des commentaires ou de code sont garanties d'une ligne sur l'autre, quel que soit le texte écrit avant.
http://nickgravgaard.com/elastictabstops/
[^] # Re: Et les elastic tabstops ?
Posté par shbrol . Évalué à 5.
par exemple, des commentaires à placer a la fin d'un fichier C++, pour emacs :
// Local Variables:
// mode: c++
// tab-width: 8
// End:
Et la meme chose pour vim :
// vim: set ts=8 sw=4 filetype=cpp
Evidemment, on peut mettre les deux simultanément, comme ca tout le monde est content...
[^] # Re: Et les elastic tabstops ?
Posté par calandoa . Évalué à 2.
Oui c'est assez compliqué, si on veut un résultat fiable et précis, sachant qu'il existe pas mal de variantes possible.
Non, je ne connais aucun éditeur ou outil qui fasse cette reconnaissance... à part un bout de code dans mon home, qui ne marche pas très bien et sur lequel il faudrait que je passe plus de temps... c'est pas gagné.
[^] # Re: Et les elastic tabstops ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ça demande qu'on écrive un analyseur syntaxique pour chaque langage…
C'est pas gagné…
[^] # Re: Et les elastic tabstops ?
Posté par calandoa . Évalué à 2.
[^] # Re: Et les elastic tabstops ?
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
Le boulot d'un bon éditeur n'est pas de m'imposer la façon dont je dois voir le code, mais de faire que l'indentation s'adapte à mon souhait, et que les alignements soient respectés. D'où mon choix d'indenter avec des tabs et d'aligner avec des espaces (la version "elastic tab stops" du pauvre).
Mathias
[^] # Re: Et les elastic tabstops ?
Posté par liberforce (site web personnel) . Évalué à 7.
Oui et non. Cela dépend du style adopté pour l'alignement des paramètres d'une fonction par exemple. Si tu codes comme ceci, pas de problème:
void ma_fonction (int param1, int param2, int param3)
{
}
Mais dans de nombreux projets, on met les paramètres d'entrée et de sortie sur des lignes différentes pour voir plus facilement ce qui a changé lors d'un diff. Et là tu as des styles différents...
1. ceux qui alignent les paramètres entre eux (chose que tu ne peux faire qu'avec des espaces)
void
ma_fonction (int param1,
int param2,
int param3)
{
}
Ou bien
2. tu décides que seuls les paramètres 2 à n seront alignés entre eux, et tu utilises un nombre fixe de tabulations (en général 2) pour les indenter.
void
ma_fonction (int param1,
int param2,
int param3)
{
}
Le cas 1 est un exemple classique de où un utilisateur habituel de tabulations est obligé d'utiliser des espaces. Et le résultat fonctionne quelque soit la configuration. Pour faire du relatif -> tabulation, pour faire de l'absolu -> espaces.
Perso, je préfère le cas 2. Il n'oblige pas à toucher à des lignes sans autre raison que changer l'indentation, comme par exemple quand on change le nom de la fonction et qu'il devient plus long ou plus court.
[^] # Re: Et les elastic tabstops ?
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: Et les elastic tabstops ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
voidma_fonction
( int param1
, int param2
, int param3
) {
/* ... */
}
[^] # Re: Et les elastic tabstops ?
Posté par riba . Évalué à 8.
[^] # Re: Et les elastic tabstops ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Ceci répond-il à ta question ? :D
[^] # Re: Et les elastic tabstops ?
Posté par Jimmy . Évalué à 3.
Il suffit de mettre une tabulation après la parenthèse ouvrante.
voidma_fonction( int param1,
int param2,
int param3)
{
}
Cela dit, il m'arrive d'utiliser aussi des espaces, par exemple pour aligner sur plusieurs lignes une condition de test compliquée (avec plein de &&, de || et de parenthèses).
[^] # Re: Et les elastic tabstops ?
Posté par liberforce (site web personnel) . Évalué à 2.
Justement non, c'est bien pour cela que je dis que c'est le seul cas où on est obligé d'utiliser des espaces.
Soit x la largeur d'une tabulation. En général x = 4 espaces. Dans ton exemple, "int param1" commence à 12 + x. 12 est le nombre de caractères de "ma_fonction(". Or si tu as quelques connaissances en algèbre, tu te rendras vite compte que cela ne fonctionne pas.
La ligne suivante avec des espaces vaudra 14. Avec que des tabulations vaudra n*x où n est un entier. Tenter de faire 12 + x = 14 te fait déduire que x = 2, or chaque éditeur ou utilisateur peut régler la taille des tabulations. Un utilisateur qui utilise autre chose que la largeur de 2 espaces pour une tabulation ne verra plus les variables alignées.
Le seul moyen c'est même nombre de tabulations et d'espaces sur chaque ligne avant les éléments à aligner...
# La seule vrai bonne façon de faire que j'ai raison et pas les autres
Posté par Tonton Benoit . Évalué à 5.
- J'aligne avec des espaces
Vu que le sondage ne parle que d'indentation j'ai donc voté "des tabulations".
[^] # Re: La seule vrai bonne façon de faire que j'ai raison et pas les autre
Posté par nerbrume . Évalué à 3.
[^] # Re: La seule vrai bonne façon de faire que j'ai raison et pas les autre
Posté par Thrillseeker . Évalué à 2.
Pourquoi ? c'est simple: l'alignement à l'intérieur du bloc doit se faire au caractère prêt, et la taille du caractère de tabulation peut changer d'un éditeur à l'autre. Résultat: quelque soit la configuration de l'éditeur utilisé, le code source est correctement visible peu importe les préférences de la taille de la tabulation.
Et il semblerait d'après un commentaire plus haut que c'est la méthode d'indentation utilisée par le kernel linux (https://linuxfr.org/comments/1173156.html#1173156 qui montre aussi un exemple du concept )
Les espaces sont généralement peu fréquent car ils servent pour les lignes trop longues ou autres cas rares.
Par contre, ceux qui indentent qu'avec des espaces négligent totalement les préférences d'indentation des utilisateurs (j'ai déjà vu du 8 espaces qui est trop pour moi, ou 2 pas assez, chacun ses préférences ceci dit).
# Indentation par l'espace
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
[^] # Re: Indentation par l'espace
Posté par Anonyme . Évalué à 5.
Au fait, j'indente avec deux espaces maximum, parce que je déteste voir un ascenseur horizontal dans une page de code :)
(Ou une césure de ligne avec Emacs, etc.)
[^] # Re: Indentation par l'espace
Posté par calandoa . Évalué à 6.
[^] # Re: Indentation par l'espace
Posté par Anonyme . Évalué à 2.
- Bon, y a plus de bouteilles ici, maintenant c'est de l'eau, compris ?
Voici la méthode kernel :
- Allez, bois de force ces verres. Si tu en bois un de plus, il te mettra raide KO et tu finiras en tutu sur Facebook.
:D
[^] # Re: Indentation par l'espace
Posté par e-t172 (site web personnel) . Évalué à 2.
Justement, c'est tout l'intérêt ! Ainsi chacun peut lire le code avec ses propres préférences. Par exemple toi qui n'aime pas le code fortement indenté tu peux régler ta taille de tabulation à 2, tandis que ton voisin la mettra par exemple à 8.
Je sens venir l'argument : « oui mais si on change la taille ça fait n'importe quoi ». Quand ça arrive ça veut dire que soit il y a un mélange de tabulations et d'espaces (beuargh), soit le programmeur a fait la connerie d'aligner avec des tabulations. Les tabulations c'est pour indenter, pas pour aligner.
[^] # Re: Indentation par l'espace
Posté par calandoa . Évalué à 4.
De plus, s'amuser à vouloir changer la taille des tabs, ça casse forcement l'indentation dans des cas précis :
int.moule(void).{......//.cette.fonction------->return.0;......//.renvoie.toujours.0
}
L'autre point, c'est que les éditeurs ne gère pas très bien cette fonctionnalité. À part Emacs, vous connaissez quel éditeur qui la gère?
[^] # Re: Indentation par l'espace
Posté par Jimmy . Évalué à 7.
Je suis d'accord qu'il faut des lignes de taille raisonnable, mais j'ai tendance à mettre une limite floue, quelque part vers 120 colonnes, voire plus si le besoin s'en fait sentir.
En tout cas, cumuler des tabulations à 8 espaces et une limitation à 80 caractères par ligne, c'est se tirer une balle dans le pied. Dès qu'on imbrique deux tests et un switch, hop, on est coinçé pour utiliser des noms de variable un peu explicites. Et les retours à la ligne automatiques sont à mon avis un remède bien pire que le mal, en terme de lisibilité.
[^] # Re: Indentation par l'espace
Posté par Anonyme . Évalué à 3.
char * string = "blablabla""bliblibli"; /*équivalent à "blablablabliblibli"*/
Je ne sais pas si c'est le préprocesseur qui s'en occupait ou le compilateur, mais je trouvais cette fonctionnalité bien pratique, dommage qu'elle n'ait pas été conservée (sauf erreur de ma part) pour d'autres langages à la syntaxe proche.
[^] # Re: Indentation par l'espace
Posté par riba . Évalué à 3.
c'est quand même le truc super chiant quand tu cherche quel code fait ce #$%^^& de message d'erreur, vu que grep ne matche plus!
char* error = "FATAL ERROR NUMBER 123""456";
mouais....
[^] # Re: Indentation par l'espace
Posté par Jean B . Évalué à 1.
[^] # Re: Indentation par l'espace
Posté par Anonyme . Évalué à 2.
[^] # Re: Indentation par l'espace
Posté par Jean B . Évalué à 2.
[^] # Re: Indentation par l'espace
Posté par Anonyme . Évalué à 2.
[^] # Re: Indentation par l'espace
Posté par zerkman (site web personnel) . Évalué à 1.
J'utiliserai des tabulations lorsque leur largeur sera fixée à 2 (ou 3, à l'extrême rigueur) dans tous les éditeurs et que cette valeur ne sera pas modifiable par un utilisateur sadique.
Et au fait en typographie c'est unE espace, pas un espace.
[^] # Re: Indentation par l'espace
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
8 espaces, qui est la valeur d'origine de la tabulation, c'est effectivement trop. Je trouve personnellement que 4 c'est la taille idéale pour du code source. Au premier coup d'œil je repère l'indentation, et je n'ai pas à trop bouger la tête pour associer l'instruction d'introduction du bloc au bloc. Efficacité, fainéantise, etc.
D'ailleurs, c'est l'efficacité qui me fait haïr l'indentation par les espaces. Je ne vois pas la différence entre 3 espaces et 4 espaces.
En dehors du boulot, le seul endroit où j'utilises des indentations avec des espace c'est dans des fichiers de données (XML, JSON, etc).
Et au boulot, mon source est truffé d'indentation à 4×n+3 parce que entre 7 et 8 tabulations, je ne vois pas la différence. Et Vim (malgré >>) ne m'aide pas beaucoup sur ça. Et l'indentation, en Python, c'est assez important.
[^] # Re: Indentation par l'espace
Posté par calandoa . Évalué à 3.
Il ne suffirait pas de configurer ton éditeur pour qu'il insère/supprime autant d'espaces que nécessaire à chaque tab/backspace? laisse moi deviner... ton éditeur n'en est pas un, c'est juste un étron modelée en forme d'éditeur, mais tu n'as pas le choix? Dans ce cas, toutes mes condoléances.
J'avoue préférer de loin l'indentation uniquement à base d'espace, car ça limite les grands n'importe quoi, lorsque pleins de personnes touchent au code, chacune avec leur éditeur configuré différemment... mais il existe un cas tordu, relevé dans un commentaire ci dessus, celui des makefiles qui veulent à tout prix des vraies tabulations.
[^] # Re: Indentation par l'espace
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
# [×] Je fais du Python
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: [×] Je fais du Python
Posté par Hank Lords . Évalué à 2.
[^] # Re: [×] Je fais du Python
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: [×] Je fais du Python
Posté par Sébastien B. . Évalué à 2.
(de mémoire, c'est une convention en python)
[^] # Re: [×] Je fais du Python
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: [×] Je fais du Python
Posté par gregR ☯ (site web personnel) . Évalué à 2.
C'est dans la PEP 8
http://www.python.org/dev/peps/pep-0008/
Use 4 spaces per indentation level.
Tabs or Spaces?
Never mix tabs and spaces.
The most popular way of indenting Python is with spaces only. The
second-most popular way is with tabs only.
Les espaces sont recommandés pour les nouveaux projets
For new projects, spaces-only are strongly recommended over tabs.
http://gregr.fr
# Astyle ou cindent
Posté par spark . Évalué à 2.
[^] # Re: Astyle ou cindent
Posté par zebra3 . Évalué à 5.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Le FALSE, il n'y a que ça de vrais!
Posté par Olivier LAHAYE (site web personnel) . Évalué à 1.
Comme quoi, l'indentation de sert à rien ;-)
[^] # Re: Le FALSE, il n'y a que ça de vrai !
Posté par Jimmy . Évalué à 2.
Le Whitespace, dérivé du Brainf*ck, qui est lui-même un descendant du FALSE.
http://99-bottles-of-beer.net/language-whitespace-154.html
# [ctrl]+k, [ctrl]+d
Posté par Sayena Yefka . Évalué à 2.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.