Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003

Kommentarer är av ondo

Jag lyckades helt spåra ur en tråd på r/gamedev då jag påstod helt ärligt att kommentarer är av ondo och bara juniorer använder dem i domänen.

Det var många som höll med mig men lika många som inte gjorde det. Personligen tycker jag det bara är brus, kommentarer blir snabbt utdaterade och det är bättre se till att hålla koden på en kvalite som gör den självdokumenterande. På sin höjd använda det för lågnivåkod som algoritmer och shaders.

Bra artikel
https://medium.freecodecamp.org/code-comments-the-good-the-ba...

På kul tittade jag genom vår kod och på ett enda ställe i domänen (spelets gamelogic) hittade jag en kommentar

public class PumpActionSlide : FirearmAction { private bool actionReleasePressed; protected override void Update() { base.Update(); CanAttach = firearm.IsAttachedToAnyMover; if (IsAttached && (!firearm.HammerCocked || actionReleasePressed || !Locked)) { MoveRelativeToHand(); } } public override void CheckForPlayerCommands(NVRHand hand) { actionReleasePressed = hand.CheckForPlayerCommand(Command.ReleaseAction); } public override void ReleaseLock() { } public override void FirearmFired() { } public override bool CanReleaseLock { get { return false; } } public override void OnReachedStart() { SlideReturned(); RequestSlideReturned(); } public override void OnReachedEnd() { base.OnReachedEnd(); firearm.IndexNewBullet(); //TODO: a bit of a hack, A pump action shotgun works different from other firearms, the shell must be in the tube when the action goes back. Otherwise it will not be indexed into the chamber. //However, firearm.IndexNewBullet() will index the shell into the chamber which is not true, in reality its first index into the action slider and then chambered when the slide goes forward //Also at somepoint we should make a more complex statemachine that shows the shell/bullet transfer from tube/mag to chamber. Mosy imporant for manual bolt and pump action slides. But any slide being pulled by hand should animate transfer of bullet/shell } public override void SlideReturned(bool playsound = true) { transform.position = SlideStartPoint.position; base.OnReachedStart(); if(playsound) { PlayClose(); } } protected override bool Locked { get { return transform.localPosition == SlideStartPoint.localPosition; } } }

Så vad tycker ni om kommentarers vara eller icke vara?

Trädvy Permalänk
Medlem
Plats
Hammarö
Registrerad
Jan 2004

Kommentarer i källkoder är bra att ha, för då kan fler ta del av informationen om hur saker och ting fungerar. Sen är kommentarer bra att ha för en själv också, ifall man behöver söka för att hitta något snabbt och enkelt (kommentarerna kan alltså innehålla nyckelord).

Jag är helt för kommentarer i källkoder! Man lär sig mer om hur källkoden är byggd då

Trodde för övrigt att du hela tiden menade vanliga kommentarer som på bloggar, innan jag såg ditt kodexempel. Var mer tydlig nästa gång!!

Citera mig om du önskar ett snabbare svar.
Min blogg

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av edgren:

Kommentarer i källkoder (trodde du hela tiden menade vanliga kommentarer som på bloggar, innan jag såg din kodexempel - tydligare info nästa gång, tack!!) är bra att ha, för då kan fler ta del av informationen om hur saker och ting fungerar. Sen är kommentarer bra att ha för en själv också, ifall man behöver söka för att hitta något snabbt och enkelt (kommentarerna kan alltså innehålla nyckelord).

Jag är helt för kommentarer i källkoder! Man lär sig mer om hur källkoden är byggd då

Om du inte kan se hur saker och ting fungerar är det ett tecken på dåligt skriven kod, kanske den borde brytas upp i fler mindre komponenter för att vara mer lättförstålig osv

Trädvy Permalänk
Medlem
Plats
Zion
Registrerad
Apr 2004

Syftar du just på DDD eller är domänen någon form av generalisering du gör?

Oavsett är det ju en fråga om syfte med kommentarer, att kommentera bara för kommenteringens skull, även om saker som inte behövs är onödigt.
Däremot uppstår problem när du t.ex. har kod som du ser som självklar men någon annan kanske inte gör det, kontexten i kod-snutten kanske inte ger nog info vilket gör att någon annan kanske måste läsa hela koden för att förstå sammanhanget. Det är helt ok när de gäller mindre projekt men inte när du sitter och felsöker något som är flera tiotusentals rader eller mer.

Många ggr är det mindre duktiga som kanske kommenterar mer för vissa saker är inte självklara för dem men att anta att alla kommer "förstå din kod" är, för att uttrycka det milt, optimistiskt.

Har du ett privat projekt med kanske ett par kollaboratörer så visst, jobbar du med något seriöst och inte kommenterar din kod lämpligt så kommer det ställa till problem då alla inte tänker som du och det kanske är flera år mellan att du skriver koden och att någon liten del måste ändras/fixas etc.

[ i5-6600K @ 4.7Ghz || Corsair H110 GTX || 16GB DDR4 || ASUS Z170 Pro Gaming || Asus ROG 1080 Strix @ 2100+/11Ghz+ ]
Unigine Superposition 1080p; 17487 @ Medium; 4594 @ Extreme
"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Trädvy Permalänk
Medlem
Registrerad
Feb 2015

@CyberVillain:

Kommentarer är väldigt viktiga, men de används ofta fel.
Att skriva en kommentar om vad en funktion faktiskt gör internt är ofta helt onödigt - det bör framgå av koden.

Vad som däremot är väldigt bra att ha med är
1) Vad funktionen skall göra - vilka in- och ut-data den har. Detta är information för folk som använder sig av funktionen och hjälper även att dokumentera (indirekt) vilka delar av funktionen som är viktiga, och vad som bara är implementations detaljer som kan ändras utan större problem.
Om det visar sig att vad en funktion skall göra och vad den faktiskty gör skiljer sig åt så har man en bugg i funktionen.

2) Varför. Varför använder funktionen just den algoritmen som den gör? Ibland finns det väldigt bra anledningar till att en viss algoritm har valts och man skall vara väldigt försiktig med att ändra den, och ibland så finns det ingen djupare mening med valet utan man tog bara första bästa.

