Reprise du message précédent :
ha oui j'avais même pas vu que c'était le taulier !

Bonjour ici,
 
Petit !

.Net Core 1.1 RTM out
https://blogs.msdn.microsoft.com/do [...] -core-1-1/
Ca a l'air pas mal, surtout l'EF Core 1.1 : https://blogs.msdn.microsoft.com/do [...] -core-1-1/
 
Du coup petit sondage... Qui utilise .Net Core ?

Bien trop récent pour le client chez qui je suis.  
Ils viennent de 'valider' le 4.5.2 là ...

C'est déjà pas mal, je suis sous VS2010 moi ...
 
Je posais plus la question pour ceux qui font de la veille, en prod je pense que ça doit être rarissime de trouver du Core. Suffit de voir la change list entre 1.0 et 1.1, comme ils disent : "hundreds of bug fixes". C'est pas super encourageant si tu cherches un truc ultra fiable.

.Net 4.0 / MVC 3 sur la majorité de nos projets, mais j'ai switché tout le monde sur VS2015 cet été.
J'ai n'ai pas eu le temps d'expérimenter .Net Core, ni même de vraiment me renseigner dessus  

Puisque on parle de nouveautés, petit récap des fonctionnalités syntaxiques de C# 7 :
http://tlevesque.developpez.com/tu [...] -csharp-7/
Pas mal de petites choses, mais aucune grosse : il n'y a rien de révolutionnaire (du moins à mon sens).
C# 6 était passé presque inaperçu et le 7 ne pas sans doute pas faire plus de bruit...

