Discussion :

[Charly910]

Bonjour,

Est ce que le compilateur aime les parenthèses ? est ce que cela lui facilite le travail et lui fait gagner du temps ?

par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  EcrireChaine := (PageControl1.TabIndex = 0) ;
  If (i > 54) Then j := 30 ;

est il plus rapide que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  EcriChaine := PageControl1.TabIndex = 0 ;;
  If i > 54 Then j := 30 ;

je demande cela car j'ai l'habitude d'abuser des parenthèses inutiles ...

A+
Charly

[Paul TOTH]

euh...tu parles en temps de compilation ou en temps d'exécution ?

car pour la compilation je dirais que ça doit être une micro seconde plus lent vu qu'il va falloir gérer la parenthèse fermante...en temps d'exécution c'est totalement indifférent (sauf à jouer sur la précédence des opérateurs évidemment)

[SergioMaster]

Dans la même veine si tu cries en mettant tout en majuscule, le compilateur comprendra mieux ?

[blonde]

euh...tu parles en temps de compilation ou en temps d'exécution ?

car pour la compilation je dirais que ça doit être une micro seconde plus lent vu qu'il va falloir gérer la parenthèse fermante...en temps d'exécution c'est totalement indifférent (sauf à jouer sur la précédence des opérateurs évidemment)

Je n'en suis pas si sûre que toi. Le compilateur va devoir créer un bloc avec la condition.
Quand il va tomber sur le '=', il va devoir évaluer les expression à droite et à gauche du symbole '=' pour créer 2 blocs. Une fois qu'il va trouver les parenthèses, les blocs seront créés. Sinon, il est obligé d'aller jusqu'au prochains indicateurs de séparation d'instruction.

Mais on est bien d'accord que la différence de temps de compilation est infiniment minime.

Personnellement, pour la lecture du code, je préfère dans ce cas, le parenthésage. @Charly : je ne trouve pas ça inutile du tout, au contraire.

[Charly910]

Merci pour vous avis de super spécialiste,

D'accord avec Blonde, c'est plus lisible et plus compréhensible dans le code.
C'est pourquoi j'utilise beaucoup les parenthèses, mais je voulais savoir si ce n'était pas trop pénalisant.

C'est vrai que le principal c'est à l’exécution et là peu importe.

A+
Charly

PS : reste à départager Paul et Blonde !

[blonde]

Si tu veux t'amuser un peu, il existe Lex et Yacc. Je te laisse découvrir

[pprem]

Si tu veux t'amuser un peu, il existe Lex et Yacc. Je te laisse découvrir

[blonde]

Ben quoi ? C'est formateur dans la compréhension des analyseurs syntaxiques et des compilateurs.
Je te trouve un peu moqueur mon cher Patrick.

[Paul TOTH]

Je n'en suis pas si sûre que toi. Le compilateur va devoir créer un bloc avec la condition.
Quand il va tomber sur le '=', il va devoir évaluer les expression à droite et à gauche du symbole '=' pour créer 2 blocs. Une fois qu'il va trouver les parenthèses, les blocs seront créés. Sinon, il est obligé d'aller jusqu'au prochains indicateurs de séparation d'instruction.

Mais on est bien d'accord que la différence de temps de compilation est infiniment minime.

Personnellement, pour la lecture du code, je préfère dans ce cas, le parenthésage. @Charly : je ne trouve pas ça inutile du tout, au contraire.

alors je ne sais pas comment Delphi va parser ce code, mais pour avoir écrit plusieurs compilateur, je sais comment moi je fais

dans FlashPascal par exemple

TCompiler.Expression est le plus haut niveau qui gère les expressions booléennes, Expression3 gère les termes, Expression2 les facteurs et Expression1 au plus bas niveau gère tous les cas possibles...et notamment le cas Parenthèse qui repart au niveau le plus haut

donc dans FlashPascal, mettre une expression entre parenthèse impose au compilateur de descendre au niveau le plus bas pour reboucler sur une expression...ce qu'il aurait fait dès le départ sans les parenthèses.