Helt självdokumenterande kod är lite av en myt. Om man inte använder extremt långa och otympliga namn på funktioner och variabler så missar man oftast väldigt mycket information.

Vad gäller att kommentarer blir utdaterade så är det en fråga om disciplin - kommentarer skall alltid hållas updaterade så de matchar koden. Allt annat är bara slarv eller lathet.

Kom ihåg att kommentarer skrivs inte främst för din egen skull, utan för att nya personer skall kunna begripa koden.

Skippa kommentarer helt är sånt som bara nybörjare gör. Så snart man börjar jobba med någon större kodmängd skriven av någon helt annan så inser man snabbt värdet av bra kommentarer.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Feb 2007

Håller med. Skriv bra kod istället för obegriplig kod som förklaras, ofta med opedagogiska kommentarer.

Skickades från m.sweclockers.com

AMD Ryzen 5 1600 | ASUS Prime X370 Pro | OCZ Vector 512GB | Fractal Design Newton R3 600W | Fractal Design Define R4| Corsair Venegance Red DDR4 16GB 3000MHz | Powercolor Radeon HD7970 | Eizo Foris FS2331

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003

@Ferrat: Nej inte domändriven design. All kod har en domän.

@Erik_T: Nej, konsensus bland alla i branchen fortum kanske just juniorer är att kommentarer bör undvikas och att koden ska vara självkommenterande

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av kazen_90:

Håller med. Skriv bra kod istället för obegriplig kod som förklaras, ofta med opedagogiska kommentarer.

Skickades från m.sweclockers.com

Gärna också ouppdaterad så den inte synkar med koden

Trädvy Permalänk
Medlem
Plats
Hammarö
Registrerad
Jan 2004
Skrivet av CyberVillain:

Om du inte kan se hur saker och ting fungerar är det ett tecken på dåligt skriven kod, kanske den borde brytas upp i fler mindre komponenter för att vara mer lättförstålig osv

Att lägga till kommentarsrader i ens källkoder är såklart upp till var och en. Jag försöker göra min källkod så tydlig som det bara går. Att ha en kommentar som berättar att raden nedan är en if-sats, är ju lite overkill. Det är jag medveten om, men jag finner det... snyggare på något sätt.