Pour moi, C# 6 = propagation de null (le "?." pour ceux qui suivent pas) et C# 7 = tuples natifs en retours de méthodes (retourner plusieurs valeurs). Deux "petites" choses qui permettent de faciliter l'écriture et la lecture de nombreux algos !
Sinon je trouve que certaines nouveautés restent très intéressantes pour la lisibilité du code :
- pouvoir faire un switch sur le type d'un objet (c'est pas trop tôt !)
- pouvoir déclarer une variable 'out' à son utilisation
- le côté convertible des throw (pratique dans des ternaires ou couplé à l'opérateur '??')

Ch'ais pas, perso les ?? et les ?. c'est pas ce que j'appelerais une amélioration quant à la lisibilité du code
Et le switch sur le type, chu pas sûr non plus que ça favorise les bonnes pratiques (= utilisation du polymorphisme plutôt que des méthodes fourre-tout).
Les Tuples je trouve ça con aussi, quitte à retourner plusieurs trucs, autant faire un objet avec un nom parlant. Quand je vois :

(sorti d'un article de la MSDN) mais bordel ça me fait chialer des larmes de sang En quoi c'est mal d'utiliser un objet "Name", bon dieu ?
 
Pour moi, si ce genre de truc se généralise, ça va faire du code encore moins lisible. A croire que les mecs ont pas lu Clean Code de Robert Martin.
Enfin bon on verra bien.

Implosion > je ne dis pas que ça ne sert à rien et qu'il ne faut pas les utiliser, juste que c'est pas LA super fonctionnalité qui fait rêver tous les pisseurs de code et justifie de migrer ASAP parce que tu vas l'utiliser tous les jours comme les expressions lambdas.
Apres on est d'accord qu'en général les opportunités de migration viennent plus des évolutions de la BCL et des trucs haut niveau du FW comme MVC, l'EF, les trucs graphiques...
 
Taiche > sur la lisibilité je me fais souvent le même genre de remarque, surtout quand tu combines tous ces trucs là ensemble, ça devient assez bordélique. Et comme ça passe par des syntaxes tordues à coups de signes de ponctuation combinés plutôt que des mots clés, ça ne facilite pas la recherche d'infos sur le web.  
Même sur SO on ne peut plus chercher avec des signes de ponctuation, une honte
 
Ca rend des services mais c'est à utiliser avec parcimonie.
 
Genre les tuples, c'est le genre de trucs que je me vois bien utiliser dans Linqpad ou pour un proto, mais pas dans du code où je prévois d'appuyer à un moment ou à un autre sur le bouton Commit

Moi ça me gonfle les Tuples à mon niveau, je préfère de loin utiliser une classe métier ou même un dictionnaire que je trouve bien plus flexibles et lisibles que Item1 & Item2 ...

On est d'accord. Le dictionnaire (ou lookup) c'est pas la même chose cela dit.
 
Malgré mes réserves les "tuples nommés" de C# 7 (faut bien leur filer un nom à ces zèbres), ça peut être utile, un peu à la croisée des chemins entre tuples, types anonymes, et class/struct...

 
Classe métier, ok, mais parfois c'est too much pour une fonction...
 
le dictionnaire pour ça me fait saigner des yeux par contre.
 
 
Quand je vois en C#7 :
 

 
et qu'on utilise la fonction ainsi :
 

 
avec accès au tuple par des variables nommées (count & sum en l’occurrence), je trouve ça plutôt sympa
 
Après, comme indiqué plus haut, le risque c'est d'en voir utiliser à toutes les sauces et particulièrement dans des cas où une classe métier serait nécessaire... Mais à chaque itération de C#, c'est toujours pareil  

Effectivement, là, c'est plutôt sexy oui
Ca doit très certainement implémenter une structure derrière au runtime non ? Un Tuple c'est pas limité à 2 valeurs ?
 
Là, ça colle, mais quid de  
 

 
Par exemple ?

 
Non, le tuple est "multiple", tel qu'utilisé aujourd'hui sous forme d'addon :  
 
https://www.nuget.org/packages/System.ValueTuple/
 
l'intégration directe dans le langage, sans classe le rends plus sexy oui.
 
Après, au delà d'un certain nombre de retour (arbitrairement, je dirais 3), il faut se pencher sérieusement sur une classe métier comme même

C'est pas qu'une question de nombre, mais aussi de types. Les Tuple de dictionnaires de collections de machins ça peut être abominable même avec juste deux valeurs par exemple.
Sachant que le type Tuple permet jusque 8 valeurs et qu'on peut faire des tuple de tuples je pense qu'il y a de quoi faire des trucs assez marrants

Des arbres de tuples  

Merci bien  
 
Tupleception

Tout peut être abominable quand mal utilisé, certaines lambda illisibles inclus ! Le nombre de fois où j'ai utilisé des objets fourre-tout qui n'avais pas d'utilité fonctionnel autre que pour logguer / avoir des résultats de calcul intermédiaires...

vs

Mon choix est vite fait

De même que coder des trucs comme ça, j'attends depuis longtemps et c'est très lisible :

et

qui évite de nombreux tests..

Le switch sur les type quand tu bosses avec de nombreux objets mathématiques (principalement des formes bien typiques), c'est excellent je trouve et nullement incompatible avec le polymorphisme. Je pense à des cas de sélection dynamique d'algo à appliquer (=optimisation de temps de traitement ou de précision de résultat), ou ajustement de paramètres en fonction du type d'objet mathématique que l'on manipule

Ba honnêtement, si ton choix c'est le premier, je suis pas du tout d'accord. Pour moi, le plus lisible c'est celui qui se lit le plus naturellement possible ("comme un journal" ), donc le second.

Je vois pas en quoi ça évite des tests, puisqu'au lieu de tester si Parent ou Enfant est null, tu testes la valeur de retour. Or, si myFinalValue est null, tu ne sais pas si c'est à cause de Parent ou Enfant, donc tu perds en granularité.
Sans parler du ?. qui peut ne pas être connu quand on embarque un novice dans l'équipe (ou tout simplement quelqu'un qui ne connaît pas la notation).
 
Après c'est des choix d'équipe, tant que tout le monde est d'accord ba tant mieux, mais je trouve que ça augmente la courbe d'apprentissage du code pour un gain discutable.

je trouve ça très lisible : <<on prend la valeur de "myConf" sinon "default">>
tu serais pas du genre à pas aimer les ternaires toi ? au final, c'est une simplification du :

(utilisation très moche de l'opérateur ternaire )

Ton novice ne va pas forcément maîtriser les lambda non plus, où le framework machin-chose que vous utilisez, c'est un faux prétexte.
L'utilisation du ?. les cas sont nombreux. Ne pas avoir une valeur peut parfois ne pas être une erreur et on peut se moquer totalement de savoir à quel moment la chaîne est rompue. C'est juste que si au bout de la chaîne on trouve notre valeur, on l'utilise pour la suite, sinon on l'utilisera pas, sans avoir à tester chaque élement

Les ternaires c'est pareil, c'est moins naturel et le gain est plus que minime (y en a-t-il un d'ailleurs ?). C'est comme tout, avec de l'habitude ça se pige vite mais ça ajoute à la courbe d'apprentissage pour rien.

Non justement, ça se rajoute [b]en plus[b] du framework ou de la lambda. Là où ton framework ou la lambda peuvent apporter quelque chose de fonctionnel, les opérateurs type ternaire ou coalesce brouillent la lisibilité naturelle pour ne rien gagner fonctionnellement.

Sans entrer dans le débat "null c'est pourri", je préfère au contraire tester ce qui est filé en entrée avant de l'utiliser, même si on n'est pas dans un cas exceptionnel. Histoire de savoir d'entrée dans quelle branche de code passer.
 
Bref, histoire de goût et de choix d'équipe comme je disais plus haut, mais peros spa du tout mon truc

(Note juste que le ternaire existe depuis très très longtemps)
 
Perso je trouve que trop de test est inutile, et il est courant de ne pas avoir le temps. Surtout quand on est sur des algos dont on se moque de savoir quel élément de la chaîne est manquant. Niveau perf, c'est du pareil au même, uniquement du sucre syntaxique.
 
C'est juste que dire "c'est pas lisible" ça me fait rire et juste pensé au mec du bureau du fond qui refuse tout changement, toujours à coder en Delphi 4

Donc utiliser le ternaire qui existe depuis très très longtemps c'est progressiste ?
"C'est pas lisible" c'est au contraire aller dans le sens de la programmation "fluent", des langages qui ne sont pas des instructions incompréhensibles comme l'assembleur qui, lui aussi, existe aussi depuis très très longtemps Et c'est pas parce que ça existe depuis longtemps que c'est une bonne façon de faire, surtout dans un domaine comme l'informatique.
On a justement les moyens maintenant que ça ne coûte pas plus cher d'écrire de façon naturelle et compréhensible par tout un chacun plutôt que d'obscurs signes cabalistiques. Le meilleur test c'est de de montrer le code à quelqu'un côté utilisateur ou MOA, quelqu'un de pas du tout versé dans la prog. S'il comprend ce que fait le code, alors t'as gagné parce que tu as restranscrit le plus fidèlement possible la pensée et les règles métier.

T'es sérieux avec le coup de "on a pas le temps pour les tests" ? Alors qu'on passe les 3/4 de notre temps à lire du code plutôt que d'en écrire ? TDD, la pyramide des tests, tout ça, pour toi c'est de la connerie ? Je remets la ref à un bouquin qui explique très bien les problématiques de nommage, de tests, etc... : https://www.amazon.fr/Clean-Code-Ha [...] 967&sr=8-1 Probablement la meilleure dépense qu'un dev puisse faire dans sa carrière.
 
J'arrête sur le sujet, parce que quand on en arrive à "ouais t'es un vilain bougon anti-changement", c'est que ça va pas aller beaucoup plus loin dans les arguments constructifs.

Surtout pas malheureux, si l'utilisateur comprend ce que fait le code il risque de trouver ça facile et tu ne pourras plus facturer 4000 brouzoufs par jour

Tu dois aimer les langages verbeux non ?
Je te trouve un peu extrême dans tes positions, moi les ternaires, le ??, etc je m'en sers assez souvent et je trouve que ça se lit aussi naturellement qu'un if avec l'habitude, et plus vite en plus. J'aime bien les syntaxes concises pourvu qu'elles restent expressives, du coup j'aime moins la ponctuation dans tous les sens.

Apres le rapport que t'as avec les tests dépend fortement de ton secteur d'activité, si tu lances des machins dans l'espace tu vas être plus rigoureux que si tu bosses sur la 57e release annuelle du site e-commerce de ton client qui vend des moufles. Je crois qu'il vaudrait mieux limiter votre débat passionné à la syntaxe du code, si on commence à parler philosophie tests en même temps la conversation va être ingérable

edit : attention je ne dis pas que Implosion du Sord ou moi on a une vision plus pertinente, c'est beaucoup une affaire de goût et chaque position se défend.

Ca dépend ce qu'on appelle "langage verbeux". J'aime bien C# et Java et on peut tout à fait écrire du code qui se lit très bien via des API fluent. Exemple : http://n-fluent.net/
Le dev, c'est transformer un besoin en langage machine. Quand t'arrives à rapprocher les 2 au maximum, tu gagnes sur tous les tableaux : tes tests sont des scénarios métier, ton code est la doc lisible par un expert métier, etc...
Bien sûr, il va y avoir des algorithmes complexes et des couches techniques qui dépassent le besoin métier, mais pas besoin de les crypter avec des signes de ponctuation, des termes qui ne veulent rien dire ("AbstractDataManager" ) ou des abréviations (les IDE font très bien l'auto-completion).

La partie en gras est ce qui me pose problème. Prendre l'habitude a un coût alors qu'il n'y a pas de gain derrière et, surtout, pas de réel besoin. Pourquoi ne pas parler naturellement ? Dans tous les cas, perso j'ai l'habitude de voir les opérateurs ternaires, mais je ne trouve pas ça plus rapide à lire. Et là on retombe dans ce que je disais avant et que tu dis à la fin : c'est un choix d'équipe.
(on passe effectivement sur la partie tests)

Alors non on n'est pas dans ce que j'appelle les langages verbeux ou pas clairs. Genre le VB qui est pour moi un dégueulis de mots clés et de nom de variables/méthodes sans séparation et sans rien pour dire qu'est ce qui est quoi. J'ai une horreur profonde du VB.Net, pourtant j'ai fait beaucoup de VB6 lorsque j'étais jeune et innocent.

Attends, lire une ternaire c'est quand même pas si compliqué .
Je trouve

carrément plus efficace que :

Pareil pour le ?? (et partiellement le ?. à condition de ne pas forcer dessus).
Y a quand même bien pire que les ternaires pour faire du code illisible.

Les API fluent ça me plait bien aussi, mais ÇA ça nécessite de l'habitude et de la pratique par exemple

Apres ça fait pas mal de temps que je code juste pour moi (freelance consultant en entreprise, très souvent autonome sur ses projets) donc j'ai peut être fini par développer des pratiques atypiques . Ex : j'ai tendance à faire des noms de méthodes assez longs pour être explicites et ça m'énerve qu'on me dise "c'est trop long à taper ou à retenir" je considère que l'auto completion est là pour ça.

Je dis pas que c'est le pire, juste que je trouve ça moins naturel et que ça demande un effort aux personnes qui ne sont pas habituées et pour un gain minime ou nul. Et perso je trouve ça moins efficace, faut que je revienne en arrière pour piger quel test on fait et ce qui est assigné à qui Ca le fait moins si le test a un nom de condition genre isTruc ou mieux un nom de méthode IsTruc() mais si c'est un booléen ou, pire, une évaluation genre youpi.ToUpperCase() == "YOUPI", ba c'est la fin du monde et je préfère 100 fois un if.

A développer oui (et encore, faut faire du return this à la fin des méthodes qui s'enchaînent, spa la mort) mais à écrire ou lire ba non. Justement, NFluent est une lib pour te permettre de lire plus facilement ce que fait un test. Exemple tiré du site :

C'est ultra-simple à lire, tu peux le donner à n'importe qui dans la rue, il ou elle saura te dire ce que ça fait.

On est d'accord (après des fois, un nom trop long peut vouloir dire que la méthode fait trop de choses ou que son utilité est mal définie, mais je préfère ça que Compute() )

PERFORM !  

Les ternaires, c'est quand même devenu une construction de programmation classique maintenant. Y'en a encore qui peuvent avoir du mal avec ?

moi c'est richard Pear qui me les propose quand j'y pense pas

Ah putain j'ai mis 5min à comprendre

Tu vois pas une nuance entre ma phrase "trop de test est inutile" et ton interprétation en "on a pas le temps pour les tests" ? En effet autant ne pas continuer a débattre dans ce cas.

A te lire il serait aussi plus "naturel" d'écrire :

Non sur cet exemple je n'utiliserais pas plus l'opérateur ternaire Par contre je savais le lire bien avant mes premiers cours de programmations. J'ai du mal à croire que cela pose problème à une personne payée et devant lire du code.

Alors va jusqu'au bout de ta logique : utilise seulement de noms en français parce que n'importe qui dans la rue ne sait pas lire l'anglais.

Bizarre de tolérer les incompétents en lecture de code de base mais pas en lecture d'anglais de base.

Le fait d'être payé ou non n'influe en rien sur ce sujet. Ou alors c'est pareil dans l'autre sens : j'ai du mal à croire qu'une personne payée pour écrire du code n'essaie pas de le rendre plus parlant.

L'anglais est de mise dans la programmation pour 2 raisons principales : les équipes internationales (ou se voulant comme telles) et le fait que de toute façon les mots-clés ainsi que la syntaxe de base de beaucoup de langages sont en anglais. If, then, while... marquer "if(maConditionEstVraie) then { faisCeci(); } " c'est du franglais et ça fait chier tout le monde, comme les noms de méthodes en "SetMontant()" ou "CalculePrixDuBasket()" qu'on trouve des fois.
Enfin, ce n'est pas "ma" logique et je trouve un peu rapide ta conclusion de ce que je tolère ou pas. Je le remets une dernière fois après j'arrête sur le sujet parce que j'ai pas super envie de passer 3 semaines sur un débat sur la lisibilité de l'opérateur ternaire : https://www.amazon.fr/Clean-Code-Ha [...] 967&sr=8-1 Moi aussi j'aimais bien les abréviations et les trucs un peu cryptiques avant, et puis finalement je me suis aperçu que ça ne servait à rien.

Je partage complétement ta vision Taiche.  
 
SirAnneau, quand tu parles de "payée et devant lire du code" cela ne veut rien dire, car cela dépend du code en question.
 
Selon sa durée de vie prévue, la taille et l'hétérogénéité de l'équipe, le fait qu'il soit de haut ou bas niveau, les performances attendues, la techno, tout cela influe sur la façon dont le code est ou devrait être écrit.
 
Les bugs arrivent lorsque le besoin est peu ou mal exprimé, ou qu'il change.
 
Pour reprendre, l'exemple d'Implosion, non seulement je choisirait la version 2 mais je le placerait probablement dans une méthode.
 
La configuration proviendra-t-elle toujours des AppSettings ?
La clé sera-t-elle toujours myConf ?
Ne souhaite(ra)-t-on pas logger lorsque la conf est nulle ?
Sera-t-il toujours possible de ne pas avoir de conf ?
=> Méthode dédiée ChargementConfiguration ( ) qui représente fonctionnellement le besoin

Pour AppSettings je trouve que c'était clairement un mauvais exemple parce que c'est le genre d'appel qui va à la fois servir souvent avec des clés variées et qui peut foirer pour 50 raisons différentes, donc ça va se retrouver dans une classe Helper qui va faire tout ce que tu dis, etc.  
 
C'est pour ça que j'avais ramené ça à un exemple super basique avec deux valeurs numériques en issues possibles, parce que l'intérêt des ternaires doit plutôt se juger sur ce genre de cas.

Merci tu ne m'apprends rien et je ne vois toujours pas concrètement où cela serait de mise mais pas de connaître la syntaxe de base d'un langage utilisé.
 

Idem. Sauf qu'on n'a pas la même notion du public visé. Pour ma part je pense que l'opérateur ternaire est plus concis et rapide à lire pour n'importe quel "animal" faisant de la programmation.
 
Toi t'as l'air de viser un public plus large... qui n'ait pas de grande notion en programmation : monsieur tout le monde. Sauf que ce n'est pas plus vrai puisque ce monsieur ne sait pas plus lire l'anglais.
 
Donc ta notion de "plus parlant" est tout autant imparfaite.
 
C'est toujours une histoire de compromis entre "facile à lire" par le profane et l'initié. Tu veux gagner 2% de profanes pour faire chier 98% d'initiés
 
N'empêche que je pense que ton bouquin ne pourra pas me faire de mal

Je répondais juste à ta question sur "pourquoi je veux pas aller jusqu'à coder en français".

Alors OK, j'ai parlé de "d'importe qui dans la rue", c'est trop large et ce n'est pas le cas. Ca m'est arrivé de pairer avec des MOA, autrement dit des gens qui ont une très bonne vision du métier et des règles à implémenter, mais qui ne connaissent rien en prog. Des gens qui parlent en anglais régulièrement de par la nature de leur taf et qui ont fait un minimum d'études. Donc dans ce genre de cas, écrire une expression en fluent ou avec du if/else c'est plus simple à lire et comprendre pour eux.
Ce pairing permet plusieurs choses, notamment de faire une implem qui corresponde en tout point au besoin métier ou de générer de la doc facilement lisible par un interlocuteur purement business (lors de ma dernière mission, mon PO était un gars qui connaissait rien au dev, ça l'empêchait pas de mater les dashboards des TU ou des scénarios SpecFlow tout simplement parce qu'on utilisait le bon nommage). Ca rejoint ce que je disais il y a plusieurs posts sur le rapprochement métier/technique ; notre but c'est pas de faire de la technique pour faire de la technique mais de répondre à un besoin métier. C'est là que je ne vois pas l'apport de syntaxe cryptiques puisqu'on s'éloigne du métier pour rien.
D'autre part, les profanes dont tu parles sont les interlocuteurs les plus importants puisque ce sont eux qui connaissent le vrai besoin et les règles correctes à implémenter. Il faut pouvoir toucher ces gens-là quand tu paires avec ou quand tu fais un debug parce qu'il y a un souci de règle mal appliquée en prod.

 
Du coup tu as fait quel choix?
 
J'ai toujours utilisé autofac de mon côté