On peut pinailler sur ce genre de trucs sur le code du noyau de la meme facon
Du peu que j'ai vu du code du noyau, c'est assez faux. Le code du noyau n'est pas forcément lisible, parce qu'il est écrit par des gens qui ne sont pas des programmeurs moyens, mais les fonctions sont hyper courtes, on a rarement plus de deux niveaux de if, il y a des millions de constantes pour tout, beaucoup de fonctions commencent par "int retval;" et dintinguent très clairement les retours d'erreurs et les retours de valeurs attendues, etc.
Je pense qu'on a relevé plein de petits trucs bizarres, pas très propres, pas très orthodoxes. Après, je ne suis pas développeur, et j'ai dit plus haut que le code n'était pas "pourri" : il fait juste un peu "premier jet". Si j'ai un étudiant qui me met les chemins en dur, je lui dis de refaire cette fonction pour qu'il aille lire les chemins dans une variable. S'il a 5 niveaux de if/else, je lui dis de fractionner son code en fonctions plus courtes. Je lui dirais aussi de ne pas appeler ses variables r, p, ou d.
À partir de ça, il serait con de conclure que systemd ne fonctionne pas, qu'il est buggué, ou qu'il n'est pas efficace. Par contre, c'est légitime de se poser des questions sur sa maturité, et sur le nombre de gens qui ont relu le code. Je ne comprends toujours pas le "return -r;" par exemple, c'est probablement un bug ou un truc pas net, simplement dû à la complexité de la fonction. Si elle avait un "int retval = 0;" au début, puis "retval = -r;", et "if (! (retval < 0))" avant le code qui fait vraiment quelque chose, il serait évident à la lecture que la fonction fait un truc idiot. Alors que là, on ne sait pas trop si retourner un code d'erreur positif n'est pas voulu, c'est bizarre quand même, non?
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par arnaudus . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 10.
Du peu que j'ai vu du code du noyau, c'est assez faux. Le code du noyau n'est pas forcément lisible, parce qu'il est écrit par des gens qui ne sont pas des programmeurs moyens, mais les fonctions sont hyper courtes, on a rarement plus de deux niveaux de if, il y a des millions de constantes pour tout, beaucoup de fonctions commencent par "int retval;" et dintinguent très clairement les retours d'erreurs et les retours de valeurs attendues, etc.
Je pense qu'on a relevé plein de petits trucs bizarres, pas très propres, pas très orthodoxes. Après, je ne suis pas développeur, et j'ai dit plus haut que le code n'était pas "pourri" : il fait juste un peu "premier jet". Si j'ai un étudiant qui me met les chemins en dur, je lui dis de refaire cette fonction pour qu'il aille lire les chemins dans une variable. S'il a 5 niveaux de if/else, je lui dis de fractionner son code en fonctions plus courtes. Je lui dirais aussi de ne pas appeler ses variables r, p, ou d.
À partir de ça, il serait con de conclure que systemd ne fonctionne pas, qu'il est buggué, ou qu'il n'est pas efficace. Par contre, c'est légitime de se poser des questions sur sa maturité, et sur le nombre de gens qui ont relu le code. Je ne comprends toujours pas le "return -r;" par exemple, c'est probablement un bug ou un truc pas net, simplement dû à la complexité de la fonction. Si elle avait un "int retval = 0;" au début, puis "retval = -r;", et "if (! (retval < 0))" avant le code qui fait vraiment quelque chose, il serait évident à la lecture que la fonction fait un truc idiot. Alors que là, on ne sait pas trop si retourner un code d'erreur positif n'est pas voulu, c'est bizarre quand même, non?