C# Skriva i konsol

Har ingen aning, men test är väl variabeln i hans kod(?)

Variabeln som ges ett värde är test... ReadLine() är en funktion från klassen Console, och funktionens returvärde lagras i test.

string s = Console.ReadLine();

För siffra:
int i = Int.Parse(Console.ReadLine());

Skriva ut först sedan ta in tal:
Console.Write("Tal: ");
string s = Console.ReadLine();

Använd inte var är mitt tips

Lite offtopic, men använd Int32.TryParse och inte Parse, annars smäller det om man skriver något annat.

int i = Int.Parse(Console.ReadLine());

var xxx = Int.Parse(Console.ReadLine());

MySuperLongDataTypeNameThatsVeryVerboseToIncludeTwice foo = new MySuperLongDataTypeNameThatsVeryVerboseToIncludeTwice();

Och "string s" bara var för att visa det hela läste du inte?
Sedan så sa jag att det finns bra ställen att använda "var" på, men vid all deklaration blir det bara otydligt.

Japp, men ur tex ett LINQ rad kan det vara svårt att veta exakt vad man kommer få ut, bara att den implementerar IEnumerable och det var det som "var" skapades för från början, som quoatat från MSDN tidigare.

Sant att det inte har något att göra med frågan, men jag känner också att jag måste pitcha in nu. Jag tycker att vars varande eller inte varande (höh) är ett non-issue, men föredrar alltid var framför direkt typnamn.

Dels är det en code-smell att ha så mycket kod i en metod att man tappar koll på vad en variabel har för innehåll. Det blir även lite enklare att refaktorera kod när en metods returvärde inte behöver deklareras på både call-site och definition-site. Den kanske främsta anledningen är att jag ofta försöker organisera min kod så att ett tilldelat värde är ett fast värde. Jag ser ofta juniora utvecklare deklarera sin variabel för att sedan bygga på den i omgångar, något i den här stilen:

string text;
//-andra deklarationer-
if (something == 42) {
    text = GetText();
} else {
    text = GetOtherText();
}
text = text + " and then some!";

... istället för

var text = something == 42
    ? GetText()
    : GetOtherText();
var message = text + " and then some!";

Det är förvisso en smaksak. Det är i min mening rörigare att spåra en variabel från deklaration, genom ett antal mutationer och vidare till användningstillfälle, än att sätta den direkt i en tilldelning. Eftersom det inte går att deklarera en variabel med var utan att samtidigt tilldela den ett värde känner jag mig säker på att den har det värde den ska ha. Vilket, ska medges, är ett resultat av min egen programmeringsstil.

Många av dessa åsikter kommer säkerligen från att jag jobbat mycket i Scala, där alla variabler deklareras med val (och i sällsynta fall var, om variabeln ska vara muterbar.)

string text;
//-andra deklarationer-
if (something == 42) {
    text = GetText();
} else {
    text = GetOtherText();
}
text = text + " and then some!";

var text = something == 42
    ? GetText()
    : GetOtherText();
var message = text + " and then some!";

Varför inte:

string text = something == 42
    ? GetText()
    : GetOtherText();
string message = text + " and then some!";

?

string text;
//-andra deklarationer-
if (something == 42) {
    text = GetText();
} else {
    text = GetOtherText();
}
text = text + " and then some!";

var text = something == 42
    ? GetText()
    : GetOtherText();
var message = text + " and then some!";

Det man kan konstatera är att den kod du säger att juniora utvecklare faktiskt är bevisat bättre i bemärkelsen hur sannolikt det är att koden innehåller ett fel. I kod som används i system där buggar kan leda till fysisk skada så är normalt sett användande av '?' operatorn inte tillåtet just p.g.a. av denna statistik.

Vad det gäller 'var' så är det nog rätt vettigt att använda i många fall. En fara i C# är när den används på typer som tillåter implicit konvertering, inte helt lätt att lura ut vilken typ 'var' då har om variabel initieras via en beräkning. Implicit konvertering mellan typer är något som visat sig stå för rätt stor andel buggar i program, nya statiskt typade språk verkar gå mot att totalt förbjuda implicit konvertering (t.ex. Go och Swift).