et mettre la parenthèse au plus haut niveau n'est pas vraiment une solution car dans l'expression 1 + (2 * (3 + (4))), on voit bien que la parenthèse intervient à tous les niveaux...donc nécessairement au plus bas niveau...sauf à faire du C pour lequel l'expression de condition est forcément entre parenthèses...mais ça devient un séparateur syntaxique comme begin/end et ne fait plus parti de l'expression en réalité.

[Charly910]

Bien, merci à tous,

je retiens que même si c'est un peu pénalisant je vais continuer à utiliser les parenthèses (sans excès) afin d'avoir une meilleure lisibilité du code.

A+
Charly

[Paul TOTH]

Bien, merci à tous,

je retiens que même si c'est un peu pénalisant je vais continuer à utiliser les parenthèses (sans excès) afin d'avoir une meilleure lisibilité du code.

A+
Charly

ceci dit, et puisque l'on parle philosophie, je pense que la lisibilité du code est très liée aux habitudes...et de fait suivre les principes utilisés par Embarcadero permet de rendre son code lisible par la plus part des développeurs Delphi

les parenthèses ne sont pas gênante et sont syntaxiquement correctes, mais leur usage n'étant pas répandu tu vas prendre une mauvaise habitude de lecture qui peut te perturber pour lire le code des autres, et les autres seront peut-être déroutés en lisant ton code.

c'est vrai de pas mal de chose, évidemment un code non indenté posera problème, mais une indentation inhabituelle aussi; cf les longues discussions sur le 'then' en fin de ligne du 'if' ou à la ligne, le 'end else begin' en une, deux ou trois lignes...j'ai moi même des habitudes qui ne sont pas Embarcadero compatibles.

au cours de ma carrière j'ai changé plusieurs fois de style d'écriture, mes premiers programmes sous Turbo Pascal, rédigés dans un éditeur texte en 80x43 lignes étaient particulièrement compacts afin d'avoir le maximum de code visible à l'écran...je les trouve très indigestes aujourd'hui. Il fut un temps ou je mettais une majuscule aux mots clés...ce que je continu à faire pour Integer mais par pour string

[foetus]

2 autres aspects :
1) Les compilateurs. En Delphi, il n'y a pas trop de compilateurs ... à moins de switcher sur Lazarus. Mais en C/ C++, tu as Delphi Builder, gcc/ g++, Visual, ... Et donc, tout parenthèser permet de ne pas avoir de surprises sur l'interprétation des expressions/ conditions/ ou autres. En théorie, il y a 0.01% de risques, mais ce sont souvent des bogues assez "discrets"/ subtils (<- en gros, ce sont généralement des bogues que l'on découvre en production)

2) Reprendre du code. @Paul TOTH a peut-être raison sur la lisibilité du code. Mais tout parenthèser clos les débats sur l'interprétation et permet de modifier rapidement les conditions/ ou autres, parce qu'on n'a pas à rajouter de parenthèses (sauf si on étend), en repérant les parenthèses on peut modifier facilement 1 partie, ...
En C/ C++, par exemple, on n'a pas besoin de mettre les accolades pour le bloc if, mais ce bloc ne fait qu'1 ligne. Et lorsqu'on est en phase de test/ débogage, à chaque fois qu'il faut faire 1 trace, il faut reprendre le code s'il manque les accolades. C'est assez pénible.

[free07]

C'est vrai que la lisibilité du code est très lié aux habitudes, les sociétés ou j'ai pris le + de plaisir à travailler sur le code est celles qui avaient une charte de bonnes pratiques ou tous les dev étaient contraints de les appliquer.

Si certaines règles m'étaient un peu pénible à suivre au début, une fois l'habitude prise, cela ne posait plus de problème et le plaisir de travailler sur du code écrit par d'autres qui respectaient ces règles l'emportait.

Rien de plus pénible de travailler sur un projet ou chaque dev suit ses habitudes, rien que pour l'indentation par exemple, cela peut devenir pénible à lire.