Re: politique de casse / -gnatyD

Bonjour :-)

Jean-Pierre Rosen m'a répondu en privé, et m'incite à vous donner un complément :



Le 21 janv. 2021 à 03:23, Thomas De Contes a écrit :

> J'ai eu l'occasion de tester GNAT Community 2020 (20200429-93) (je ne l'ai plus sous la main) et l'option -gnatyD.
> 
> Je suppose que comme c'est la 1ère version dans laquelle cette option existe, c'est normal qu'il y ait encore des bugs ?


Le précédent mainteneur de RAPID m'a demandé explicitement de suivre le GNAT Coding Style.
Il y a des choses qui ne sont pas à mon gout, mais tant pis, j'ai décidé de respecter cette demande autant que possible, au moins pour ce projet.

Donc pour m'aider, j'ai activé plein d'options (-gnatyy pas -gnatyg), et j'ai désactivé seulement celles que je trouvais vraiment trop gênantes.

Le problème avec -gnatyD, c'est qu'elle est nouvelle et visiblement en rodage (mais je n'ai pas assez d'expérience pour me permettre une affirmation).
Donc, ce que j'aimerais, c'est savoir ce qui est attendu (ce qui serais toléré si je contribuais à GNAT),
pour pouvoir m'y conformer des maintenant, au fur et à mesure que je modifie le code, et éviter de devoir repasser partout si je m'aperçois plus tard que quelque chose n'était pas bon.
(Par exemple j'ai plein de "Mcc" signalés par -gnatyr, partout, vu que c'est une racine, et j'aimerais savoir tout de suite si c'est permis d'écrire "mcc" ou s'il faut "MCC", pour éviter de le faire 2 fois. :-) )

Je n'ai vu que 2 choses auxquelles j'aurais du mal à me faire si on me l'imposait :
- Interdiction d'avoir plusieurs lignes vides consécutive. Je les juge nécessaires pour que ça soit suffisamment aéré. (Je vais tacher de me limiter à 4, pour éviter un trop grand décalage avec ceux qui auraient envie de me relire. Peut-être que les développeurs de GNAT trouvent que l'abondance de commentaires requise est suffisante pour l'aération ?)
- Dans les corps, classement des sous-programmes par ordre alphabétique plutôt que par fonctionnalité. J'y vois beaucoup plus d'inconvénients que d'avantages. (Il faudrait qu'on m'explique mon erreur d'appréciation, mais ça n'est pas l'objet de ce message.)



