Kommentarer är av ondo

Tycker inte det är en antingen/eller fråga.
Självfallet är det väl knappast rimligt att skriva en kommentar per kodrad.

Däremot gillar jag kommentarer på funktion/klasssnivå, men det beror nog lite mer på hur man jobbar.
Kör man mkt kodning mot befintlig kod/apier/whatever, så är man sällan intresserad av att gå in och läsa igenom funktionen för sakens skull, jag vill då bara snabbt veta "gör denna funktion det jag behöver?".

Problemet är ju att kommentarer/dokumentation sällan (aldrig? ) underhålls, så det är väl mest det som gör mig kluven till det hela.
Oftast i scenariot jag beskriver ovan går man på en mina ändå eftersom kommentar/docs är så utdaterade att det som skrivs inte stämmer. Och så har man då först fått läsa docs + implementera + felsöka + sluta med att läsa igenom kodfan ändå

Spel, eller saker som körs på en PC allmänt idag behöver inte vara direkt optimerat, inte ens en spelmotor, men som jag sa, det är långt ifrån all kod som skrivs och beror som sagt på vad man arbetar med.

Såvida man inte jobbar i ett litet projekt med få inblandade så är ju kommentarer livsviktiga för att nästkommande person snabbt ska kunna sätta sig in i koden och ta över.
Osäker på varför TS tycker att koden i exemplet är självkommenterande, då det finns tvetydighet lite överallt däri.

Jag tycker Googles styleguide är ganska bra, men en del av det kan man väl skippa i mindre projekt:
https://google.github.io/styleguide/cppguide.html#Comments

I kort, jag håller med och jag gör inte så...överflödet av kommentarer kan vara lika förvirrade som avsaknaden av kommentarer.

Saker ska i sin mån vara självförklarande, men självförklarande för vem? Vart sätter man ribban och hur långt vill man ta ett mönster?

Jag skulle våga påstå att det är svårt att säga vad som är bäst, då det verkligen är upp till var och en. Men av erfarenhet är resultatet av för lite kommentarer lika förödande som mer för mycket.

Sedan kan man ju tillägga att många kommenterar pga. dokumentation, jag arbetar mycket mer kommentarer för genering av dokumentation. Skriver rätt mycket publika API:er och där är det ovärdeligt med kommentarer som sedan används vid generering av dokumentation för dessa publika API:er!

Ser ut som att tråden spårade lite här med

Vi pratar om helt olika nivåer av optimering och krav, en spelmotor bör vara optimerad ja men det är inget krav och inte heller direkt kritiskt. Du verkar prata programmering riktat till stor del mot just spelprogrammering eller applikationsprogrammering, jag pratar om det mer allmänt och inkluderar saker du inte verkar göra. Vet som ju inte kontexten av diskussionen du hade med personen som inte kunde "skriva snyggare" pga krav men som jag påpekat finns det massor av situationer där sådana krav existerar.

Hur du använder domän här är ju luddigt igen då du just du skiljer på spelmotor vilket är kod, och domän vilket du använder för att referera till all kod med syfte? Spelmotorn måste ju vara en domän med? eller hur använder du det egentligen?

    public class TubeFedShotgun : InternalMagazineFirearm
    {
        protected override void Awake()
        {
            base.Awake();
            Category = FirearmCategories.Primary;
            UsesTouchpad = true;
        }

        public override bool TriggerReady(NVRButtonInputs trigger)
        {
            return trigger.SingleAxisDown;
        }
        
        protected override void AddForceToCasing(Rigidbody casing)
        {
            casing.AddForce(-this.transform.right * 1.5f);
            casing.AddRelativeTorque(new Vector3(0.0005f, 0.001f * (5 + Random.value * 5), 0.0005f));
        }
    }

Ditt första exempel med Shotgun var ganska läsbar, den här förstår jag väldigt lite av. Användning av literaler är typiskt förvirrande. Awake är inte självförklarande men verkar fungera som någon initiering? TriggerReady är heller inte självförklarande, ready i vilket syfte, är det säkringen?