Bilden nedan visar en liten del av min källkod.

Citera mig om du önskar ett snabbare svar.
Min blogg

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Jun 2007

Att skriva självdokumenterande kod är förstås ett bra mål att ha, men verkligheten ser tyvärr annorlunda ut om man jobbar på lite större projekt med många personer inblandade. Innan jag började jobba som programmerare och mest skrev kod för mig själv så kommenterade jag sällan min kod.

Nu har jag dock i ett par år arbetat inom ett projekt som började för 20 år sedan som ett doktorandprojekt och som sen sett otaliga doktorander och exjobbare komma och gå, med vitt skilda grader av programmeringsfärdighet. Efter några år av att fixa andras trasiga och helt okommenterade kod så kommenterar jag nu för tiden min kod närmast religiöst.

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av edgren:

Att lägga till kommentarsrader i ens källkoder är såklart upp till var och en. Jag försöker göra min källkod så tydlig som det bara går. Att ha en kommentar som berättar att raden nedan är en if-sats, är ju lite overkill. Det är jag medveten om, men jag finner det... snyggare på något sätt.

Bilden nedan visar en liten del av min källkod.

https://erik-edgren.nu/files/screenshot.126.jpg

Det går inte skriva bra kod i php
Ditt exempel är ett perfekt exempel på när en kommentar istället borde varit ett metodnamn, ett klassnamn etc, etc. Som isolerar konceptet "Läste ett inlägg"

Trädvy Permalänk
Medlem
Plats
Kumla
Registrerad
Jul 2008
Skrivet av CyberVillain:

@Erik_T: Nej, konsensus bland alla i branchen fortum kanske just juniorer är att kommentarer bör undvikas och att koden ska vara självkommenterande

Källa på det, som det heter nuförtiden.

Sedan är det stor skillnad på att inte ha några kommentarer och att undvika kommentarer. Eftersom det är väldigt få, om några, som skriver "självkommenterande" kod så tror jag inte att det håller. Och som sagt, vad som är självklart för dig idag är inte det för alla andra och kanske inte ens för dig själv efter några år.

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av perost:

Att skriva självdokumenterande kod är förstås ett bra mål att ha, men verkligheten ser tyvärr annorlunda ut om man jobbar på lite större projekt med många personer inblandade. Innan jag började jobba som programmerare och mest skrev kod för mig själv så kommenterade jag sällan min kod.

Nu har jag dock i ett par år arbetat inom ett projekt som började för 20 år sedan som ett doktorandprojekt och som sen sett otaliga doktorander och exjobbare komma och gå, med vitt skilda grader av programmeringsfärdighet. Efter några år av att fixa andras trasiga och helt okommenterade kod så kommenterar jag nu för tiden min kod närmast religiöst.

Jag satt på bänken 2 veckor under 10 år på mitt förra jobb. Då fick jag i uppdrag att skriva om ett system skrivet inhouse. Alla nyexade fick sitta inhouse först innan konsultcheferna vågade skicka ut dem på uppdrag.. Du kan ju förstå vilken jävla spagetti det blir i ett sådant system. Inga kommentarer hjälper. Vad som hade hjälp borde vara en ratio på 30-70 senior/junior i denna typ av projekt där man säkerställer kodkvalitet.

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003

@videopac: Nej jag (och många andra) säger att man ska undvika kommentarer i den domännära koden (den kod som utför affärsnyttan). Kommentarer i lågnivåkod som bit shifting osv kan behövas. Sedan tycker jag alla team med självbevarelsedrift borde ha bra dokumentation av domänen, men inte i koden

Trädvy Permalänk
Medlem
Plats
Over the rainbow
Registrerad
Sep 2006

Kan bara instämma med de som nämnde en kombination av struktur, snygg och ren kod, samt vid behov komplettera med kommenterar för att spara tid åt andra, tex vid debug och liknande.

Kan för visso hålla med om att man kan diskutera behovet, men jag anser också att koden bör vara snygg och lättfattligt för alla som kan tänkas vilja ta del av den och att det skall gå snabbt och enkelt för andra att ta del av innehållet.
Om en kommentar tex sparar tid för läsaren kan den vara befogad.

