Reprise du message précédent :

 
 
Ah ouais du coup c'est sur que c'est mort pour toi. Désolé.

ben disons que ma tranquillité d'esprit en a pris un coup, sans pour autant imaginer le pire

J'ai eu la même chose quand j'ai vu un mec sur twitter qui connait le pote d'un oncle qui est mort du vaccin.

du coup oui je vais avoir une 1080Ti à vendre

Tu pouvais t'arrêter la

et est-ce qu'avec vos cartes graphiques qui consomment autant qu'un chauffage de studio vous arrivez à faire calculer des congés de raccordement corrects à Fusion360 ?

Avis aux intéressés:
https://www.ghi.ch/une-genevoise-ve [...] -de-francs

haha

 
Attends on n'est pas des rigolos ici. Et encore t'as pas vu nos robinets.
 

 
J'ai mesuré la consommation avec HWInfo, tu peux aussi le faire avec GPU-Z (mais utilise une version récente de GPU-Z, une vieille version avec une carte récente ça crashe le PC)

Je suis curieux du profil de l'auteur du 1er message. Dev*Scrum Master*LinkedIn influenceur ?

Pourquoi c’est un anti-pattern?
 
C’est du Java ? La string pourrait aller directement dans l’enum.

C'est pas moi le premier message. Je n'utilise pas ce genre de vocabulaire à la con.
 
Il n'y a pas d'Enum
 
Proposer de faire un switch pour setter une valeur et la retourner à la fin, c'est aussi con comme proposition : en l'occurence le switch en lui même est très con.
 
Mais bon, ce dev (que je connais pas encore) est pas mûr... il a écrit plus loin en réponse à "ces listes de codes métier mériteraient d'être soit en base soit sous forme d'Enum", il répond :  
 
"ouais àa serait plus clair mais à un endroit j'ai besoin de strings alors c'est plus facile comme ça"

La partie vraiment excellente c’est le Strings.EMPTY à la fin, parce que clairement il te faut une constante nommée pour ça

C'est dans le JDK (et dans la plupart des libs de manipulation de Strings).

Je pense que ça a strictement aucun impact sur ce que fait le compilo, mais bon.

C’est pas String.EMPTY ?

Classement 2021 de la popularité des différents langages.

IEEE Spectrum (analyse de CareerBuilder, GitHub, Google, Hacker News, the IEEE, Reddit, Stack Overflow etTwitter) .
https://spectrum.ieee.org/top-progr [...] /100/1/50/
 
Un autre, le TIOBE Index, avec une méthodologie différente mais des résultats plutôt similaires (au moins pour les premiers rangs)
https://www.tiobe.com/tiobe-index/

 
oui, probablement, j'ai pas fait gaffe.
 
Après c'est du vieux code, la gestion de dépendance est une cata comme j'en ai rarement vu, il doit y avoir au moins 3 librairies d'utils dans le projet, et ça démarre en ~1 minute pour le portail à vide.
 
Tu peux ajouter a minima 30 secondes par service que tu ajoute, c'est merveilleux.
 
(et certains "services", c'est une pauvre JSP avec 3 trucs derrière, hein)

Vu shang chi et la légende des 10 anneaux, j'ai adoré

Pour moi, A est un trou du cul, c'est pas un problème architecturel donc si t'es pas d'accord tu proposes ton alternative et t'expliques pourquoi, et le "faut pas faire des return dans un switch" ça sent les saletés genre MISRA.

B s'il connait pas bien les enums Java c'est excusable, le switch + return c'est probablement la seconde option (ou la 3e si on considère que la première est un newtype), et si on lui dit de pas faire switch + return, bah switch + set c'est le moins pire mais c'est de la merde. Si quelqu'un propose une hashmap en java pour cette situation il prend deux claques et il est envoyé au lit sans manger.

C'est pas dans le JDK et c'est juste plus long pour rien, Strings.EMPTY ça te dit strictement rien de plus que "". C'est comme les THREE = 3, sauf que comme ça vient d'une classe utilitaire tu peux pas le changer, ça pêterait tout.

J’ai l’impression que String.EMPTY n’existe pas, Strings est peut-être une classe maison

 
C'est quoi cette remarque digne des années 90 ?

Y a pas de Strings dans le JDK et encore moins de constante EMPTY.

Les strings sont internées donc oui tu peux supposer que toutes les constantes et littérales pointeront vers la même chaîne vide.

 
A est le lead dev du projet. Il est vraiment bon et plutôt très apprécié de ses équipes. Là il est probablement allé un peu vite, mais il a proposé un atelier refacto demain.
 
Je soupçonne que B est un dev a qui on a déjà répété les mêmes trucs 100 fois mais qui comprend pas ou s'en branle (je les connais pas tous, chez ce client on a des logins anonymisés, et les 2 lettres distinctives n'ont rien à voir avec les initiales ou autre )

