Sauf qu’à part dans du code Python ou dans un Makefile, dans la quasi-totalité des cas l’indentation n’a pas de sémantique.
Tu ignores (volontairement ?) de répondre précisément à ce qui suit immédiatement mon affirmation « la sémantique c’est important ».
Je le remets :
{
→ int⋅i;
}
Le premier peut être supprimé par le préprocesseur/minifieur, pas le second, et ce sans aucune forme d’analyse syntaxique.
C’est un peu comme les commentaires de documentation, ça n’a aucun sens pour le code exécuté, mais ça un un sens pour la documentation.
De même, la tabulation dans l’exemple ci-dessus n’a aucun sens pour le code exécuté, mais elle a du sens pour l’éditeur, et il pourrait avoir du sens pour un préprocesseur.
Le rôle du compilateur c’est de transformer ton code. Le rôle de l’éditeur est d’afficher le code et permettre sa saisie. Dans mon exemple la sémantique de la tabulation ne concerne que l’éditeur, et c’est très bien comme ça. D’ailleurs l’indentation elle-même n’a pas de sens pour le compilateur ou l’interpréteur dans la majorité des cas comme tu l’as précisé, si on le fait quand même c’est bien que ça sert à autre chose qu’au compilateur ou interpréteur. C’est pour une raison similaire qu’on demande d’écrire des noms de fonctions et des noms de variables « qui ont du sens », pourtant le compilateur ou l’interpréteur n’en a rien à carrer.
C’est en pensant que l’indentation veut dire quelque chose qu’on en arrive à ce que quelqu’un écrive du code comme ça :
Je n’ai jamais parlé dans ce fil de discussion de la sémantique de la tabulation sur le plan fonctionnel (ce qui sera exécuté par le code). Ce que tu fais là est un homme de paille et tu dois savoir que si c’est intentionnel c’est malhonnête.
Je parle de sémantique de la tabulation pour l’éditeur qui fait le rendu de ton code.
Même python avec ses indentations qui ont un sens fonctionnel n’en a rien à cirer de cette indentation-là, mais cette indentation a du sens pour le codeur et elle peut avoir du sens pour l’éditeur. De même la dernière virgule n’a aucun sens fonctionnel mais elle a un sens pour l’outil de diff qui peut voir chacune des lignes clé-valeurs comme un ensemble qui peut se traiter indépendamment des autres lignes et grandement faciliter les fusions.
On n’est pas des machines, il y a plusieurs niveaux de sémantique et pas seulement celui du compilateur/interpréteur. Le meilleur exemple étant le commentaire de code, complètement inutile sur le plan fonctionnel mais tellement utile que l’éditeur a une règle de style spécifique pour cela.
C’est très précieux d’avoir un caractère dédié à l’indentation, ça évite de devoir faire de la divination pour appliquer le style, parce que contrairement au commentaire n’y a pas de balise autour de l’indentation ! Sans le caractère tabulation les développeurs de moteur de rendu de code doivent traiter les espaces comme s’ils parsaient du whitespace ! C’est du masochisme !
C’est aussi parce qu’on refuse de considérer la sémantique sur ce plan-là qu’on n’a toujours pas de moteur de rendu de code potable après tant d’année et malgré toutes les supers choses dont on rêverait comme celle présentée dans ce journal ! On a des moteurs CSS de la mort qui tue sur le web mais pour faire le rendu de code on continue de demander aux codeurs de faire la mise en page à la main avec des espaces !
Perso j’aime bien coder avec une fonte mono, mais je me rends bien compte que c’est surtout une contrainte qu’on se donne et qu’on donne à tout le monde pour se permettre d’être compatible avec les cro-magnons qui sont resté à la mise en forme à base d’espace !
C’est incroyable qu’on soit resté à la mise en forme à base d’espace après tant de décennies, et ce qui est incroyable c’est que ce soit le domaine le plus à la pointe qui en soit resté là. Mais même les fontes mono que j’affectionne bien montrent leur limites, parce que dans le code on met aussi du vrai texte, ne serait-ce qu’entre deux guillemets d’un printf et que l’espace fine insécable ou l’émoji ou l’idéogramme et bien ils bouleversent un peu tout ça.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 7.
Tu ignores (volontairement ?) de répondre précisément à ce qui suit immédiatement mon affirmation « la sémantique c’est important ».
Je le remets :
C’est un peu comme les commentaires de documentation, ça n’a aucun sens pour le code exécuté, mais ça un un sens pour la documentation.
De même, la tabulation dans l’exemple ci-dessus n’a aucun sens pour le code exécuté, mais elle a du sens pour l’éditeur, et il pourrait avoir du sens pour un préprocesseur.
Le rôle du compilateur c’est de transformer ton code. Le rôle de l’éditeur est d’afficher le code et permettre sa saisie. Dans mon exemple la sémantique de la tabulation ne concerne que l’éditeur, et c’est très bien comme ça. D’ailleurs l’indentation elle-même n’a pas de sens pour le compilateur ou l’interpréteur dans la majorité des cas comme tu l’as précisé, si on le fait quand même c’est bien que ça sert à autre chose qu’au compilateur ou interpréteur. C’est pour une raison similaire qu’on demande d’écrire des noms de fonctions et des noms de variables « qui ont du sens », pourtant le compilateur ou l’interpréteur n’en a rien à carrer.
Je n’ai jamais parlé dans ce fil de discussion de la sémantique de la tabulation sur le plan fonctionnel (ce qui sera exécuté par le code). Ce que tu fais là est un homme de paille et tu dois savoir que si c’est intentionnel c’est malhonnête.
Je parle de sémantique de la tabulation pour l’éditeur qui fait le rendu de ton code.
Il est par exemple pratique de faire ceci :
Même python avec ses indentations qui ont un sens fonctionnel n’en a rien à cirer de cette indentation-là, mais cette indentation a du sens pour le codeur et elle peut avoir du sens pour l’éditeur. De même la dernière virgule n’a aucun sens fonctionnel mais elle a un sens pour l’outil de diff qui peut voir chacune des lignes clé-valeurs comme un ensemble qui peut se traiter indépendamment des autres lignes et grandement faciliter les fusions.
On n’est pas des machines, il y a plusieurs niveaux de sémantique et pas seulement celui du compilateur/interpréteur. Le meilleur exemple étant le commentaire de code, complètement inutile sur le plan fonctionnel mais tellement utile que l’éditeur a une règle de style spécifique pour cela.
C’est très précieux d’avoir un caractère dédié à l’indentation, ça évite de devoir faire de la divination pour appliquer le style, parce que contrairement au commentaire n’y a pas de balise autour de l’indentation ! Sans le caractère tabulation les développeurs de moteur de rendu de code doivent traiter les espaces comme s’ils parsaient du whitespace ! C’est du masochisme !
C’est aussi parce qu’on refuse de considérer la sémantique sur ce plan-là qu’on n’a toujours pas de moteur de rendu de code potable après tant d’année et malgré toutes les supers choses dont on rêverait comme celle présentée dans ce journal ! On a des moteurs CSS de la mort qui tue sur le web mais pour faire le rendu de code on continue de demander aux codeurs de faire la mise en page à la main avec des espaces !
Perso j’aime bien coder avec une fonte mono, mais je me rends bien compte que c’est surtout une contrainte qu’on se donne et qu’on donne à tout le monde pour se permettre d’être compatible avec les cro-magnons qui sont resté à la mise en forme à base d’espace !
C’est incroyable qu’on soit resté à la mise en forme à base d’espace après tant de décennies, et ce qui est incroyable c’est que ce soit le domaine le plus à la pointe qui en soit resté là. Mais même les fontes mono que j’affectionne bien montrent leur limites, parce que dans le code on met aussi du vrai texte, ne serait-ce qu’entre deux guillemets d’un
printfet que l’espace fine insécable ou l’émoji ou l’idéogramme et bien ils bouleversent un peu tout ça.ce commentaire est sous licence cc by 4 et précédentes