J'ai fini par cloner le dépot systemd pour avoir d'autres exemples de sources à lire.
Du coup pour la variable "r" la réponse est simple : ils utilisent "int r" dans toutes les fonctions. Alors certes c'est moins expressif que int return_value; mais c'est cohérent sur l'ensemble du projet.
Sur le couplet "y a pas de commentaires cay pourri". On peut aussi trouver du code largement commenté dans systemd, par ex :
static int mount_points_list_umount(MountPoint **head, bool *changed, bool log_error) {
MountPoint *m, *n;
int n_failed = 0;
assert(head);
LIST_FOREACH_SAFE(mount_point, m, n, *head) {
/* If we are in a container, don't attempt to
read-only mount anything as that brings no real
benefits, but might confuse the host, as we remount
the superblock here, not the bind mound. */
if (detect_container(NULL) <= 0) {
/* We always try to remount directories
* read-only first, before we go on and umount
* them.
*
* Mount points can be stacked. If a mount
* point is stacked below / or /usr, we
* cannot umount or remount it directly,
* since there is no way to refer to the
* underlying mount. There's nothing we can do
* about it for the general case, but we can
* do something about it if it is aliased
* somehwere else via a bind mount. If we
* explicitly remount the super block of that
* alias read-only we hence should be
* relatively safe regarding keeping the fs we
* can otherwise not see dirty. */
mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
}
/* Skip / and /usr since we cannot unmount that
* anyway, since we are running from it. They have
* already been remounted ro. */
if (path_equal(m->path, "/")
#ifndef HAVE_SPLIT_USR
|| path_equal(m->path, "/usr")
#endif
)
continue;
/* Trying to umount. We don't force here since we rely
* on busy NFS and FUSE file systems to return EBUSY
* until we closed everything on top of them. */
log_info("Unmounting %s.", m->path);
if (umount2(m->path, 0) == 0) {
if (changed)
*changed = true;
mount_point_free(head, m);
} else if (log_error) {
log_warning("Could not unmount %s: %m", m->path);
n_failed++;
}
}
return n_failed;
}
(arf, bien sûr la fonction que je cite n'utilise par 'int r' :) )
En tout cas, ils ne sont pas opposés aux commentaires par principe (ou pour justifier de facturer du support).
Enfin le style général est également cohérent (accolades, alignements, assert, etc).
Dernière chose, que je trouve bien plus importante que les commentaires dans le code d'ailleurs, les messages de commits ont l'air complets et utiles.
Si vous considérez cette codebase comme crade, je veux bien un exemple d'un projet (sérieux, pas un hello world de 15 lignes) propre.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par pepp . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 4.
J'ai fini par cloner le dépot systemd pour avoir d'autres exemples de sources à lire.
Du coup pour la variable "r" la réponse est simple : ils utilisent "int r" dans toutes les fonctions. Alors certes c'est moins expressif que int return_value; mais c'est cohérent sur l'ensemble du projet.
Sur le couplet "y a pas de commentaires cay pourri". On peut aussi trouver du code largement commenté dans systemd, par ex :
(arf, bien sûr la fonction que je cite n'utilise par 'int r' :) )
En tout cas, ils ne sont pas opposés aux commentaires par principe (ou pour justifier de facturer du support).
Enfin le style général est également cohérent (accolades, alignements, assert, etc).
Dernière chose, que je trouve bien plus importante que les commentaires dans le code d'ailleurs, les messages de commits ont l'air complets et utiles.
Si vous considérez cette codebase comme crade, je veux bien un exemple d'un projet (sérieux, pas un hello world de 15 lignes) propre.