politique de casse / -gnatyD

Bonjour :-)


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 ?


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



j'en profite pour ajouter :


   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é :-)
je ne sais pas ce qu'il faudrait comme critères, peut-être une longueur maximale ?


  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


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



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/