Reprise du message précédent :

Tu donnes des conseils de préparation physique aux coureurs du Tour de France parce que tu vas au marché à vélo ?

De ce que j’en vois, il va pas penser à ta place. Mais si tu sais ce que tu veux faire, ça va t’écrire 70% du code pour toi. Et c’est déjà un chouette gain de temps, d’être un super autocomplete

 
Un autre intérêt aussi depuis qu'on l'utilise, c'est que parfois, ça incite à remettre en question le fait de savoir si on s'y prend bien tout court en terme de solution pour un problème donné. En clair, est-ce que l'algo est réellement nécessaire, est-ce la bonne démarche, est-ce la bonne question à la base.
L'effet pervers du truc, c'est que ça tendra vers une certaine uniformisation au fil du temps.

Sauf si tu fais du go, ça va être fortement modulé par la correspondance entre le code dont tu as besoin et le training set. Parce que si t’es pas dans ses clous il va plus écrire 10% du code 100% du temps.

Je voulais te montrer, mais tout à été viré dans la PR.

on va dire que j'ai pris l'habitude de bien utiliser et de savoir quoi faire avec Copilot depuis le temps que je l'utilise, après si tu n'es pas content, c'est pas grave, je t'aime quand même.

Je ne minore pas ton expérience avec copilot, et en particulier je sais qu’on utilise pas exactement le même. C’est aussi pour ça que je me dis que je dois regarder plus fort de mon côté, d’autres gens semblent en être satisfaits et c’est encore un peu tôt pour dire que tous les autres sont cons.

Le workload est un énorme facteur, si c'est loin du training set tu vas mettre des plombes à affiner ton prompt pour que ça commence à se rapprocher un peu, donc t'as aussi vite fait de faire ça toi même, surtout que tu dois tellement comprendre le problème que t'as largement plus vite fait d'y aller toi même.

Genre j'ai demandé à 3.5 de parser parser un pack git, il veut pas, il arrive à parser le header (12 octets) puis il se paume, complètement à l'ouest, pas réussi à affiner, mais fair enough les packfiles c'est de la grosse merde.

