Conditional Operators eller ej?

Man skal lige vænne sig til den nye syntaks, men det tager ikke lang tid.
Synes at den er meget pænere, kortere og mere effektiv hvor at den gamle fylder ufatteligt meget.
Førhen var jeg glad for "old-school" fordi jeg nemmere direkte kunne læse hvad der skete, men nu efter jeg har vænnet mig til det synes jeg at jeg kan strukturere min kode meget bedre så den ikke fylder så meget og man dermed nemmere kan få læst pointen af koden.

BTW. det med nestede if'er er jeg imod fordi det skaber for mange niveau'er og det kræver mere fokus at se hvad der sker. Så jeg ville flytte min if på niveau 2 op i første if og sige "&&" sammen med den fordi begge er betingelser skal opfyldes for at kunne komme ind til dit inderste niveau, uden at du skal lave mellemberegninger eller andet før du kan gå længere ind.
Derudover bruger jeg ofte modsatte if's der siger hvis det her ikke er opfyldt så break, og så udfører mere og mere kode dernedaf.
Sådan at du ikke har if/else indeni if/else og sådan dernedaf.
Så kan du strukturere din kode nemmere ved at lave

 int i = 2;
 if (i > 1)
 {
     if (i%2 == 0)
        break;
    
     MaxModel max = modelListe[i].Max;
     if (max == null)
        break;
 
     bool calculated = max.calc();
     if (!calculated)
         break;
 
     double maxBelob = max.belob;
     double maxBelobMoms = maxBelob * 1,25;
     return new { Max = maxBelob, MaxMedMoms = maxBelobMoms };
 }
 return new { Max = 0, MaxMedMoms = 0 };

Et lille eksempel for at vise hvordan du kan lave dine nestede if/else pænere og mere læsbare fremfor at have rigtigt mange if'er nestede under hinanden.

Samme eksempel med nestede if'er:

 int i = 2;
 if (i > 1)
 {
     if (i%2 != 0)
     {
         MaxModel max = modelListe[i].Max;
         if (max != null)
         {
             bool calculated = max.calc();
             if (calculated)
             {
                 double maxBelob = max.belob;
                 double maxBelobMoms = maxBelob * 1,25;
                 return new { Max = maxBelob, MaxMedMoms = maxBelobMoms };
             }
         }
     }
 }
 return new { Max = 0, MaxMedMoms = 0 };

Dog ved jeg ikke om dit eksempel kan løses direkte med en Conditional Operator fordi du har skiftende omstændigheder.

Min udgave af sin kode ville være:

 bool isZero = hoursStr.Equals("0,0") || hoursStr.Equals("0.0");
 
 if (isZero && createZero)
 {
    rn.AppendChild(n);
 }
 else
 {
    rn.AppendChild(n);
 }

Men giver det samme, og du kunne effektificere mere ved at gøre:

 (isZero && createZero) ? rn.AppendChild(n) : rn.AppendChild(n);

Men resultatet ser umiddelbart ud som om du laver det samme fordi din else alligevel appender.

Som jeg læser det, kan man ikke sidestille csharpers kode med Brians. I Brians kode vil der ikke ske noget i tilfældet hvor hoursStr.Equals("0,0") er true mens createZero er false. I csharpers kode vil kode efter kolon blive kørt i dette tilfælde.

Som jeg læser det, kan man ikke sidestille csharpers kode med Brians. I Brians kode vil der ikke ske noget i tilfældet hvor hoursStr.Equals("0,0") er true mens createZero er false. I csharpers kode vil kode efter kolon blive kørt i dette tilfælde.

Må give dig medhold. Jeg sad længe i går og prøvede at se, hvordan csharper kunne stille det op på den måde - og jeg kunne ikke forstå det.

Angående læsbarheden, så synes jeg absolut ikke at conditional operators hjælper til dette. Slet ikke i den brugsform der er vist her.

Dog bruger jeg det selv mere og mere, til at sætte variabler, f.eks:

 DateTime now = DateTime.Now;
 string hours = (now.Hours < 10) ? "0" + now.Hours : now.Hours;

Men læser jeg andres kode, så skal jeg ofte tænke over det en ekstra gang.

Husk det kommer altid i en kontekst og aldrig alene derfor mener jeg ikke man kan afgøre meget fra sådanne eksempler. Variabelnavne, funktion/metodenavne angiver hvad man har med at gøre. Her er 2 eksempler på a==b?c: (a>b?d:e):

 public static int ChooseValue(int a, int b, int ifEqual, int ifLarger, int ifSmaller) {
     if (a > b)
         return ifLarger;
     else if (a < b)
         return ifSmaller
     return ifEqual;
 }
 
 public static int ChooseValue(int a, int b, int ifEqual, int ifLarger, int ifSmaller) {
     return a == b ? ifEqual : (a < b ? ifSmaller : ifLarger); 
 }

Her ville jeg nok vælge den første, siden jeg forstår den med det samme, og vil aldrig bytte harddisk plads med en version jeg finder mindre forståeligt. Men jeg finder begge mere forståelige end den med enkelte tegn. Ligeledes foretrækker jeg også:

 int largest = Math.Max(x, y);

over

 int largest = x > y ? x : y;

medmindre det var performance-sensitivt kode (f.eks. inde i en løkke med mange iterationer) og jeg har målt at det er Max er langsomt.