1
Les différences entre le GNAT Coding Style (ce que j'en ai compris) et l'option -gnatyD :


> Concernant la politique de casse j'ai lu le GNAT Coding Style / 2.2 Identifiers :
> https://gcc.gnu.org/onlinedocs/gnat-style/Lexical-Elements.html
> ainsi que la doc de -gnatyD.
> 
> A priori ça n'autorise pas les minuscules intégrales, pourtant je n'ai eu aucun avertissement pour des noms de paquetages entièrement en minuscules.
> D'ailleurs, je viens de trouver un nom de procédure qui n'est pas signalé non plus :
> 
>  126.    procedure focus (obj : in Widget) is
>                           |
> (style) bad capitalization, mixed case required
> 
> Est ce que c'est voulu, ou est ce que c'est un oubli ?
> Si c'est voulu, est ce que quelqu'un pourrait me préciser les règles svp ?
> 
> Puisque pour les types par exemple ça fonctionne :
> 
>   30.    subtype peer is Glib.Object.GObject;
>                  |
> (style) bad capitalization, mixed case required


Et à l'inverse, il refuse le "tout en majuscules" :


>   36.    function To_Color (RGB : in RGB_Color) return Color is
>                             |
> (style) bad capitalization, mixed case required
> 
>   44.    function To_Color (RGB : in String) return Color is
>                             |
> (style) bad capitalization, mixed case required
> 
> Il me semble que RGB est conforme au GNAT Coding Style, vu ce que ça dit sur les acronymes courts, donc ça serait chouette qu'il ne soit pas signalé :-)


Ce que j'ai compris du GNAT Coding Style :

Appelons "éléments" les parties d'un identificateur séparées par des '_'.
Pour chaque élément :
- La 1ère lettre doit être une majuscule (ou un chiffre, si ce n'est pas le 1er élément).
- Les suivantes doivent être soit toutes en majuscule, soit toutes en minuscule (et peuvent aussi être des chiffres).

Et c'est la même règle quelque soit le type d'objet désigné par l'identificateur.


Ce que j'ai constaté de l'option -gnatyD :

Je n'ai rien trouvé sur des paquetages ou des sous-programmes, alors qu'il y avait à dire.
Je ne sais pas s'ils sont totalement ignorés, ou si les règles sont différentes.

J'ai trouvé ça dans le code de RAPID :
--------
package gui.Window is
  type GUI_Window is tagged limited record
--------
Ca laisse penser que les règles pourraient être différentes dans le GNAT Coding Style, mais si c'est ça ce qui est curieux c'est que je n'ai rien trouvé dans la doc :
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gnat-style/

Le camelCase (dromedary case) est autorisé, et même si j'aime beaucoup, ça me surprend : je l'aurais imaginé limité au plus au CamelCase (l'original).

Le "tout en majuscules" est interdit.

On dirait que ça suit la règle du "mixed case" strictement, c'est à dire que du moment qu'il y en a au moins un de chaque, dans n'importe quel ordre, c'est bon.


Je vois 3 possibilités :
- J'ai bien compris le GNAT Coding Style, et l'option -gnatyD va être améliorée.
- J'ai mal compris le GNAT Coding Style, et dans ce cas j'aimerais bien que quelqu'un me l'explique. :-)
- J'ai bien compris le GNAT Coding Style, mais l'option -gnatyD n'a pas été prévue pour s'y conformer. Dans ce cas là aussi, quelque chose m'a échappé. ;-)



2
Ce que je trouverais pratique en décalage du GNAT Coding Style, pour avoir vos avis.


Les acronymes :

http://svn.savannah.gnu.org/viewvc/rapid?view=revision&revision=87

Il a transformé mcc.Gui en mcc.tki, donc il a fait exprès, et je suppose que c'est parce que ce sont des acronymes.

Je trouve que "la 1ère lettre en majuscule et pas les autres" ne convient pas aux acronymes, mais "tout en majuscules" et "tout en minuscules" me paraissent convenable.
Qu'en pensez vous ?

Je n'ai pas entendu dire que le GNAT Coding Style autorisait ça, mais si c'est le cas tant mieux. :-)


Si c'est une mauvaise idée, et qu'il vaut mieux que les acronymes soient uniquement en majuscules, je vous soumet le cas des identificateurs composés uniquement d'une lettre :


>  129.       for i in Result'Range loop
>                 |
> (style) bad capitalization, mixed case required
> 
> Le GNAT Coding Style voudrais qu'on utilise plutôt J, mais
> - il me semble que tout le monde fait ça,
> - en plus, i minuscule ne risque pas tellement d'être confondu avec l ni 1, contrairement à I majuscule.
> 
>   70.       x, y, Width, Height : Integer;
>             |
> (style) bad capitalization, mixed case required
> 
> Ici, ça ne me parait pas choquant, même si les mêmes variables sont en majuscule à d'autres endroits du code.
> (Et puis, faire du "mixed case" dans les noms composés uniquement d'une lettre, c'est pas commode. ;-) )
> 
> En conséquence, ce qui me parait approprié, c'est de décider que pour les noms composés uniquement d'une lettre, la casse est libre.
> Qu'en pensez vous ?
> 
> Si vous n'êtes pas d'accord, j'arriverai à m'y faire, mais il faudra signaler aussi le y.


Ça ne me parait pas nuire à la lisibilité.
Mais peut-être avez vous l'avis contraire ?


CamelCase :


> J'aime beaucoup le camelCase parce que j'y ai été habitué avec HyperCard, avant d'apprendre Ada (du coup le tiret bas je trouve ça moche, même si c'est /totalement subjectif/).
> Mais si c'est mal vu par la majorité d'entre nous, j'aime autant que le compilateur me le signale,
> or ça n'est pas le cas, puisqu'il n'a rien dit du tout sur les noms que j'ai fait comme ça ...
> 
> Peut-être qu'il ne veut pas dire "mixed case required" du fait que, strictement, le camelCase est du "mixed case" ?
> Il faudrait trouver une façon de designer la manière de bien écrire les noms selon le GNAT Coding Style, pour que ça ne soit pas flou.


... Ou peut-être que le GNAT Coding Style accepte le CamelCase ?

J'ai trouvé quelques identificateurs en CamelCase je ne sais plus où, et là j'en ai trouvé un mieux, puisqu'il combine CamelCase et snake_case ! :-)

http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/rapid/rapid/file_menu.ads?view=markup

SaveAs_Choice

Je trouve que c'est astucieux, pour la lisibilité. :-)
Ca fait en quelques sortes des groupes de mots à l'intérieur de l'identificateur. :-)

C'est bête qu'il ne s'en soit pas servi là :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/tki/mcc_tki/mcc-common_dialogs.ads?view=markup

Ca contient Yesno_Dialog et Yesno_Cancel_Dialog.
À la place, YesNo_Dialog et  YesNoCancel_Dialog, ça aurais été chouette, non ?

Qu'en pensez vous ?




> Question connexe sur GNAT Community 2020 :
> 
> src/rapid/rapid/rapid_main.adb: In function 'Rapid_Main':
> src/rapid/rapid/rapid_main.adb:145: warning: 'T159b' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> Est ce que ce message est significatif et je devrais en tenir compte, ou bien est ce que c'est une erreur et ça aura disparu dans la prochaine version ?


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/