(maintenant il sera l'autre lead dev : je les rejoins sur le même genre de rôle : il y a entre 25 devs sur le périmètre et ça va grossir)

Je me demande quel pourrait être l'use case métier d'un code vide, ça attise ma curiosité  

C'est souvent plus simple à gérer que se retrouver avec des null qui trainent.
 
Idéalement t'auras plutôt pas la possibilité d'avoir un code d'entrée invalide (genre une enum, mais pas une enum C), mais parfois c'est pas une option parce que tu interagis avec un sytème qui peut évoluer de manière asynchrone (ou alors tu connais pas bien les enums du langages) (ou alors parce-que le langage a pas d'enums mais c'est pas le cas ici).

 
Ah oui.
 

 
+1
 
Perso j'aime pas faire grossir inutilement mes livrables et gérer des dépendances pour 2 méthodes (isBlank et isEmpty, en gros)
 
Donc pour des trucs cons comme ça je les réimplémente souvent dans une classe utilitaire.
 
Ca fait à peine plus de code que la déclaration d'une dépendance

isEmtpy est standard (mais est une méthode d’instance donc gère pas les nulls, ce que tu peux vouloir).

Et du coup, pour les gens qui n'ont plus fait de Java depuis leurs études (du coup... plus de 15 ans ), c'est quoi la bonne façon de faire quand tu veux mapper une valeur vers un entier ? Si on suppose que les entiers en questions ne sont pas les même que les éventuelles valeurs si on avait une Enum.

Switch est une expression depuis Java 12 mais une enum peut très bien avoir des propriétés.
 
Mais en fait je comprends rien à la remarque initiale ni à l'alternative proposée.

Et les exceptions ?
Je suis pas très fan des cas à la marge "des fois que".
Soit c'est dans le scope soit ça ne l'est pas '

Je ne comprend pas non plus, ce commentaire sur le refactoring c'est de la merde.

Une COGIP en java 12?

La remarque initiale c'est "switch + return s'pas bien". L'alternative proposée c'est

String result;
switch (machin) {
    case BLAH:
        result = "BLAH";
        break;
    […]
}
return result;

Si tu veux éviter les NPE c'est généralement pas pour mettre des erreurs pas contrôlée au même endroit.

Je sais pas si t'as remarqué mais le scope on le connait pas, je propose des explication / justifications possibles

Bon sinon petite question, j'ai retrouvé mon vieux macbook blanc et j'ai sorti le disque dur, branché en SATA to USB sur mon PC et sur mon Mac, j'arrive pas a explorer dedans.
Je pense que j'ai pas mal de pépites de mes années universitaires dessus ...

Quand je le branche sur le Mac il apparait bien dans /dev/disk2 (s1 - s3), mais j'arrive pas à le monter en type hfs, donc peut-être que c'est du HFS+ je ne sais pas, en tout cas mon mac ne sait pas le monter "mount - t hfsplus" ou "mount -t hfs_plus" ne fonctionne pas.
J'ai tenté avec le logiciel HFS Explorer, il voit bien un disque mais comme il est de type Unknown il veut pas tenter de le monter en HFS/HFS+/whatever.

Y'a pas un logiciel comme dans NCIS là, je plug le disk, il trouve tout seul tout comme un grand et je peux faire mes extracts (même payant) ?

String result;
switch (machin) {
    case BLAH:
        result = "BLAH";
        break;
    […]
}
return result;

L'alternative est encore plus laide, on croirait voir des profs d'algos qui t'empêchent de faire un early return/break

un livecd gparted ?
 
edit : et pour les partoches perdues, TestDisk sur UBCD

Je vais tenter ça