Only the first line makes it clear that there's a high probability that h, s, and v will be modified by the function call.

c'est pas faux, mais je trouve que ca peut etre genant uniquement lorsque tu ne constifie pas tes parametres lorsqu'ils peuvent l'etre. et ca depend beaucoup des habitudes de code que t'as, et de comment tu design tes classes/methodes... c'est sur que des classes designees pour etre tres facilement lisibles et utilisables avec des pointeurs ne passeront pas forcement bien avec des references point de vue lisibilite, et l'inverse est encore plus vrai, mais entre les deux options, perso je trouve quand meme les references plus claires et pratiques...

(et puis bon heu, leur exemple, excuse moi.. "getHSV(h, s, v)", tu t'attends a quoi en lisant ca, a ce que ca utilise les 3 valeurs que tu lui passe pour faire un truc en interne, ou a ce que ca te les remplisse ? et si c'etait un "setHSV", les 3 seraient a priori const... (ou des valeurs passees directement) donc bon...)

sinon le "high probability", bah, a partir du moment ou les const sont utilises la ou il faut, tu as l'info directement dans la declaration de la fonction, et si tu utilises une IDE un minimum evoluee (style visual studio, par exemple ), tu as l'info directement lorsque tu ecris l'appel a la methode...

et le probleme de NULL... entre "__attribute__((nonnull)) *", ou une syntaxe du meme genre et juste "&", on a vu mieux point de vue lisibilite quand meme.. non? enfin, si c'est bien comme ca que ca s'utilise / a ca que ca sert (surtout que si tu veux bien le faire, des nonnull, tu peux en avoir quasiment partout, donc si c'est pour remplacer toutes les references par des pointeurs taggues avec des __attribute__((nonnull)), je sais pas toi, mais ca me parait quand meme mieux les references )