Reprise du message précédent :

Tu te fais toute la CppCon ou bien ?

Le répertoire du projet si c'est un script utilisé uniquement par ce projet, mais pour un script commun à différents projets il y a un dossier commun (contexte de dépôt monolithique). Et les dépendances tierces ne sont pas fournies non, si un projet OSS me dit qu'il dépend de psql je veux installer psql moi-même (et pas me retrouver automatiquement avec sous dossier rempli de gros binaires linkés statiquement ou autre truc de cet acabit )

'tain je trainais une dette à l'Urssaf depuis juillet et aout 2020, et la dette était exactement du même montant qu'un mois que j'avais payé, du coup il a fallu m'expliquer avec des mots

J’ai cliqué sur une vidéo CPPCon et maintenant youtube arrête pas de m’en proposer d’autres
 
Alors je clique dessus Enfin sur certaines, Carruth c’est des présentations intéressantes et souvent assez générales donc c’est cool, ça s’applique pas 100% qu’au C++ (même s’il y a des trucs que si, genre quand il parle des problèmes de perf de unique_ptr à cause des moves non destructifs  )
 
(même si la partie qui gère l’unwinding existe aussi en rust, et là t’as pas de noexcept, faut panic=abort au niveau du projet).
 
Mais c’est marrant d’avoir regardé ça ce matin et là paf je peux lier ça à une question

“It depends”, ya pas de raccourcis faciles, et surtout pas mettre une limite en dur.

 
Ya un nom standard / commun pour ça?
 
Et une réponse sur comment make manipule $PATH (ou pas), pour savoir comment trouver les outilscripts?

Oui des gros machins comme ça naturellement

Il y a une tendance commune on va dire : https://api.csswg.org/bikeshed/?for [...] ta/spec.bs

Pour make ce sont souvent des variables pour les exe, on croise souvent $(YACC) et rarement yacc, ce qui te permet depuis l'extérieur de faire un peu comme tu veux (yacc + $PATH, full path, ...)

T'as raison    
 
Le :

C'est le drame de tellement de projet
 
Tant que le code est lisible est documenté, la taille importe assez peu (que ce soit dans une fonction ou ailleurs).
Ils ont combien d'XP ces devs ?
Ils ont bossé combien d'années sur du legacy pour savoir comment ça fonctionne dans la vraie vie ?
 
Comme dit masklinn, si tu dois jongler dans je sais pas combien de fonction pour comprendre un code qui aurait été beaucoup plus lisible à plat, t'as perdu.
 
Un des seuls potentiels arguments légitimes c'est que c'est + simple de faire des tests unitaires sur des unités de code + simples mais encore c'est pas une vérité absolue et, si t'as trop découpé, tu finis par en fait tester l'implémentation donc fail.
 

J'ai un projet.
Je veux automatiser des trucs de dev.
Je me dis que je vais utiliser make (potentiellement une erreur mais bon).
Certains des trucs à automatiser sont trop compliqués pour du make/shell (genre combinaisons de fichiers dans des format structurés multiples, requêtes HTTP, ...).
Donc je veux les mettre dans des scripts externes que le makefile invoquerait.
Je me demande comment les gens qui utilisent couramment make organisent ce genre de situations.
Donc je pose cette dernière question ici,

'k donc si je lis bien ça, les que make va invoquer iraient probablement dans tools/, et probablement un script par tâche de haut niveau?

Je me demandais plus genre comment tu fais des trucs relativement au makefile. -C va changer le PWD en premier et ça va finir dans CURDIR, mais genre quand t'as des makes récursif ou quoi (-f?), comment tu trouves des trucs relatifs au makefile actuel?

 
Les make récursifs c'est satan Tu peux passer des variables d'un make à l'autre ( https://www.gnu.org/software/make/m [...] fRecursion ) mais je suis loin d'être expert là-dedans c'est pas ma techno préférée on va dire

Ouais je compte pas faire des make récursifs, je me pose plus la question du setup de l’environnement d’exécution et des différents chemins, genre est-ce que CURDIR est nécessairement le chemin du makefile racine ou bien est-ce que c’est juste le PWD au moment de l’invocation, que généralement tu `make -C somedir` donc ton PWD est bon mais c’est pas nécessairement le cas?

Merci à tous pour les différentes réponses.
 
