Discussion :

[imperio]

Tu es d'une mauvaise foi assez terrifiante. Mais bon, je reste sur ma position : je suis content de ne pas travailler avec quelqu'un comme toi. "le code c'est la doc", je pensais que c'était une légende dans le temps puis j'ai découvert la réalité. Cela dit tu viens d'un milieu de chercheurs, et pour le peu que je connais du domaine au travers d'anciens collègues, leur code est généralement assez dégueux et imbittable (c'est d'ailleurs pour ça qu'on nous embauchait : pour nettoyer derrière).

En fait, j'ai du mal à imaginer comment on peut comprendre le code d'une fonction perdue au milieu de milliers d'autres (dans des libs ou non) et le comprendre sans avoir besoin de docs quand c'est fonction "optimisée" (comprendre, elle utilise des trucs avancés comme du simd ou même de l'assembleur pour faire ce qu'elle a à faire avec le moins d'instructions possibles). Pour moi ça tient de la magie noire à ce niveau-là. Mais peut-être es-tu juste un dieu parmi les développeurs, qui sait ?

[Ryu2000]

En fait, j'ai du mal à imaginer comment on peut comprendre le code d'une fonction perdue au milieu de milliers d'autres

Si le méthode est toute petite et que son nom est clair, on ne devrait pas avoir trop de mal à comprendre ce qu'elle fait.
C'est encore plus simple si le nom des variables sont pertinents.

[Neckara]

Oui tout à fait . Car le principe d'un ETL c'est de modéliser le flux. Donc des commentaires , sinon c'est un parcours ... de données mais à l'aveugle.

En quelques sorte. Un genre "d'info bulle".

D'accord, là oui.

C'est plus vraiment du pur "code", mais un mix entre code et interfaces graphiques j'ai l'impression.


Mais juste pour enculer la mouche qui remue son derrière un peu trop près de moi, je rangerais ça dans la catégorie "documentation", plus que dans la catégorie "commentaires de codes". En considérant chaque scripts comme sa propre "application" indépendante.

Un peu comme tu peux construire des scripts shells et chaque commandes que tu as dedans a sa propre entrée dans le MAN.

Mais bon, je reste sur ma position : je suis content de ne pas travailler avec quelqu'un comme toi.

Sentiment entièrement partagé...

Parce que des code de stagiaires avec des commentaires qu'il faut tout reprendre à 0, tellement le code est inutilisable, j'ai déjà assez donné.

"le code c'est la doc", je pensais que c'était une légende dans le temps puis j'ai découvert la réalité.

Le code propre c'est la doc n'a pas besoin de commentaires.

Va lire n'importe quelle bibliothèque, regarde le code, tu n'y trouveras pas tant de commentaires que cela. Potentiellement des bouts de documentations pour doxygen/JAVA doc/autre, mais pas de commentaires.

Et encore... la documentation, sera surtout pour l'API publique figée, et ne s'amusera pas à paraphraser la signature... Non parce que les :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class A {
    constructor() { // permet de créer une instance de la classe A.
    }
}

No fucking shit Sherlock,I wouldn't have guessed.

Cela dit tu viens d'un milieu de chercheurs, et pour le peu que je connais au domaine au travers d'anciens collègues, leur code est généralement assez dégueux et imbittable (c'est d'ailleurs pour ça qu'on nous embauchait : pour nettoyer derrière).

Oh ? Les quelques commentaires dans le code ne vous suffisent pas ?

En même temps, c'est normal, on fait du prototypage, on teste des trucs à gauche et à droite, on prend des stagiaires pour faire 2-3 trucs, tu m'étonnes que ce soit dégueux la plupart du temps.

En même temps le but est juste de produire les résultats pour nos articles, une fois l'article publié, on en a plus tant besoin que ça, à moins qu'il faille reproduire ou faire d'autres trucs du genre, ou carrément se constituer un Framework.

En fait, j'ai du mal à imaginer comment on peut comprendre le code d'une fonction perdue au milieu de milliers d'autres (dans des libs ou non) et le comprendre sans avoir besoin de docs quand c'est fonction "optimisée" (comprendre, elle utilise des trucs avancés comme du simd ou même de l'assembleur pour faire ce qu'elle a à faire avec le moins d'instructions possibles). Pour moi ça tient de la magie noire à ce niveau-là.

Ben déjà arrête de confondre documentation et commentaires... d'autant plus que je te l'ai déjà fait remarqué.

Et ensuite, comme je l'ai déjà dit, organise un minimum ton code, tes fichiers, et ton architecture, et ça deviendra tout de suite bien plus facile à se repérer.

Pour la fonction optimisée... on entre dans un des cas de figures d'exceptions que j'ai bien explicité...
Et pour utiliser la fonction, tu n'as pas besoin de regarder son contenu, mais sa signature...

Après, pense aussi à utiliser les bibliothèques appropriées plutôt que de partir directement sur de l'assembleur... et n'optimise que ce qu'il est nécessaire d'optimiser. Gagner quelques instructions, ça reste un besoin très très rare. Pour preuve, je fais mes trucs directement en JS... donc pour l'optimisation...

Mais peut-être es-tu juste un dieu parmi les développeurs, qui sait ?

Je ne suis que l'homme qui parle à l'oreille des ordinateurs.

[Sodium]

En fait, j'ai du mal à imaginer comment on peut comprendre le code d'une fonction perdue au milieu de milliers d'autres (dans des libs ou non) et le comprendre sans avoir besoin de docs quand c'est fonction "optimisée" (comprendre, elle utilise des trucs avancés comme du simd ou même de l'assembleur pour faire ce qu'elle a à faire avec le moins d'instructions possibles). Pour moi ça tient de la magie noire à ce niveau-là. Mais peut-être es-tu juste un dieu parmi les développeurs, qui sait ?

En fait le code objet, avant d'être tout un tas de design pattern qui font très bien à citer en entretien d'embauche, c'est avant tout une manière de décrire en langage humain ce que fait du code. Quant à la sur-optimisation du code, c'est généralement à part pour des cas très spécifiques (écriture d'un moteur 3D par exemple) une mauvaise pratique. Le gain des méthodes de ninja qui produisent du code illisible est généralement négligeable (voir négatif) et l'optimisation consiste plutôt à ne pas faire faire au programme des choses inutiles, ce qui est plus facile quand le code est compréhensible.

[goldbergg]

En fait, j'ai du mal à imaginer comment on peut comprendre le code d'une fonction perdue au milieu de milliers d'autres (dans des libs ou non) et le comprendre sans avoir besoin de docs quand c'est fonction "optimisée" (comprendre, elle utilise des trucs avancés comme du simd ou même de l'assembleur pour faire ce qu'elle a à faire avec le moins d'instructions possibles). Pour moi ça tient de la magie noire à ce niveau-là. Mais peut-être es-tu juste un dieu parmi les développeurs, qui sait ?

Tu prends n'importe qu'elle soft a base de CRUD (genre application de gestion), t'as généralement un beau découpage en couche (DAL, BLL, Utils, etc...) et dans chaque couche tu retrouves des sous-découpage par types d'entité, puis par entités.
Le tous codé en respectant des convention d'écriture qui implique que tous les fichiers sont plus ou moins écrit de la même façon.

Peut importe la taille du projet, tu prends n'importe qu'elle fichier, a partir de la couche ou il est et de son arborescence, tu comprends très rapidement ce que va traité ce fichier, ensuite si dans ce fichier les fonctions sont bien nommé, ça devrait être très simple de comprendre son fonctionnement sans aucun commentaire.

Par exemple une class UserManagement dans la DAL, va forcement gérer les utilisateur dans une BDD et une fonction nommé Get(int Id), rien qu'au nom on sais se qu'elle fait et pour peux qu'elle appelle des api correctement nommé (ex: Database.GetContext()) et il n'y a franchement pas de place pour le moindre commentaires, tout est compréhensible (après bien sur il y a des exceptions).

Perso j'ai eu a reprendre d’énorme projet tout degeux, sans doc, sans commentaire, mais heureusement bien architecturé et j'ai toujours réussie facillement a comprendre le code et a le maintenir.

Par contre si tu bosse par exemple dans le jeux-video et que tu ecries une fonction racine carrée inverse rapide
https://fr.wikipedia.org/wiki/Racine...inverse_rapide
La oui, les commentaires sont obligatoire.
Et encore faut il qu'ils soient pertinent, parce que perso

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?

même avec un commentaire, j'y comprend rien

Bref, tout dépend du type de projet et de son langage.

[Neckara]

Tiens un exemple de code avec une documentation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/// Enum describing the different status of a process.
#[derive(Clone, Copy, Debug)]
pub enum ProcessStatus {
    /// Waiting in uninterruptible disk sleep.
    Idle,
    /// Running.
    Run,
    /// Sleeping in an interruptible waiting.
    Sleep,
    /// Stopped (on a signal) or (before Linux 2.6.33) trace stopped.
    Stop,
    /// Zombie.
    Zombie,
    /// Tracing stop (Linux 2.6.33 onward).
    Tracing,
    /// Dead.
    Dead,
    /// Wakekill (Linux 2.6.33 to 3.13 only).
    Wakekill,
    /// Waking (Linux 2.6.33 to 3.13 only).
    Waking,
    /// Parked (Linux 3.9 to 3.13 only).
    Parked,
    /// Unknown.
    Unknown(u32),
}

ProcessStatus c'est le "status of a process."... WOW, je ne m'en saurais pas douté.

La plupart des enum, tu ne fais que répéter le nom, sans plus de détails. Et derrière, si un nouveau noyau Linux sort avec une modification de certains statuts, ta documentation sera obsolète...

Avec des commentaires qui, je présumes (je n'ai pas regardé d'avantage) peuvent être trompeurs :

• Run, c'est running or runnable ;
• Idle, je ne suis pas sûr que ce ne soit "que" pour un "disk sleep".
• Zombie/Tracing/Parked : pas sûr que ce soit explicite pour tout le monde.

/// Struct containing a process' information.
pub struct Process {

Quelle surprise... Bon, si on voulait être plus explicite, on l'aurait nommé ProcessInfo.


Mais bon, c'est une bonne illustration de ce que je dis. Des commentaires/docs qui ne font presque que paraphraser le code. Mais la seule chose réellement utile n'y est pas.

Parce que je présume que Process et ProcessStatus, ça ne vient pas non plus de nulle part...
Alors on a des commentaires paraphrasant le code un peu partout... mais aucun lien vers une documentation Linux ou la RFC dédiée e.g. : https://man7.org/linux/man-pages/man5/proc.5.html (see /proc/[pid]/stat (3) Sate ).

Parce que là, si il y a un changement... au moins la documentation sera mise à jour.


Peut être même ajouter un lien du type :
https://idea.popcount.org/2012-12-11...rocess-states/
https://www.tecmint.com/linux-process-management/

Avec un mirroir sur archive.org pour garantir la pérénité du lien.


Parce que je te pose la question, y'a des commentaires, c'est beau, mais en l'occurence, à quoi servent ces commentaires ? Quelle utilité à part paraphraser le code, et potentiellement induire en erreur l'utilisateur ? Sachant que la génération de la doc ne doit normalement pas en avoir besoin pour se générer.


C'est bien beau de prendre son temps à mettre des commentaires partout... mais il faut aussi se demander pourquoi.


EDIT: Après, je veux bien croire que ce n'est pas ton plus beau code, que c'est peut-être un side-project, que c'était des contraintes d'autres personnes, que c'est un fork, ou je ne sais quoi. Mais c'est un exemple assez parlant de ce dont je parle.

[Neckara]

Par contre si tu bosse par exemple dans le jeux-video et que tu ecries une fonction racine carrée inverse rapide
https://fr.wikipedia.org/wiki/Racine...inverse_rapide
La oui, les commentaires sont obligatoire.

Perso, je ne mettrais qu'un commentaire: le lien vers la page Wikipédia.

[imperio]

...

Non, sur ce coup-là tu as parfaitement raison. La doc n'est pas utile, cependant pour la génération de doc, ça permet d'avoir un truc un peu plus sympa que "rien du tout". De plus, j'associe pas ça à du commentaire de code (sauf si tu considères une déclaration de type comme du code ? Question de point de vue après...).

Pour en revenir au fameux "le code c'est la doc", on peut prendre du code pas trop avancé de rust (puisqu'on semble y être) et tu peux bien évidemment me dire ce que le code de cette fonction fait dans le détail je suppose : https://github.com/rust-lang/rust/bl...et_impl.rs#L23 Et bien évidemment, les commentaires ne servent complètement à rien.

Après tu aimes faire dans l'attaque personnelle et tu aimes cracher sur les gens qui ont tendance à documenter/commenter trop que pas assez en prenant pour exemple des cas spécifique. C'est moche et franchement bas de front, mais je pense que je vais arrêter de débattre là. Nous avons chacun nos opinions sur le sujet et nous sommes heureux de ne pas avoir à travailler chacun avec l'autre. Mais à titre personnel, j'apprécie de ne pas avoir à me farcir des milliers de lignes de code juste pour comprendre ce que les appels d'une fonction font.

Quant à la sur-optimisation du code, c'est généralement à part pour des cas très spécifiques (écriture d'un moteur 3D par exemple) une mauvaise pratique.

Ça tombe mal, ça fait partie de mon boulot. De plus, la sur-optimisation en elle-même n'est pas mauvaise, c'est l'optimisation précoce qui l'est. À bon entendeur.

[disedorgue]

Et encore faut il qu'ils soient pertinent, parce que perso

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?

même avec un commentaire, j'y comprend rien

Bref, tout dépend du type de projet et de son langage.

Qu'est-ce qui n'est pas compréhensible ici d'un point de vu code ?
Perso, je trouve ça lisible, après la valeur "magic", c'est ce que l'on appellerait du fonctionnel qui est une abstraction au dessus du langage et qui n'a pas lieu d'être documenté dans le code justement.

[Neckara]

Pour en revenir au fameux "le code c'est la doc", on peut prendre du code pas trop avancé de rust (puisqu'on semble y être) et tu peux bien évidemment me dire ce que ce code de cette fonction fait dans le détail je suppose : https://github.com/rust-lang/rust/bl...et_impl.rs#L23 Et bien évidemment, les commentaires ne servent complètement à rien.

Déjà je n'ai jamais fait de Rust.

Ensuite ta fonction fait déjà 100 lignes, mais je sais qu'elle me retourne un vecteur d'implémentation de "blankets", je présume que c'est un concept de Rust ?
Ty, après avoir recherché, ça semble être le Type... pas super explicite, pourquoi ne pas l'avoir nommé directement Type ?
DefID, c'est un identifiant de définition.

Dans le code, que je ne devrais pas avoir à lire, tu as une sous-fonction assez longue et pas nommée (40 lignes). Si tu appelles cela du "code propre", je m'inquiète sérieusement. Mais en gros, ça récupère une liste, sur certaines conditions ça exclus des éléments (on aurait besoin d'un fonction nommée), puis ça construit la structure d'implémentation à retourner (idem une fonction de construction ça aurait été bien).

Bon, c'est vrai que ça a été compliqué à lire pour moi, c'est la première fois que je lis du Rust, et j'ai des difficulté pour le formatage du code (e.g. accolades, mais pas de () pour les if). Bon, ça c'est une question d'habitude.


Enfin bref, tu me donnes un code non-pertinent vu qu'il ne respecte même pas ma condition initiale : "un code propre".

Après tu aimes faire dans l'attaque personnelle et tu aimes cracher sur les gens qui ont tendance à documenter/commenter trop que pas assez en prenant pour exemple des cas spécifique. C'est moche et franchement bas de front, mais je pense que je vais arrêter de débattre là.

T'as pas aimé que je prenne de ton code en exemple pour illustrer ce que je dis ?

Mais à titre personnel, j'apprécie de ne pas avoir à me farcir des milliers de lignes de code juste pour comprendre ce que les appels d'une fonction font.

Encore une fois, si tu dois faire ça, c'est que ton code est pourri à la base...
Un code propre doit respecter les principes d'encapsulation et d’abstraction.

Ça tombe mal, ça fait partie de mon boulot. De plus, la sur-optimisation en elle-même n'est pas mauvaise, c'est l'optimisation précoce qui l'est. À bon entendeur.

Soit ton optimisation est utile soit elle ne l'est pas. Si tu "sur-optimises" alors que tu n'en as pas besoin, non seulement tu auras perdu du temps, mais en plus tu auras rendu ton compte moins maintenable.

Après, oui, quand c'est gratuit, faut pas se gêner, et appliquer les bons principes de programmations. Si tu as une fonction à optimiser et qu'elle se retrouve plus rapide que ton besoin, oui, c'est pas la mort. Si tu anticipes des besoins futurs ou des machines moins performances, oui, c'est bon.

[Neckara]

Qu'est-ce qui n'est pas compréhensible ici d'un point de vu code ?

Ouch, ça faisait longtemps que j'avais pas lu du C/C++, j'ai cru qu'il faisait un "&" bit à bit xD.

Il est compliqué de savoir ce que fait la seconde ligne. On converti y en un long i. Puis on calcul un nombre bizarre auquel on soustrait i/2, mais on ne comprend pas pourquoi.

Mais c'est vrai qu'avec la signature de la fonction avec un nom explicite (FastInvSqrt), on comprend tout de suite ce qu'on fait. Mais perso, je mettrais quand même un lien à la page Wikipédia.


Par contre oui, j'avais pas vu que le code venait de Wikipédia et que le commentaire en était tiré xD.

[Pyramidev]

Pour en revenir au fameux "le code c'est la doc", on peut prendre du code pas trop avancé de rust (puisqu'on semble y être) et tu peux bien évidemment me dire ce que le code de cette fonction fait dans le détail je suppose : https://github.com/rust-lang/rust/bl...et_impl.rs#L23 Et bien évidemment, les commentaires ne servent complètement à rien.

Déjà je n'ai jamais fait de Rust.

Ensuite ta fonction fait déjà 100 lignes, mais je sais qu'elle me retourne un vecteur d'implémentation de "blankets", je présume que c'est un concept de Rust ?

Un exemple de blanket implementation :

Code Rust :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#[stable(feature = "rust1", since = "1.0.0")]
impl<T: fmt::Display + ?Sized> ToString for T {
    #[inline]
    default fn to_string(&self) -> String {
        use fmt::Write;
        let mut buf = String::new();
        buf.write_fmt(format_args!("{}", self))
            .expect("a Display implementation returned an error unexpectedly");
        buf.shrink_to_fit();
        buf
    }
}

Traduction : pour tout type T qui implémente le trait Display, ce type implémente aussi le trait ToString et voici l'implémentation par défaut de la méthode to_string (requise par le trait ToString).

Si on traduisait ça en POO, on dirait que la classe abstraite Display dérive de la classe ToString et que le code de Display contiendrait une implémentation de la méthode virtuelle to_string de ToString. En vrai, le système de type de Rust n'obéit pas aux mêmes contraintes que l'héritage en POO, mais je donne quand même une analogie pour que ce soit plus clair.

De manière plus générale :

Implementations of a trait on any type that satisfies the trait bounds are called blanket implementations

Source : https://doc.rust-lang.org/book/ch10-...lement-methods

Du coup, la fonction get_blanket_impls citée par imperio a visiblement pour rôle de chercher les implémentations par défaut pour les traits que définit le type ty en paramètre.

Personnellement, je n'ai pas compris les détails de l'implémentation. En amont, je crois qu'il faut d'abord comprendre ce à quoi correspond le type core::DocContext et je n'ai pas le temps de regarder ça. Il y a aussi des abréviations que je ne comprends pas, typiquement tcx.

Il faut noter qu'il existe un guide pour aider à comprendre l'implémentation du compilateur de Rust : https://rustc-dev-guide.rust-lang.or...his-guide.html

Je n'ai pas lu ce guide, donc je ne sais pas quelle serait la difficulté de lire l'implémentation après avoir lu ce guide-là.

[Neckara]

Merci pour l'explication sur les Blankets.

Personnellement, je n'ai pas compris les détails de l'implémentation. En amont, je crois qu'il faut d'abord comprendre ce à quoi correspond le type core::DocContext et je n'ai pas le temps de regarder ça. Il y a aussi des abréviations que je ne comprends pas, typiquement tcx.

C'est aussi que je ne comprends pas la syntaxe : Ty<'tcx>. Ça ressemble un peu à un template/générique, par contre c'est bizarre le '.

cx je miserais sur context. t je dirais soit type soit trait. À mon avis ça serait type context.

D'ailleurs Rust semble être d'accord pour dire que tcx, c'est pas très explicite.
https://rust-lang.github.io/compiler...cx-transition/

Et j'étais pas loin :

the name “tcx” suggests “type context”, but this context is far more general and is used in parts of the compiler (e.g., parsing, macros) that have nothing to do with types

Et sans tricher \o/

[Pyramidev]

C'est aussi que je ne comprends pas la syntaxe : Ty<'tcx>. Ça ressemble un peu à un template/générique, par contre c'est bizarre le '.

Les variables qui commencent par une apostrophe sont des durées de vie (lifetimes). Les paramètres entre < et > sont bien des paramètres génériques, un peu comme les templates en C++. Ces paramètres peuvent être aussi bien des types normaux que des annotations de durées de vies. Rust doit souvent propager à la compilation des contraintes sur les durées de vie.

Pour ceux que ça intéresse, plus de détails ici : https://doc.rust-lang.org/book/ch10-...me-syntax.html

D'ailleurs Rust semble être d'accord pour dire que tcx, c'est pas très explicite.
https://rust-lang.github.io/compiler...cx-transition/

Merci pour le lien.

[Neckara]

Les variables qui commencent par une apostrophe sont des durées de vie (lifetimes). Les paramètres entre < et > sont bien des paramètres génériques, un peu comme les templates en C++. Ces paramètres peuvent être aussi bien des types normaux que des annotations de durées de vies. Rust doit souvent propager à la compilation des contraintes sur les durées de vie.

Pour ceux que ça intéresse, plus de détails ici : https://doc.rust-lang.org/book/ch10-...me-syntax.html

Wow, ça me paraît un peu spécial ça. Je comprends un peu l'idée globale, mais wow.
Et puis pourquoi ils mettent un ! à leur println ?

J'ai l'impression d'être un humain débarquant dans une société extra-terrestre.

[Pyramidev]

Et puis pourquoi ils mettent un ! à leur println ?

Parce que println! est une macro.
Le premier paramètre, qui correspond au format de la chaîne, doit être une string literal, donc doit être connu à la compilation.
Cela permet notamment de contrôler à la compilation que le nombre de paramètres et leurs types sont cohérents avec le format.
Un exemple de code illustratif en ligne que l'internaute peut directement modifier, compiler et exécuter : https://doc.rust-lang.org/rust-by-ex...llo/print.html
(Attention, il y a deux lignes qui ne compilent volontairement pas. Elles ont un commentaire FIXME en dessous.)

[Invité]

Wow, ça me paraît un peu spécial ça. Je comprends un peu l'idée globale, mais wow.
Et puis pourquoi ils mettent un ! à leur println ?

J'ai l'impression d'être un humain débarquant dans une société extra-terrestre.

Welcome to the real world.... Et oui, il n'y a pas que Java et JavaScript dans la vie. Bienvenue dans le monde des macro, traits, lifetime, ownership et autre borrowing.

Concernant les commentaires de code, la bibliothèque base d'Haskell en a 29k lignes, pour 33k lignes de code... Et ce n'est certainement pas parce que le langage manque d'abstraction...

Et concernant l'optimisation, il faut arrêter de prendre son cas particulier pour une généralité. Une bonne partie de mon travail consiste justement à optimiser du code. Et quand on doit choisir entre du code "propre" qui met 3 mois à donner un résultat et un code moins lisible qui met 3 jours, la décision est vite prise...

[Neckara]

Parce que println! est une macro.

C'est assez marrant, merci pour le lien. Personnellement, je trouve que c'est une manière un peu étrange de gérer les variadics et les fonctions inline. Après pour le DSL, pourquoi pas...

https://doc.rust-lang.org/rust-by-example/macros.html

[Neckara]

Welcome to the real world.... Et oui, il n'y a pas que Java et JavaScript dans la vie.

Je ne connais pas que JavaScript et Java hein...

J'ai fais de l'ASM, C, C++, C#, Java, JavaScript, R, PHP, Python, Lua, LaTeX, TCL/TK, XSLT, PL/SQL, et je dois en oublier.

Ce n'est pas parce que je ne code pas dans TON langage, que je ne suis pas dans le "vrai monde"...

Concernant les commentaires de code, la bibliothèque base d'Haskell en a 29k lignes, pour 33k lignes de code... Et ce n'est certainement pas parce que le langage manque d'abstraction...

Et combien de lignes sont de la doc, avec exemples, de l'API publique ?

Et concernant l'optimisation, il faut arrêter de prendre son cas particulier pour une généralité. Une bonne partie de mon travail consiste justement à optimiser du code.

Et qu'est-ce qui te fait dire que ce n'est pas toi, qui est un cas particulier ?

Déjà que très peu d'applications/logiciels sont optimisés, si tu comptes en plus que même sur les bibliothèques optimisées tu n'optimises que les goulots d'étranglements... et pas l'entièreté du code (et heureusement).

Et quand on doit choisir entre du code "propre" qui met 3 mois à donner un résultat et un code moins lisible qui met 3 jours, la décision est vite prise...

Un facteur x30 ? T'es sûr que tu n'exagères pas un peu ?

Ok, pour des optimisations d'I/O, réduction de la complexité de l'algorithme, utilisations de bibliothèques de calculs, bonnes options de compilations, éviter les copies/allocations inutiles, et 2/3 bons principes, voire passer sur GPU... mais me dire que tu gagnes un facteur de x30 avec un code "non-propre", je suis sceptique.

Le nommage, l'indentation, retours à la ligne, et au pire des fonctions inlines, c'est pas ça qui va modifier tes performances. Passer à l'assembleur, tu gagneras des pouillèmes, et certainement pas un facteur x30, si au départ tu utilisais des bibliothèques adaptées.

À la limite, faire plusieurs opérations en un seul parcours en évitant des copies... mais un facteur x30... ça me semble quand même un peu beaucoup.

Un algorithme plus compliqué mais de moindre complexité ? Ok, mais normalement tu donne le nom de l'algorithme, et tu peux lier cela soit à une page Wikipédia soit à un article de recherche qui donnera tous les détails nécessaires. Et une fois que c'est écrit/validé, t'y retouche normalement plus.



Après ça dépend ce que tu appelles "moins lisible".


<troll>
Après, si je veux être de mauvaise foi, je pourrais te dire que je préfère un code propre qui donne un résultat en 3 mois, qu'un code "moins propre" qui donne un mauvais résultat en 3 jours . Après, si t'as un serveur de calcul, tu parallélise à l'arrache, tes 3 mois, tu le fais en 2 jours à tout péter, plutôt que tu de passer 5 jours à optimiser ton code sur ta machine. Ou si je veux vraiment troller, je dirais que je préfères un code qui s'exécute en 3 mois, que de passer 3 mois à écrire un code qui s'exécute en 3 jours.

Désolé, mais je prends de l'avance sur trolldi.
</troll>

[Invité]

Je ne connais pas que JavaScript et Java hein...

J'ai fais de l'ASM, C, C++, C#, Java, JavaScript, R, PHP, Python, Lua, LaTeX, TCL/TK, XSLT, PL/SQL, et je dois en oublier.

Oui, n'importe quel dev sénior "connait" et "a fait" au moins 15 langages différents. Mais en maitriser vraiment plus de quelques uns, là ça devient beaucoup plus difficile...

Ce n'est pas parce que je ne code pas dans TON langage, que je ne suis pas dans le "vrai monde"...
...

Tout à fait. Et réciproquement : tes problématiques ne sont pas forcément les miennes donc les généralités sur l'optimisation où il suffirait d'utiliser la bonne lib, le bon algo wikipedia ou le bon GPU, merci mais non merci.