Men hvis det nu var typer med hvor Max ikke virker for så kunne jeg godt finde på at gøre det sådan her:

 Molecule largest = moleculeA > moleculeB ? moleculeA : moleculeB;

Men hovedpointen er at konteksten bør afgøre om det læsbart. Hvis den er ikke triviel bør den pakkes ind i en metode hvis navn angiver hvad der sker eller hvor en variabel som den tildeles angiver.

Tak for jeres input. Jeg er ikke helt med på dit indlæg cSharper, da det ikke bidrager til min forståelse for at det gør læsbarheden nemmere :-) Men det kan lige så godt være mig der ikke er helt med.

Jeg bruger det også konsekvent til variabler som Nicky viser - det giver god mening og kan læses hvis det holdes i moderate udtryk. De kan stadig blive voldsom slemme, hvis man ikke passer på.

Jeg kan faktisk godt se nu efter at have set min egen kode at i den case kan du ikke gøre det, fordi den slet ikke tilgodeser muligheden for at der sker ingenting efter den første if.
Beklager!

Det med læsbarheden og mine eksempler var blot måden at strukturere sine if'er på.
Jeg synes det er meget mere læselige at have if (falsecondition) break, end en if og så noget arbejde, if og så noget arbejde, if og så slutresultatet.

Så netop din kode kunne ikke bruge conditional operators, men generelt synes jeg bedre om dem i min kode. Oftest er det dog i tekster jeg kan bruge dem eller simple operationer, men har heller ikke så tit nogle vildt lange if i flere niveauer.

Men som med alt andet så skal det gøres til de steder det passer ind, og ikke gøres ved meget komplicerede operationer og beregninger da selve det simple så nemt forsvinder. Så det skal være de steder det passer til for ellers kan det blive ret forvirrende hvis de er på flere linier og statements lige efter hinanden.

Ved simpel logik som ikke fylder meget er jeg stor tilhænger af conditional operators. Fx hvis en boolean skal oversættes til en tekststreng:

 string s = (myBoolean) ? "Ja" : "Nej";

Dog har jeg set eksempler på meget grim brug af denne operator. Fx hvis udtrykkene er så lange at det fylder flere linier, eller flere conditional operators indlejret i hinanden.

Med hensyn til spørgsmålet om at bruge breaks/returns frem for at neste i dybere niveauer er jeg meget splittet. Begge dele kan blive meget grimt. Breaks/returns kan betrages som gotos, hvilket i mange år har været et af de værste antipatterns. Men nestede ifs gør også bare koden kompliceret at læse. Hvad jeg synes giver bedst læsbarhed og mindsker både problemet med breaks/returns og nestede ifs, er bare at lave korte metoder. Korte metoder er altid nemmere at overskue og læse og gør ofte at normale code smells ikke lugter så meget som de plejer.

@Kim
Vil til dels give dig ret Kim, men alting med måde. Alting kan jo overgøres, ligesom med conditional operators indlejret i hinanden.
Jeg har også set eksempler på mange små metoder hvor jeg havde svært ved at finde rundt i hvad der rent faktisk skete fordi det var en stor storm af metoder der gjorde meget lidt. Et lign. eksempel var så at en havde lavet små metoder som kaldte flere små metoder så når du havde fundet ud af det var denne metode der skulle rettes så skulle du igennem 20 mindre metoder for at finde ud af hvor problemet faktisk var.

Så som med alting så er der gode og dårlige eksempler og hvor og hvordan det bruges.

I en blog fandt jeg et eksempel:

 a==b?c:(a>b?d:e);

Præcist sådan noget er ikke volapyk for mig, men jeg ville nemmere og hurtigere kunne læse den som en "almindelig" if sætning.

csharper:
Lige præcis. Man kan ikke opstille regler for den slags. Det er ikke enten sort eller hvidt. Man er nødt til at tænke selv, og det er noget af det der gør det spændende at kode og designe systemer, imo :-).

@Kim
Vil til dels give dig ret Kim, men alting med måde. Alting kan jo overgøres, ligesom med conditional operators indlejret i hinanden.
Jeg har også set eksempler på mange små metoder hvor jeg havde svært ved at finde rundt i hvad der rent faktisk skete fordi det var en stor storm af metoder der gjorde meget lidt. Et lign. eksempel var så at en havde lavet små metoder som kaldte flere små metoder så når du havde fundet ud af det var denne metode der skulle rettes så skulle du igennem 20 mindre metoder for at finde ud af hvor problemet faktisk var.

Så som med alting så er der gode og dårlige eksempler og hvor og hvordan det bruges.

Brian:
Ja, det er et meget godt eksempel. Det er nemt nok at læse det i eksemplet, men i en rigtig applikation vil variabel navnene være længere og måske en del af en objektstruktur, hvilket gør det sværere at overskue.

I en blog fandt jeg et eksempel:

CSharp kode 

 a==b?c:(a>b?d:e);

Præcist sådan noget er ikke volapyk for mig, men jeg ville nemmere og hurtigere kunne læse den som en "almindelig" if sætning.

Btw. det er irriterende at man ikke kan besvare to indlæg i samme tråd lige efter hinanden. Det ville give mere mening (i hvert fald for mig) hvis dette svar var delt i to.