@___alt & Hermes le Messager : Sur la théorie je suis d'accord avec vous, j'aime aussi quand le code est bien structuré, avec une belle séparation des concepts et de pas devoir scroll à travers des méthodes de 600 lignes.
Le problème étant (et plus le temps passe, plus je suis convaincu de ça), que je trouve qu'en pratique c'est très compliqué d'arriver à ce résultat.  
HLM, tu donnes notamment l'exemple des libs 3rd party qu'on passe notre temps à appeler, mais justement, la majorité de ces libs sont bien souvent passées par de nombreuses versions (majeures ou mineurs), avec parfois des changements d'interfaces importants, alors même que leurs concepteurs sont régulièrement des gens plutôt brillants. Si même eux n'y arrivent pas du premier coup, quel est la chance que "tu" y arrives ? Et on a tous eu je pense aussi à utiliser des libs avec des interfaces pourries, donc des fois c'est même pas sur que la solution soit trouvée
Sachant que ces libs sont souvent open source, avec peu de contraintes de temps/rentabilité, ce qui laisse toute latitude pour expérimenter, refactorer etc... Combien d'entreprises peuvent se permettre ça pour arriver à ce niveau de "perfection" dans leur code 'maison" ?
 
 
@masklinn : Thanks pour la référence pour Chandler, avoir un peu d'éléments de biblio peut m'aider à faire comprendre que c'est pas qu'une lubie personnelle. J'étais aussi tombé sur un papier sur les "leaky abstraction" que j'avais bien aimé.
 
@ratibus : Y en a un qui est junior, mais l'autre a bientôt 10 ans d'XP, du coup c'est pour ça que je voulais quand même me remettre un peu en question là dessus (n'aimant moi même pas trop les arguments d'autorité).
Et les discussions sur les TU, je pourrai en faire un pavé aussi (avec le même dev )
 
 
Pour le fait de factoriser trop tôt/du couplage/DRY tout ça, j'aime assez la comparaison avec les points et la droite (je me demande si c'est pas sur ce topic que je l'avais vu d'ailleurs y a fort longtemps): si t'as qu'un seul point (use case), tu peux trouver une infinité de droites (de fonctions) qui passent par ce point. Avec deux points, t'as qu'une seule droite possible... Mais t'es quand même assuré d'en trouver une... Sans garantie qu'un 3ème point soit couvert par la même droite (et a fortiori d'autres). Bon l'analogie marche surtout avec ceux qui ont un profil un peu matheux. Mais du coup c'est pour ça que j'ai tendance à leur dire d'attendre que la 3ème occurrence se pointe avant de se lancer dans du gros boulot de factorisation.

 
À vérifier mais je crois que make -C set la variable CURDIR mais ton current working directory lui ne change jamais même dans les make récursifs. Ya une option qui print les directories, bien pratique pour débugger.

Ils sont jeunes et naïfs, mais je ne pense pas qu'il faille se battre sur la question des principes, à moins que l'un d'eux ait pour ambition de faire de l'une de ces règles une obligation, ce qui serait complètement con.

Tout ce que tu peux faire à mon avis, c'est argumenter sur des cas concrets, et expliquer pourquoi tu penses qu'ici et là il vaut mieux garder une approche un peu moins stricte.

Par contre tu mentionnes en particulier deux trucs qui sont à mon avis bien différents : refactorer un bloc de code en une fonction pour en documenter la signification, c'est toujours bien quand c'est bien fait, par contre oui c'est un effort et on peut facilement se tirer une balle dans le pied en le faisant ; en revanche, sortir des trucs dans une librairie et partager le code, c'est bien plus lourd de conséquences et ça se discute toujours (cf les adeptes de go, un peu de duplication c'est mieux qu'un peu de dépendance).

 
Après je note quand même un truc dans l’originel: mettre des facades sur toutes les libs tierces c’est pas nécessairement une mauvaise idée. Mais ça peut être couteux, et si c’est pour répliquer l’api d’en dessous ça vaut pas trop le coup, faut vraiment t’en isoler.

Isoler les libs tierces qui sont facilement interchangeables je suis assez d'accord, les trucs fondamentaux, j'avoue être plus dubitatif... Surtout si c'est pour (mal) reproduire les fonctions de la lib/framework. Exemple concret que j'ai fais sauter par exemple. On a une app Flask qui utilise SQL Alchemy comme ORM (bref du archi classique dans le monde Python), et ils avaient fait pour tous les modèles une méthode "find". Sauf que dans 95% des cas, elles ressemblaient à ça :
 

Et forcément, en dehors du cas du filtrage par PK/ID qui revient souvent dans le code, la plupart de chaque paramètres n'était utilisé qu'une seule fois dans le reste de la code base... Et comme parfois l'opérateur de comparaison ne convenait pas, bin t'as des variantes, genre `name="toto"` fais un match exact, mais si tu veux avoir tous les objets qui commencent par toto, bin t'as le paramètre `name__starts=toto`. Avec bien sur aucune cohérence entre les "find" des différents modèles sur le naming des paramètres, etc... Et je poursuis même pas sur les subtilités quand tu veux controler l'ordering, avoir directement les objets ou renvoyer la query, etc.. Bref... /rant off

Mais t'as toujours une infinité de courbes

 
Y'a pas mal de projets qui utilisent des wrappers pour les outils de build, genre Gradle Wrapper our Maven Wrapper.
Je ne sais pas s'il y a un équivalent à make (mais si c'est le cas, bon courage avec des recherches de type "make wrapper" ).