Det låter oerhört märkligt, finns detta dokmuenterat? Jag har korrigerat betydligt fler buggar bland if-satser där variabler inte initierats ordentligt eller fått ett oväntat värde. Faktum är att jag vad jag kan minnas aldrig fått en bug vid användande av ternary operatorer.

I språk som drar åt det funktionella hållet är if-then-else ofta expressions istället för statements vilket leder till ungefär samma funktionalitet som ternary-operatorerna annars tillhandahåller. Detta brukar anses vara en Bra Grej™ just för att ett värde direkt kan tilldelas.

Menar du saker som int till double-expansion? Jag har aldrig upplevt det som ett problem specifikt relaterat till användandet av typinferens.

I Swift använder man väl just var och let för att definiera sina variabler?

Dokumenten är saker man får betala dyrt för så inget jag kan posta. Men om du hittar kodstandard för någon organisation som t.ex. certifierar sin kod enligt DO-178C (används för kritiska system i flygplan) så lär du se att den bl.a. förbjuder användandet av '?'.

Exakt, int * uint -> long i C# medan det i t.ex. C++ blir uint. Så något som ser exakt lika ut (bara att 'var' stavas 'auto' i C++) ger olika resultat. Nu är det inte det buggar kommer av, det är snarare jämförelse som någon trodde var "signed" men i praktiken är "unsigned". Om man skriver ut typen så kommer det inte ens kompilera i C# om man gör ett felaktigt antagande och i C/C++ kan man få samma beteende i de flesta kompilatorer om man kör med "warnings as errors" (vilket alla borde göra idag). Använder man 'var/auto' så kommer kompilator anta en typ som gör att det kompilerar, men det kanske inte var den man förväntade sig.

Ja, Swift använder sig av var/let, men du får t.ex. inte addera två tal av olika typ. Go använder sig av denna syntax (motsvara 'var' i Swift)

aSignedInt     := 123
anUnsignedInt  := 123u
willNotCompile := aSignedInt + anUnsignedInt
willCompile    := uint(aSignedInt) + anUnsignedInt

Även här skulle ser man att krav för kritiska system är att all form av typkonvertering ska vara explicit. Gissar att verktyg för statisk kodanalys kan hantera automatisk "type-inference", annars lär man inte få använda auto/var i sådana lägen.

Överhuvudtaget är det rätt vettiga regler man använder sig av, en annan är att "McCabe Cyclomatic Complexity" inte kan vara över 10 utan väldigt bra motivation. Har man sådana regler i sin egen kodstandard så kommer många fall av dålig kod aldrig ens kunna passera automatiska tester av kvalité.

Sjukt härligt nörderi. Ibland är Sweclockers bara bäst.

Jag tror det OP ville veta var IMMED -fönstret, där han medan han debuggar sin kod kan styra värdet på variables i runtime?

Att hänvisa till stängd/otillgänglig dokumentation hjälper mig tyvärr inte. Jag är inte intresserad av flygsystem utan dokumenterade exempel där ?: ansetts skadligt av en given orsak.

En snabb googling gav bland annat http://programmers.stackexchange.com/questions/28314/ternary-..., http://stackoverflow.com/questions/694814/ternary-operator-ba... och http://stackoverflow.com/questions/160218/to-ternary-or-not-t..., vilket i stort verkar ge min intuition stöd.

Detta kompilerar i C#:

    uint a = uint.MaxValue;
    int b = -1;

    Console.WriteLine(a == b); // False

Nu var det kanske inte så du menade, men i vilket fall så är problemet du beskriver begränsat till primitiva värden. Hur kringgår rent funktionella språk den här problematiken? De drivs just oftast av typinferens.

Brad glömde i sitt inlägg från 2011 nämna att det, i den offentliga dokumentationen, direkt innan ...-stycket står:

Slutklämmen noterar att den officiella C#-dokumentationen generellt sett använder explicit typnotation då användadet av var åtminstone har potential att vara mer svårförstådd. Ingen stans rekommenderas det att man undviker var.