Som någon som gör kundanpassningar av en programvara, och hoppar mellan olika brancher lite hela tiden har jag svårt att se att det går att klara sig bra utan dem. Saker kan liksom fungera på olika sätt från en branch till en annan, och kommentarer hjälper rätt rejält när man snabbt ska sätta sig in i en viss branch, och behöver se vad och varför folk (eller en själv) har gjort på ett visst sätt här.

@CyberVillain: Ja, fast du pratar fortfarande då i stort sett enbart programmering för en modern PC med hutlöst mycket resurser, där du kan vara övertydlig med din kod etc. Finns skäl till att kommentering fortfarande är oftast är ett krav när man utbildar, du vet aldrig vilken miljö du ska jobba i, du vet aldrig hur länge koden kommer vara aktiv eller vem som kommer efter dig osv. Att sträva efter lättläst kod, lättöversiktlig struktur osv är alltid bra men att prata som att kommentarer är "av ondo" känns mest som en optimistisk och begränsad syn, även länken du säger är bra läsning påpekar uttryckligen att det finns skäl för kommentarer.

					if (TriggerReady(trigger)) {
						this.Fire ();
						firstShot = false;
					}

Tror att det är detta som kan dela folks åsikter.

Jag vill ju ibland ha kommentarer just för att slippa det du nu beskriver.
Dvs ser jag en func DoSomeLeetHaxx(){} så vill jag (oftast) inte behöva hoppa igenom femtielva steg i kod och läsa 15 andra chainade funktioner för att förstå vad fasen det är som händer.

Givetvis så bör/kan en insatt/vettig programmerare förstå vad koden gör, och då kan man argumentera för att kommentarer/dokumentation är överflödig.

Själv så vill jag oftast ha kommentarer/docs för att spara tiden det tar mig att göra precis det du beskriver.
Men det är absolut potato / pottattoo, min besparing i tid kräver istället att utvecklaren innan lagt tid på underhåll av kommentarerna.

Så det beror ju helt på fallet. Ska man komma in som ny utvecklare i domänen på heltid så ser jag inga problem.
Men är man som oftast bara inne och doppar lite här och var, så är det i min mening guld värt att ha kommentarer. Ofta skiter jag fullständigt i hur det faktiskt fungerar, inte mitt problem. Jag vill bara använda skiten och fokusera vidare på det jag faktiskt vill göra.

Problemet man ändå ofta kommer till när man satt sig in väl nog är att man (det gör väl ALLA utvecklare?? ) ändå anser att skiten är felimplementerad och så gör man sin egen implementation ändå.
I den förra domänen jag satt i var det inte ovanligt att man hittade 10 (ja, tio) olika implementationer för att åstadkomma samma sak
Ofta så det blir när man har hög personalomsättning och ingen som riktigt orkar bry sig om helheten.

Jag säger inte emot dig, berättar bara om mina erfarenheter. Hittils i min karriär har jag ALDRIG suttit i ett projekt där vi fått starta cleant. Ofta har det varit år, om inte tiotals år, av legacy.
Ofta har det varit så illa att all källkod inte ens funnits, så man har fått bygga runt existerande kod i produktion som ingen orkat bygga om.

Något som jag skulle vilja kalla det ”absolut sjukaste” jag sett, var ett ställe där dom fuckat upp så hårt och målat in sig i ett hörn och varit så trött att dom inte orkat bry sig, att dom skapat en ”SuccessfulException”. Helt enkelt så gick all returhantering ut på att kasta en exception, så när dom väl insåg att dom hade ett success att returnera så blev do tvunga att skapa en exception för det, och sen så levererade dom returvärdet som exception-message

Lite kodkommentarer hade då varit guld värt

Benägen att hålla med, men det är så verkligheten ser ut för 98+% av alla mjukvaruutvecklare.