Edit, rent kladd hör naturligtvis inte hemma i en kod som skall ge ett professionellt intryck, inte heller i själva kodens struktur, kan för visso hålla med om att det mest ger intryck av lathet.

Behovet av kommentarer blir då själveliminerande till ett minimum.

Edit, generellt för kod, oavsett språk och plattform.

Vänligen Besvara också de SISTA inläggen i trådarna inte bara de första! (Det första inlägget kan mycket väl ha hunnit bli inaktuellt.)

Det är farligt att leva, dödligheten lär vara 100%

Trädvy Permalänk
Medlem
Registrerad
Jul 2005

Det beror helt på kommentaren finner jag.
Kommenterar man varje rad så är det mer irriterande då man kan se vad som händer om raden inte gör 20 saker, vilket är ett dåligt upplägg i alla fall.

Däremot att kommentera en funktion, vad den gör och parameterar den tar och värden den retunerar är väldigt vettigt. Åtminstonde om man inte kan avgöra allt det direkt för att fuktionen är självförklarande med bara några få rader kod.

Som du uppmärksammat så har alla olika önskemål, ett välutvecklat IDE kan tillgodose många av dessa krav. Själv har jag en mindre fontsize och en diskretare färg för kommentarer, det gör att när jag tittar jag på koden för översikt syns inte kommentarerna speciellt väl.

There are 10 types of people in the world: Those who understand binary, and those who don't...

Asus Maximus VIII Hero | i7-6700K | ASUS GeForce GTX1070 Strix 8GB | G.Skill F4-2133C15Q-32GRK |

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Nov 2011

På jobbet sep läste vi en bok, Clean Code, om hur man kan skriva kod mera lättläst och utan kommentarer etc. Efter det förbättrade vi våran kodstandard avsevärt.

Däremot om det behövs kommentarer för att beskriva något så kan/ska de användas, men fortfarande hållas simpla så vida att de som är inblandade och ska läsa koden kan förstå. Vissa saker är helt enkelt mycket lättare att beskriva med en mening än att skriva om koden. Ska man släppa något öppet för andra programmerare kanske man behöver vara lite mera förklarande, men fortfarande hålla ner på texten.

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av WarWolf.667:

Det beror helt på kommentaren finner jag.
Kommenterar man varje rad så är det mer irriterande då man kan se vad som händer om raden inte gör 20 saker, vilket är ett dåligt upplägg i alla fall.

Däremot att kommentera en funktion, vad den gör och parameterar den tar och värden den retunerar är väldigt vettigt. Åtminstonde om man inte kan avgöra allt det direkt för att fuktionen är självförklarande med bara några få rader kod.

Som du uppmärksammat så har alla olika önskemål, ett välutvecklat IDE kan tillgodose många av dessa krav. Själv har jag en mindre fontsize och en diskretare färg för kommentarer, det gör att när jag tittar jag på koden för översikt syns inte kommentarerna speciellt väl.

Jag jobbar tvärt om, strängar och kommentarer får en utstickande färg så att jag ser dem och kan jobba bort dem

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av wargreymon:

Vissa saker är helt enkelt mycket lättare att beskriva med en mening än att skriva om koden.

Dock om man inte biter i problemet och refaktoriserar bort det oklara så kommer koden degenera, kommentarer hjälper inte mot det.

Trädvy Permalänk
Medlem
Plats
Skåne
Registrerad
Jan 2011
Skrivet av edgren:

Kommentarer i källkoder är bra att ha, för då kan fler ta del av informationen om hur saker och ting fungerar. Sen är kommentarer bra att ha för en själv också, ifall man behöver söka för att hitta något snabbt och enkelt (kommentarerna kan alltså innehålla nyckelord).

Jag är helt för kommentarer i källkoder! Man lär sig mer om hur källkoden är byggd då

Trodde för övrigt att du hela tiden menade vanliga kommentarer som på bloggar, innan jag såg ditt kodexempel. Var mer tydlig nästa gång!!

Japp men kommentarer kan också vara farliga. T ex kanske man ändrar i koden men inte i kommentaren, så det står felaktigt vad något gör. Sen har vi det klassiska exemplet där kommentarer skriver vad varje kodrad gör istället för varför den gör det. Det gör det hela mycket svårare att läsa.