Haveri i flygsystem betyder typisk allvarlig skada eller död för människor, man har regler där för statistik visar att vissa konstruktioner innehåller fler buggar än andra och endast en av dessa behövs. I språket Go, som skapats av bl.a. Rob Pike och Ken Thompson som båda har väldigt mycket erfarenhet av väldigt stora och komplexa system, valde man explicit bort "?:" p.g.a. man sett allt för mycket dumheter i produktionskod från kreativ användning av "?:". Standarder för medicinsk utrustning har liknande krav.

Du kanske inte är intresserad av dessa områden, men kod som är certifierade enligt dessa standarder har långt färre buggar än genomsnittlig kod, så något gör man rätt här.

Tittar man däremot på MISRA (Motor Industry Software Reliability Association), som inte är en certifieringsstandard utan en rad rekommendationer/krav för kod som ska användas inom en rad områden (ibland ihop med certifiering typ DO-178C) så har de bara ett allmänt krav att syftet med varje uttryck måste vara uppenbart men det finns inget specifik förbud mot t.ex. "?:". Däremot har MISRA och alla standader explicit förbud mot rekursion, både explicit och implicit vilket även gör det svårt, men inte omöjligt (bara dyrt att certifiera), att använda alla former av funktionspekare.

Du anser alltså några personers åsikter på Internet som ett starkare bevis på att din känsla är rätt än att de som skrivit specifikationer för hur man ska utveckla programvara där buggar typiskt betyder allvarlig skada eller död för människor?

Personligen har jag inget emot "?:" (utom då jag skriver kod för "safety critical system" och använder det väldigt sällan annars också) och ditt exempel ovan ser jag absolut inget fel med, vara bara att du ansåg att det andra på något sätt skulle vara sämre jag reagerade mot.

    uint a = uint.MaxValue;
    int b = -1;

    Console.WriteLine(a == b); // False

Här är ett exempel

            var cond = false;
            var x = cond ? 10 : 'a';
            var y = cond ? ' ' : 'a';

            Console.WriteLine("x={0}", x);
            Console.WriteLine("y={0}", y);
            Console.WriteLine("{0}", cond ? 0.0 : 'a');

Detta är en klass av fel folk gör med "?:" (i C eller pre-C++11 skulle det bara vara det sista fallet som är relevant), de tänker inte på att "?:" använder ranking-regler för att avgöra typ.

Rent funktionella språk är bra i teorin, i praktiken har C + en rad regler + statisk kodanalys visat sig generera kod av betydligt bättre kvalité när kvalité är absolut kritiskt. Men funktionella språk som Haskell fungerar typiskt som Go, alla former av konvertering måste vara explicit (vilket även krävs av saker som MISRA och standarder för säkerhet, går att hårt efterleva i C & C++ via automatisk check med statisk kodanalys).

Men tror denna diskussion rejält gått off-topic nu. Och är personligen en förespråkare för "type inference" + har inget personligt mot "ternary conditional operator", men det verkar vara något som genererar rätt mycket debatt och heta känslor när man t.ex. läser reaktionerna när Python införde stöd för detta i v2.5.

Jag är intresserad av varför, inte att. Även om det du skriver är mycket intressant så ger du fortfarande inga konkreta exempel på hur ?: skulle kunna leda till människors död. De poster jag länkade till var vad som kom upp när jag googlade "ternary operator considered harmful" i hopp om att hitta något matnyttigt. Du får som sagt gärna fylla på och länka in poster eller konversationer som berör ämnet.

            var cond = false;
            var x = cond ? 10 : 'a';
            var y = cond ? ' ' : 'a';

            Console.WriteLine("x={0}", x);
            Console.WriteLine("y={0}", y);
            Console.WriteLine("{0}", cond ? 0.0 : 'a');

Detta är också tillåtet:

	bool cond = false;
	int x;
	
	if (cond) {
		x = 10;
	} else {
		x = 'a';
	}	
	Console.WriteLine("x={0}", x);

Jag ser inte hur det skulle vara bättre. Jag kan hålla med dig om att det är konstigt att char konverteras till int (och double!) men det har inget att göra med vare sig typinferens eller ?:.

Jo den har nog det, men det är fortfarande intressant
Du får gärna skicka ett PM om du vill diskutera vidare eller tipsa om läsnyttigt; jag gillar att försöka se saker från flera vinklar.