J'ai demandé un pack index, il a commencé vraiment complètement à l'ouest (mais confiant), en raffinant et en le reprenant au bout d'une demi douzaine d'échanges il arrive plus ou moins à quelque chose, mais t'as aussi vite fait de faire ça à la main, parce-que sans connaitre exactement le format c'est pas possible (après charger tout l'index en mémoire je lui ai demandé de me sortir un offset, il a sorti n'imp, j'ai arrêté).

Et les pack index c'est pas un truc obscur, c'est bien documenté par le projet (pour le coup), toutes les implems de libs git ont besoin de savoir taper dedans, et il y a des tutos / explications sur le web. Il y a un peu de confusion possible avec le fichier d'index mais voilà.

Sinon je croyais qu'un vrai dev aujourd'hui il passait réellement qu'une toute petite partie de son temps à vraiment écrire du code (faut bien caser du temps pour les réunions), du coup est ce que c'est vraiment utile à passer du temps à apprendre à maitriser un prompt pour gagner 50% de rapidité (vs des outils d'autocompletion d'IDE classiques) pour une tâche que tu fais au final une faible proportion de ton temps ?

Pas moyen de gérer les labels sur l'application Android de Gmail

Je passe mon temps à essayer de comprendre le code des autres, pendant de nombreuses heures voire de nombreux jours

Dites, je suis une quiche en automobile...  
 
Notre C4 Picasso de bientôt 10 ans roule beaucoup moins depuis qu'on a la twingo electrique. En gros depuis la dernière vidange en Août 2022, on a fait environ 8000 km
 
D'après Citroen la révision / vidange est à faire tous les 15 ou 20 000 km (selon les sources) ou tous les ans...  
 
Mais je me dis que vu le kilométrage, ça doit pouvoir attendre plusieurs mois, voire être décalé au printemps prochain, non?

https://www.ggpauto.fr/faire-la-vid [...] -justifie/

j'étais dans une situation très spéciale où je produisait du code nouveau en partant de très peu d'intégration, c'est pour ça que je me suis dit que c'était idéal.  
Je parsais un nouveau format de fichier, à partir d'une spec, et comme intégration j'avais juste à implémenter une interface.

Ouais enfin ça dit tout et son contraire ton truc  

 
Bah ça dit quand même ça :
 

 
ça me semble assez clair.

Je trouve le message clair et cohérent pourtant:

Les modulations c'est une voiture vraiment vieille (pré 1994), beaucoup de ville, et des huiles minérales ou semi-synthèse, auquel cas il faut coller plus près aux recos constructeur.

Ouais mais au dessus ils disent des trucs moins optimistes.

Bon, je la ferais avant le ski alors.

Tu ne risques absolument rien à espacer de 2-3-4 ans. Ça a été maintes fois démontré. Après tout dépend aussi ta façon de conduire.  
 
Mais une voiture mal entretenu c’est mort pour espérer bien la vendre et encore moins si besoin d’une prise en charge constructeur.  
 
Cela dit, dans ton cas ça ne s’applique pas je pense.

Pour moi, copilot, faut vraiment le prendre comme un truc qui te fait gagner du temps sur les tâches pour lesquelles ta compétence a 0 valeur ajoutée.

Genre ça te premache bien la doc inline, ou les  tests (unitaires et fonctionnels).
C'est vachement utile aussi sur tous les cas du genre "ok je dois utiliser tel truc, mais je me souviens plus du nom exact ni du format des args" : tu décris l'action en commentaire et c'est parti.
Ça marche aussi pour les tâches hyper bateau que tout le monde fait tout le temps.

Bref, ça fait gagner un peu de temps à chaque fois. C'est loin d'être miraculeux, c'est du 5min par ci, 2min par là. Je sais plus qui ici a dit que c'est un autocomplete++, mais c'est exactement ça.

Et au bout du compte, ça fluidifie tellement le taf et ça te permet tellement de te concentrer sur l'important que, pour moi, ça mérite très largement le coût de l'abonnement.

Par contre c'est clair, faut pas lui demander plus que du commun.

Bah là, elle roule plus que sur des moyens et grands trajets. Je suis même obligé de trouver des prétextes pour la sortir de temps en temps pour qu'elle roule au moins une fois toutes les 2 semaines.

Elle a 10 ans, l'objectif de revente c'est une reprise genre prime a la casse ou autre quand on l'a changera.
Après elle n'a que 135000 km, elle peut en faire encore au moins autant

C'est le hdi 16 soupapes ? Ça va être la révision de la distri nan ?

Je sais pas, je vais regarder, mais il me semble qu'on l'a déjà fait.

Édit : accessoires on a fait a 100000km.

Distribution c'est 10 ans, donc novembre 2023.
Donc on fera une session complète en novembre et ça ira bien.

Question : vous êtes du genre à mettre des commentaires partout ou à penser que le code se suffit à lui même

Perso j'ai tendance à sur-commenter. Je me sert des commentaires pour bien séparer les différents blocs fonctionnel d'une fonction. Ça donne un commentaire tous les 4 lignes.
Je deteste relire du code, même le mien. J'ai juste besoin de parcourir mes commentaires.

Je documente les méthodes publiques et les fonctions privées non triviales : description, arguments, retour. Éventuellement exceptions levées.

Chaque fonction ne devant faire qu'une seule chose, je trouve ça suffisant en général.
Et puis c'est cool parce que du coup je peux laisser Copilot documenter, quand tu suis cette philosophie il s'en sort vraiment pas mal.

Cas particuliers appelant des commentaires supplémentaires : solution de contournement (e.g. souci dans une lib avec la date du pb et l'issue github associée si possible, pour pouvoir retirer le contournement dans le futur), choix d'algorithme pouvant paraître contre-intuitif de prime abord, avertissements divers,... Bref ce sont davantage des aides à la maintenance que des explications.

Le code se suffit. J'ai des noms de fonctions à rallonge et idem avec certains params mais au moins c'est clair (selon moi ).
Quand je documente c'est soit par de la JS Doc pour avoir de l'auto complétion et expliquer un cas un peu complexe. Ou bien car y'a une issue ouverte et que mon code est un workaround et je link l'issue en question ou le cas spécifique.

J'essaie de mettre des noms assez clairs et des docstrings, mais quand je veux ou peux pas rendre le code lisible je vais rajouter un bloc de commentaires pour expliquer un peu ce que ça fait (pas comment, je déteste ces commentaires).

Après j'ai tendance à pas mettre des commentaires très longs ou trop souvent dans le code parce-que IME c'est pas ou mal maintenu, j'essaie surtout de mettre des explications très complètes dans les messages de commits, pour savoir quelles raisons j'avais de faire une pareille merde quand je reviens dessus 6 mois plus tard.

 
Le code ne se suffit pas à lui-même.
La plus-value des commentaire ceci dit n'est pas de répéter ce qu'exprime déjà le code (sauf si l'implémentation est cryptique ET qu'elle a une bonne raison de l'être) mais plutôt d'expliquer pourquoi il est écrit de cette façon plutôt qu'une autre.

Pour le coup un docstring généré automatiquement qui écrit en prose ce que fait le code ce serait chouette. Je pense que c'est quand même utile de dire avec des mots ce que fait le code, c'est plus facile à lire et à comprendre. Le problème c'est que c'est souvent faux.

 
This

 
Je préfère que ça passe par le nommage et une gestion correcte de la complexité, parce que ouais la maintenance des commentaires et les commentaires automatiques j'ai jamais trouvé grand chose de satisfaisant. Exception faite des systèmes où ce sont tes tests qui génèrent la doc de ton API, t'as une forme d'assurance que ça correspond.
 
Et pour éviter la charge de maintenance des commentaires, peu mais le plus locaux possibles et qualitatifs ça me va bien.

 
Oui du coup le code se suffit sauf très rare cas ou c'est pas écrit d'une bonne manière.

Moi non plus, je me dis que c'est typiquement le genre de tâches que je verrais bien copilot et consorts faire convenablement, avec une plus-value certaine, parce qu'on a beau dire, le plus beau code du monde ça vaut pas le language naturel pour expliquer un truc (même un truc "simple" ). (C'est sûr que c'est plus flagrant pour moi qui fais surtout du C++.)

Personne habite vers la Clusaz ?
Je cherche à savoir qui est l’auteur des vitraux de l’église de Sainte Foy, mais je ne trouve pas
 
http://cordee74190.eklablog.fr/la- [...] a117310018

Envoi un mail à la mairie  

Yes c’était mon plan B si je ne trouvais pas la réponse ce soir

C'est comme tout, c'est une question de mesure
 
Je déteste les commentaires inutiles qui font juste paraphraser du code simple, ou pire, la signature de la fonction (surtout que trop souvent ces derniers ne sont pas mis à jour avec l'évolution du code et du coup décrivent un comportement faux ou partiel). Par contre des commentaires dans le cas d'un algo un peu complexe, ou une optimisation/implémentation pas évidente, je prend.  
 
Avec l'âge, l'expérience pardon, je me rend compte que la majorité de mes commentaires répondent en fait à "Pourquoi ?". Pourquoi ce bout de code est là, pourquoi il a été implémenté de cette façon là et pas d'une autre, dans quel contexte, éventuellement s'il périme (par exemple dans le cas d'un monkeypatch temporaire en attendant le fix ou l'upgrade d'une librairie sous-jacente), pourquoi avant d'y toucher faut faire attention à ça ou ça si y a des side-effects pas évidents à identifer etc...

Alors d'une tu pourrais peut être demander au cabinet, mais de deux si tu veux commander des vitraux ça risque d'être tendu, quelqu'un qui en faisait il y a 50 ans est à la retraite si non décédé.

T'as contacté l'office du tourisme ou la mairie ?

Je cherchais la réponse ce soir du coup ça collait pas avec les horaires d’ouverture
 
Mais oui je vais faire ça, thanks  

https://twitter.com/itsmefrenchy123 [...] 0913502209

Elon a quand même du bol que le siège soit dans la capitale du wokisme, au Texas il se serait déjà fait dégager à coup d'AR-15.

en fait il a viré tous les adultes responsables et a gardé tous les teenager attardés dont lui ?