Själv vill jag att koden ska tala för sig själv men det är inte alltid det går och då är kommentarer jättebra.

Jag brukar tänka såhär: Behöver jag skriva en kommentar på mer än 2 rader så är det nog bäst att refaktorera lite.

Stationär:Asrock P67 Extreme 4 | i5 2500K@4.5Ghz | Asus GTX 970 black Överklockad | Samsung Evo 960 1TB, 2x WD blue 5TB | 8GB Corsair XMS3 + 8GB Hyper x Fury | EVGA Supernova G2 750W Gold | Silverstone FT02
Laptop: Dell XPS 15 2017
Mobil: Oneplus 6 128GB

Trädvy Permalänk
Medlem
Plats
Umeå
Registrerad
Mar 2015

Av vad jag har/håller på lära mig så är det väl att man bör skriva koden självdokumenterande, men i det fall det inte går exempelvis på grund av lågnivå, komplexa situationer, eller mindre bra namngivning så bör man skriva förklarande kommentarer. Då ska det ju inte vara milslånga kommentarer utan högst en rad, annars bör man tänka ut något bättre.

i7 4770K | GTX 780 X2 | 840 PRO | CF791 && 710-14 Yoga, båda med Arch.

Trädvy Permalänk
Medlem
Registrerad
Nov 2005

Beror väl på... Jag tycker det är bra om metoder och funktioner öppnas med en kort sammanfattning.
Håller med om att kod helst ska vara så bra att den är "självbeskrivande" men en summering kan spara tid.

Annars kommenterar jag endast när man gör nåt jävligt ovanligt som man vet att kollegorna inte kommer ha koll på.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Nov 2011
Skrivet av CyberVillain:

Dock om man inte biter i problemet och refaktoriserar bort det oklara så kommer koden degenera, kommentarer hjälper inte mot det.

Nu syftade jag på sådana saker som gör att man måste skriva koden på ett sådant sätt att den blir onödigt lång bara för att bli mer beskrivande. Inte att man ska sätta en kommentar istället för att refaktorera fulkod.

Trädvy Permalänk
Medlem
Registrerad
Feb 2015
Skrivet av CyberVillain:

@Erik_T: Nej, konsensus bland alla i branchen fortum kanske just juniorer är att kommentarer bör undvikas och att koden ska vara självkommenterande

Självkommenterande kod är en myt. Det finns helt enkelt inte - undantaget helt triviala program.
Välskriven kod med väl valda namn på funktioner och variabler osv. är naturligtvis bra och minskar behovet av kommentarer, men kod som är skriven så bra att inga som helst kommentarer behövs - sådan kod finns inte.

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av Erik_T:

Självkommenterande kod är en myt. Det finns helt enkelt inte - undantaget helt triviala program.
Välskriven kod med väl valda namn på funktioner och variabler osv. är naturligtvis bra och minskar behovet av kommentarer, men kod som är skriven så bra att inga som helst kommentarer behövs - sådan kod finns inte.

Nej vi har ju som sagt en kommentar!
edit: Det är klart det inte alltid går att undvika, men många är slöa och använder kommentarer som en ursäkt för att inte skriva vackra system

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Sep 2013

Tycker personligen liksom @CyberVillain att koden ska vara skriven på så sätt att det är självdokumenterande (d.v.s. kunna vara läsbar av alla), men jag kan tänka mig några scenarion där en eller ett par korta kommenterar kan snabba upp förståelsen för vad koden gör (t.ex. om det är en ganska stor kod som är vid en första anblick är lite krånglig, och att koden inte kan göras mindre krånglig).

Main || Intel Core i7 980X @ 4.12GHz || ASUS Rampage III Gene || Corsair Vengeance 6x4GB @ 1800MHz || EVGA GTX 780 Reference || Creative Sound Blaster ZxR || 2x Intel 530 240 GB || Western Digital Blue WD10EZEX 1000 GB || ASUS VG248QE (no G-sync) ||
Laptop || Lenovo Thinkpad X220 4291-37G ||
Project: Pentium Clockbox || Intel Pentium G3258 ||

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av Icte:

