sauf que ce path est utilisé ici, et surement ailleurs.
T'as été vérifier?
qu'aujourd'hui c'est /run/programme/fichier
mais qu'il y a pas si longtemps c'etait /var/run
et que parfois c'est /run/user/programme/fichier
Vu que systemd impose une restriction forte sur ou ses binaires se trouvent, c'est pas délirant de considerer ca comme une réelle constante.
Et le jour ou ca change, ils vont faire quoi?
grepper sur /run/machin. Le fait que ca puisse changer un jour ne justifie pas un #define public. Ce qui justifie un #define public, c'est que ca soit une constante publique, utilisée par different composant.
Si c'est une constante privée a cette implementation (et ca a l'air d'etre le cas, vu comment elle est precise), ca a rien a faire dans un .h, sinon ca devient une api publique, et c'est une très mauvaise chose de l'exposer publiquement si c'est du prive.
Si c'est une constante privée utilisée une seule fois dans le fichier, bah #define ou pas, c'est surtout une question de gout. Perso, dans ce cas, j'inline, point barre. J'ai pas envie de me taper une dégueulante de #defines en haut du fichier, ca masque les vraies constantes intéressantes, et ca fait chier quand je veux savoir ce qu'il y a précisément dans cette constante.
Les deux styles se tiennent, je qualifierais pas l'un ou l'autre de crade, en tout pas a partir d'un snippet aussi court, sans voir le contexte.
Et tant que t'en es a donner des leçons, tu l'appellerais comment toi, cette constante?
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par groumly . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 0.
T'as été vérifier?
Vu que systemd impose une restriction forte sur ou ses binaires se trouvent, c'est pas délirant de considerer ca comme une réelle constante.
Et le jour ou ca change, ils vont faire quoi?
grepper sur /run/machin. Le fait que ca puisse changer un jour ne justifie pas un #define public. Ce qui justifie un #define public, c'est que ca soit une constante publique, utilisée par different composant.
Si c'est une constante privée a cette implementation (et ca a l'air d'etre le cas, vu comment elle est precise), ca a rien a faire dans un .h, sinon ca devient une api publique, et c'est une très mauvaise chose de l'exposer publiquement si c'est du prive.
Si c'est une constante privée utilisée une seule fois dans le fichier, bah #define ou pas, c'est surtout une question de gout. Perso, dans ce cas, j'inline, point barre. J'ai pas envie de me taper une dégueulante de #defines en haut du fichier, ca masque les vraies constantes intéressantes, et ca fait chier quand je veux savoir ce qu'il y a précisément dans cette constante.
Les deux styles se tiennent, je qualifierais pas l'un ou l'autre de crade, en tout pas a partir d'un snippet aussi court, sans voir le contexte.
Et tant que t'en es a donner des leçons, tu l'appellerais comment toi, cette constante?