Nan mais je préfère me dire que j'ai mal compris, parce que je suis souvent du côté des jeunes cons dans la discussion...

Ben à peu près comme tu dis.
Je n'utilise pas couramment make, en fait je l'utilise le moins possible. Je préfère un build tool qui utilise un vrai langage de script.
J'ai un répertoire bin ou tools à la racine du projet, je fous les scripts dedans. make (ou autre) les invoque. Il n'y a qu'un makefile qui est à la racine, et ne fait que le minimum à savoir appeler les scripts, tout le reste est géré dans les scripts.

Pour les chemins, je n'utilise que des chemins relatifs à la racine du projet, donc une seule variable $PROJECTROOT et tous les autres chemins sont des ${PROJECTROOT}/mon/chemin/relatif.
Cela veut dire que tes scripts ne font pas de cd, pwd et autre. Cela évite que tes scripts ne pètent dès que tu déplaces un répertoire.
Après, où tu colles ton répertoire projet, c'est toi qui vois.

Vous avez des bonnes ressources pour apprendre le Go ?

T’es un vieux qui essaie de se faire passer pour un jeune en fait, un peu comme ceux qui s’achètent un roadster

Pas le faire  

Perso pour mes trucs perso j'utilise babashka qui a un équivalent de make avec bb tasks.
 
J'ai pas mal de scripts babashka pour automatiser mes trucs à la cogip
 
Pour Go j'avais appris sur le tas j'ai jamais lu de livre donc rien de spécial à conseiller, voir les best seller cher O'Reilly et Praprog

Moi je suis d'accord mais ma nouvelle équipe a du code en go

Alors barre toi tant qu'il est encore temps

T'façon le langage a été conçu pour qu'un freshie tout juste sorti d'unif puisse commencer à pisser du code dans la journée, donc tu fais le Tour of Go, et éventuellement tu te prendras toutes les portes genre typed nils, les slices qui partagent un buffer, les boucles mal scopées, tout ça, mais c'est tout des super feature qu'on me dit.

Une resource externe qui peut te servir c'est slice tricks, quand github sera plus cassé, parce-que réinventer comment supprimer un élément d'une slice est assez chiant sinon.

Maiwai  

Perso, pour tout ce qui est automatisable ici, c'est python. Les langages de Satan ou qui datent de mon grand père, c'est non  

@Harko, rdv technicien fibre Orange planifié pour le 24 février (2022 ) ça sent bon !

J'ai lu trop vite ton message et le précédent, j'ai cru que c'était Harko qui postait

Leave harko alone  

 
pourtant tu devrais savoir, si ça parle d'accès à des vitesses d'internet normales, ça peut pas etre Harko

WTF mon wifi sur mes 3 PC tourne à 50mb/s ce soir, genre je suis en Wifi 2.4ghz.  
Alors que le routeur m'indique que je suis en 5ghz...
 
Netgear Orbi ne m'a jamais fait faut bond, mais là ça déconne sévère.  
Je vais redémarrer tout ça ce soir.

Le gosse qui DL tout son porn

Figure 1, le boomer qui "DL" des trucs pour le sauver sur son disque dur
 
En 2022 tout se streame mon bon monsieur

Haut cinq !  

Un avis sur le Go du coup ? Python je sais qu'on en dit du bien, perl je sais que ça meurt, ruby je sais que c'est surtout tenu par rails, mais Go... j'ai ni avis ni retour je suis curieux tiens

On parle du gosse de Gatsu. il a internet seulement de 20h05 à 20h08 un dimanche sur 3.

Gatsu vend un abonnement à sa femme pour que le beau fils puisse streamer depuis sa cage sur le balcon, jusqu’à dix heures par semaine

 
Plus ça va et plus j'aime python. Vu à quel point ce langage devient universel, je pense que c'est vraiment un langage à connaître et à maîtriser.  
 
Ah oui d'ailleurs une question. Quand on reprend en main une équipe qui bosse avec Perl (web) et on sait qu'on va devoir changer de techno pour la version suivante du projet, quel est le langage qui vous semble le plus naturel pour transitionner ?

je sais pas si je vous ai dit, mais junior devrait sortir jeudi/vendredi prochain de l'hopital
il y a encore une anesthesie à risque mardi pour mesurer la tension pulmonaire, et faire un prélévement de foie, mais ensuite ça devrait rouler

Il pourra même retourner à l'école à la rentrée. Par contre il devra probablement changer de sport, les sport cardio risquent très fortement de lui être interdit

 
Ruby doit etre le language mainstream le plus inspiré de Perl je pense (c'est pas forcement positif...)

Argument d'autorité mais ça m'avait bien fait marrer à l'époque: https://news.ycombinator.com/item?id=13485953