Tycker personligen liksom @CyberVillain att koden ska vara skriven på så sätt att det är självdokumenterande (d.v.s. kunna vara läsbar av alla), men jag kan tänka mig några scenarion där en eller ett par korta kommenterar kan snabba upp förståelsen för vad koden gör (t.ex. om det är en ganska stor kod som är vid en första anblick är lite krånglig, och att koden inte kan göras mindre krånglig).

Jag fick som argument på reddit att han inte kunde skriva bättre kod pga prestandaskäl, ett till metodanrop var för dyrt.. haha ja då jävlar har man prestandakrav

edit: Och så är det ju i vissa tightar loopar som matematiska algoritmer osv.. Men att skriva med det prestandakravet i den vanliga domänen är ju hål i huvudet

Trädvy Permalänk
Medlem
Plats
Borlänge
Registrerad
Maj 2006

Även om vi säger att självkommenterande kod exiterar så är det lite av en utopi. Tror de flesta utvecklare skulle vilja grotta ner sig, snygga till kod, byta ut fula variabelnamn mm men många gånger så är verkligheten att det är tidspress, man får ärva gamla projekt och liknande. Man bör absolut sträva efter att göra tydlig kod men ibland får man helt enkelt "rädda" dålig kod med lite förtydligande kommentarer.

Sen tycker jag rent allmänt att det kan vara bra med nå'n liten kommentar här och där. Inte för att det inte går att läsa koden, men för att det går snabbare att sätta sig in i en funktion med en kort förklaring. Det är ju ett sätt att effektivisera för alla ilblandade.

Huvuddator: i5 2500k@5,0GHz | 4x4GB@1600MHz | GTX 980ti@Stock | EK HF på CPU/GPU + 3.140 rad.
Andradator: i7 920@3,2GHz | 3x2GB@1600MHz | GTX 580 @Stock | Vattenblock på CPU/GPU/SB + 2.120 + 3.120 rad.
Server: AMD 3850 @Stock | 2x4GB@1600MHz | ~3,5TB HDD | Fractal Design Kelvin S36
Lullull: Rift+Touch|HOTAS Warthog|G27

Trädvy Permalänk
Medlem
Plats
Over the rainbow
Registrerad
Sep 2006
Skrivet av Cyne:

Även om vi säger att självkommenterande kod exiterar så är det lite av en utopi. Tror de flesta utvecklare skulle vilja grotta ner sig, snygga till kod, byta ut fula variabelnamn mm men många gånger så är verkligheten att det är tidspress, man får ärva gamla projekt och liknande. Man bör absolut sträva efter att göra tydlig kod men ibland får man helt enkelt "rädda" dålig kod med lite förtydligande kommentarer.

Sen tycker jag rent allmänt att det kan vara bra med nå'n liten kommentar här och där. Inte för att det inte går att läsa koden, men för att det går snabbare att sätta sig in i en funktion med en kort förklaring. Det är ju ett sätt att effektivisera för alla ilblandade.

Kunde inte sagt det bättre själv, tänkte också skriva just det.

Vänligen Besvara också de SISTA inläggen i trådarna inte bara de första! (Det första inlägget kan mycket väl ha hunnit bli inaktuellt.)

Det är farligt att leva, dödligheten lär vara 100%

Trädvy Permalänk
Medlem
Plats
Zion
Registrerad
Apr 2004
Skrivet av CyberVillain:

Men att skriva med det prestandakravet i den vanliga domänen är ju hål i huvudet

Varför? Beror ju helt på vad man jobbar med? finns massor av situationer där antalet clock cycles spelar in och resurser är begränsade etc av antingen hårdvaruskäl eller pga resursfördelning. Visst, programmerar du ett spel till en high-end gaming setup kanske det inte är kritiskt men det är ju är ju långt ifrån allt som programmeras.

[ i5-6600K @ 4.7Ghz || Corsair H110 GTX || 16GB DDR4 || ASUS Z170 Pro Gaming || Asus ROG 1080 Strix @ 2100+/11Ghz+ ]
Unigine Superposition 1080p; 17487 @ Medium; 4594 @ Extreme
"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood