Forum Mjukvara Programmering och digitalt skapande Tråd

Kommentarer är av ondo

1 2 3 4 5 6 7 8
Skriv svar
Permalänk
Medlem ★
●
Skrivet av CyberVillain:

@Ferrat: Nej domänen är den kod som är grundläggande för ditt affärsområde. Är det ett försäkringsbolag kanske det är koden som beräknar premier på alla försäkringar osv. Sedan har du massor med boilerplatekod, denna kan man med fördel minimera genom att använda ramverk från microsoft google osv.. Och sedan har du lågnivåkod som av olika själ måste vara komplex och svårläst

Gå till inlägget

Så du använder det i två olika betydelser? Eller en abstraktion av all kod som du bryr dig om? För isf är det ju väldigt luddigt vad du menar och när du menar det?

Skrivet av CyberVillain:

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

Gå till inlägget

Pratar du inte kod allmänt gällande kommentarer utan enbart ditt aktuella område? För det du pratar om nu ovan är ju just DDD med fokus på just den del av utvecklingen/koden som är aktuell för dig i en utvecklingsmiljö.

Visa signatur

"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Redigera
Citera flera Citera
Permalänk
Avstängd
●

@Ferrat: Du har ju alltid en kärndomän i ett system även om du inte kör domändrivet. I ett affärssystem är det den affärsnära logiken. osv, osv.. Till skillnad från ramverkskod, och liknande.

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Svaret är väl självklart.

Skriv ren och självförklarande kod.
Skriv in kommentarer för säkerhets skull.

Men det beror såklart på projektet. Jag är inte programmerare själv men jag har hört mycket ont om kodprojekt där koden ursprungligen är 20+ år gammal och har reviderats av 100+ personer genom åren. Sådant är jättevanligt.

Skriver du något som bara ska användas ett år framåt så visst... men om det du skriver kanske ska användas i decennier är det en viss hybris att anse att just ditt sätt att koda idag är allmängiltigt.

/hulle.

Visa signatur

A600, 2 MB Chipram, 85 MB HD, Extra diskettstation, Joysticks: Tac-2, The Bug och Wico Red Ball.
Zotamedu:"Kompressorkylning är nog det mest miljöfarliga du kan göra med en dator om du inte tänker börja elda brunkol i den."

Redigera
Citera flera Citera
Permalänk
Avstängd
●

SÅ denna precis på jobbet

        private DateTime GetPaymentDate(IPPolicyMonth pm) {
                return pm.Month.AddMonths(1).AddDays(-1);

            //var date = rm.Company.ConnectedToAutoGiro ?
            //    rm.ReportMonth.Month.AddDays(3): // Den 4:e
            //    rm.ReportMonth.Month.AddDays(2); // Den 3:e
            
            //if (date.DayOfWeek == DayOfWeek.Sunday)
            //    return date.AddDays(-2);
            //if (date.DayOfWeek == DayOfWeek.Saturday)
            //    return date.AddDays(-1);

            //return date;
        }

Det borde vara dödsstraff på att kommentera bort kod när det finns git samt metoden användes inte ens.. Vart delete på den direkt..

edit: Notera också att någon har ändrat på dagarna i koden men behållt kommentaren som nu pekar fel. Hade ju dessutom gått skriva den där mycket snyggare, men det hör ju inte hit

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Avstängd
●

Asch, rita bara en stor kuk med diverse obskyra tecken så löser det sig...

Visa signatur

Daisy, Daisy...
Three is a magic number
Yes it is, it's a magic number

Redigera
Citera flera Citera
Permalänk
Keeper of Traditions ★
●
Skrivet av CyberVillain:

SÅ denna precis på jobbet

        private DateTime GetPaymentDate(IPPolicyMonth pm) {
                return pm.Month.AddMonths(1).AddDays(-1);

            //var date = rm.Company.ConnectedToAutoGiro ?
            //    rm.ReportMonth.Month.AddDays(3): // Den 4:e
            //    rm.ReportMonth.Month.AddDays(2); // Den 3:e
            
            //if (date.DayOfWeek == DayOfWeek.Sunday)
            //    return date.AddDays(-2);
            //if (date.DayOfWeek == DayOfWeek.Saturday)
            //    return date.AddDays(-1);

            //return date;
        }

Det borde vara dödsstraff på att kommentera bort kod när det finns git samt metoden användes inte ens.. Vart delete på den direkt..

Gå till inlägget

Och på att använda upper camel case på funktionsnamn.... Urk!

Visa signatur

|| Intel 8700K || Asus RTX 4070 TI Super TUF || Samsung 750 EVO 500GB & Kingston A2000 1TB & Samsung 960 EVO 250GB || Corsair RM 850x || Antec P183 || Asus G-Sync RoG Swift PG279Q || Dell XPS 15 || Thinkpad X220

The Force is like Duct Tape, it has a light side, a dark side, and holds the universe together.

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av Dunder:

Och på att använda upper camel case på funktionsnamn.... Urk!

Gå till inlägget

i C# är både privata och publika stora

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Tycker det är bra, speciellt som komplement till annan dokumentation.
Jag har sett fall där kommentarer i källkoden är den enda beskrivningen, och då är det väldigt tacksamt för nästa person som en dag ska förbättra eller lägga till funktionalitet.

Kommentarerna får då beskriva övergripande vad tanken med metoden/funktionen är, inte kommentarer av typen "Den tar in tre heltal, gör nånting och sätter en flagga", det ser man ju ändå, eller förklara varför man gör nånting för att undvika eller jobba runt ett problem i förekommande fall.

Visa signatur

|[●▪▪●]| #Lekburk#: Ryzen 3700X >-< GB-X570-AE >-< 32GB DDR4 >-< MSI RTX 3070 >-< 970 EVO 1TB SSD>--
--< Arctic Freezer 34 >-< FD Define R4 >-< Seasonic F.+ 650W >-< Acer XF270HUA >-< AOC Q2778VQE >--
#Servering#: Ryzen 1700@3,6GHz >-< Prime X470 Pro >-< 16GB DDR4 >-< GTX 1030 >-< 970 EVO 500GB SSD >--
--< Stockkylare >-< Antec P182 >-< Silver Power 600W >-< Samsung 245T |[●▪▪●]|

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av CyberVillain:

SÅ denna precis på jobbet

        private DateTime GetPaymentDate(IPPolicyMonth pm) {
                return pm.Month.AddMonths(1).AddDays(-1);

            //var date = rm.Company.ConnectedToAutoGiro ?
            //    rm.ReportMonth.Month.AddDays(3): // Den 4:e
            //    rm.ReportMonth.Month.AddDays(2); // Den 3:e
            
            //if (date.DayOfWeek == DayOfWeek.Sunday)
            //    return date.AddDays(-2);
            //if (date.DayOfWeek == DayOfWeek.Saturday)
            //    return date.AddDays(-1);

            //return date;
        }

Det borde vara dödsstraff på att kommentera bort kod när det finns git samt metoden användes inte ens.. Vart delete på den direkt..

edit: Notera också att någon har ändrat på dagarna i koden men behållt kommentaren som nu pekar fel. Hade ju dessutom gått skriva den där mycket snyggare, men det hör ju inte hit

Gå till inlägget

Som sagt... Kommentarer/docs underhålls sällan

Skulle säga att ungefär var 3:e funktion såg ut sådär på mitt förra ställe.
En sökning på "Todo:" genererade över 10k (japp, 10 000) träffar.
Ett av skälen till att inget gjordes åt saken var att ingen av dom/oss som var kvar varken kände att det var vår sak eller orkade lägga tid & ta ansvar för städandet.

Något av det bästa var när det kunde se ut som (väldigt förenklat exempel, halvpseudo):

// Return: a+b
func DoSomeHaxx(int a, int b) {
    return a - b;
}

[Fact]
func Add_should_sum_correctly() {
      //var res = _sut.Add(2,2);
     var res = 4;
     Assert.Equal(4, res);
}

Sen kunde man se denna funktion användas där callern verkligen förväntade sig att talen skulle summeras
Folk har sen alltså bytt namn på funktionen, ändrat vad den gör, samt "haxxat" till testet att ändå gå igenom.
Herregud.

Enda sättet mig veterligen att slippa sån här skit är extensiv code-review, men väldigt väldigt sällan det finns tid & ork till det.
Alternativt nån form av statisk kodanalys vid incheck?

Redigera
Citera flera Citera
Permalänk
Avstängd
●

@BasseBaba: hehe, sjukt bra, eller kommentarre som dessa

//save order to database
orderRepository.Save(order);

edit: Vi kör gated commits där varje pull måste code reviews.. men ofta godkänner utvecklaren själv pullen

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av RHWarrior:

Tycker det är bra, speciellt som komplement till annan dokumentation.
Jag har sett fall där kommentarer i källkoden är den enda beskrivningen, och då är det väldigt tacksamt för nästa person som en dag ska förbättra eller lägga till funktionalitet.

Kommentarerna får då beskriva övergripande vad tanken med metoden/funktionen är, inte kommentarer av typen "Den tar in tre heltal, gör nånting och sätter en flagga", det ser man ju ändå, eller förklara varför man gör nånting för att undvika eller jobba runt ett problem i förekommande fall.

Gå till inlägget

Kommentaren i mitt ursprungsinlägg tycker jag är bra exempel på en vettig komentar

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av CyberVillain:

i C# är både privata och publika stora

Gå till inlägget

Off topic:

Vilket enligt mig är felaktigt.

Små bokstäver gör det mycket enklare att identifiera det som en metod istället för property. Dessutom är det ett ypperligt tillfälle att skilja på egen kod och inbyggd kod.

On topic:

Om ens kod är mer publik än inhouse, exempelvis ett publikt bibliotek, så ska det vara kommenterat men dock endast det som kan tänkas vara ointuitivt. Rent generellt så om man måste förklara metoden/klassen för sin polare så måste man nog kommentera metoden/klassen.

Visa signatur

ηλί, ηλί, λαμά σαβαχθανί!?

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av Leedow:

Off topic:

Vilket enligt mig är felaktigt.

Små bokstäver gör det mycket enklare att identifiera det som en metod istället för property. Dessutom är det ett ypperligt tillfälle att skilja på egen kod och inbyggd kod.

On topic:

Om ens kod är mer publik än inhouse, exempelvis ett publikt bibliotek, så ska det vara kommenterat men dock endast det som kan tänkas vara ointuitivt. Rent generellt så om man måste förklara metoden/klassen för sin polare så måste man nog kommentera metoden/klassen.

Gå till inlägget

Jo, fast den dokumentationen tycker jag ska ligga utanför koden, tex en wiki, exempel från ett av mina egna publika APIer

https://github.com/AndersMalmgren/SignalR.EventAggregatorProx...

Eller om du kör http://dotnet.github.io/docfx/ kan du lägga headerdatat i separata filer istället för i koden

Senast redigerat
Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av CyberVillain:

Jo, fast den dokumentationen tycker jag ska ligga utanför koden, tex en wiki, exempel från ett av mina egna publika APIer

https://github.com/AndersMalmgren/SignalR.EventAggregatorProx...

Eller om du kör http://dotnet.github.io/docfx/ kan du lägga headerdatat i separata filer istället för i koden

Gå till inlägget

Du har inte hört talas om intellisense? Skriver man korrekt formaterade kommentarer så får man upp informationen direkt när man skriver anropet till funktionen exempelvis. Ganska mycket smidigare än att behöva leta på någon internwiki eller liknande i alla fall.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Varför inte kommentera?

Hjälper mig fort och enkelt att hitta snutten av kod som jag vill ändra eller utöka, utan att behöva läsa koden först.

Visa signatur

[IT-Dept]
Ryzen 1700 OC - 32 - 1070

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av snajk:

Du har inte hört talas om intellisense? Skriver man korrekt formaterade kommentarer så får man upp informationen direkt när man skriver anropet till funktionen exempelvis. Ganska mycket smidigare än att behöva leta på någon internwiki eller liknande i alla fall.

Gå till inlägget

Ja, jag nämner ju docfx ovan ffs

Skickades från m.sweclockers.com

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av AllMessedUp:

Varför inte kommentera?

Hjälper mig fort och enkelt att hitta snutten av kod som jag vill ändra eller utöka, utan att behöva läsa koden först.

Gå till inlägget

Kommentarer i kod blir ofta utdaterad och irrelevanta då de inte uppdateras när kod ändras, de är även I vägen för koden, språk blir enklare för ny version ta lambda som exempel I c# eller inbyggda nulloperatorer osv, kommentarer motverkar detta. Sedan så är det många utvecklar som skriver kommentarer istället läsbar kod vilket är tråkigt

Skickades från m.sweclockers.com

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av CyberVillain:

Kommentarer i kod blir ofta utdaterad och irrelevanta då de inte uppdateras när kod ändras, de är även I vägen för koden, språk blir enklare för ny version ta lambda som exempel I c# eller inbyggda nulloperatorer osv, kommentarer motverkar detta. Sedan så är det många utvecklar som skriver kommentarer istället läsbar kod vilket är tråkigt

Skickades från m.sweclockers.com

Gå till inlägget

Känns ändå som en smaksak.

Räcker med att kommentera kodsnutten med ett ord så fattar man direkt vad t.ex. metodens syfte är. Tror det tar längre tid för en som inte kodat applikationen att förstå vad som händer annars.

Men känner ändå att det är en smaksak.

Visa signatur

[IT-Dept]
Ryzen 1700 OC - 32 - 1070

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av AllMessedUp:

Känns ändå som en smaksak.

Räcker med att kommentera kodsnutten med ett ord så fattar man direkt vad t.ex. metodens syfte är. Tror det tar längre tid för en som inte kodat applikationen att förstå vad som händer annars.

Men känner ändå att det är en smaksak.

Gå till inlägget

OM du inte förstår metodens syfte är det dags för en refaktorisering, tex bättre metodnamn, bryta upp den i fler mindre metoder eller tom bryta ut den i egen klass, etc, etc

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Avstängd
●

@CyberVillain: Det låter lite som om du lever i en idealvärld där all kod är självförklarande och är den inte det så finns all tid i världen till att refaktorisera osv. Min värld ser inte ut så, och sannolikt inte de flesta utvecklares. Sen handlar det förstås om disciplin, ändrar man en funktion måste man ju också ändra dokumentationen inklusive kommentarer liksom. Att hänvisa till en internwiki gör inte detta enklare snarare tvärtom.

Mitt nuvarande team jobbar agilt och todos är då ett grymt verktyg för att exempelvis markera saker som behöver refaktoriseras eller tänkas om, mycket på grund av att todos visas i errorlistan i VS automatiskt. Vi har också flera team, externa likväl som interna, som arbetar mot vår kod och då blir det väldigt mycket mindre frågor om man har relevanta kommentarer som syns i intellisense.

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av snajk:

@CyberVillain: Det låter lite som om du lever i en idealvärld där all kod är självförklarande och är den inte det så finns all tid i världen till att refaktorisera osv. Min värld ser inte ut så, och sannolikt inte de flesta utvecklares. Sen handlar det förstås om disciplin, ändrar man en funktion måste man ju också ändra dokumentationen inklusive kommentarer liksom. Att hänvisa till en internwiki gör inte detta enklare snarare tvärtom.

Mitt nuvarande team jobbar agilt och todos är då ett grymt verktyg för att exempelvis markera saker som behöver refaktoriseras eller tänkas om, mycket på grund av att todos visas i errorlistan i VS automatiskt. Vi har också flera team, externa likväl som interna, som arbetar mot vår kod och då blir det väldigt mycket mindre frågor om man har relevanta kommentarer som syns i intellisense.

Gå till inlägget

haha, det du vet inte hur ofta man gör det där argumentet. Faktum är dock att in the end så vinner man tid på att kontinuerligt förbättra koden. Och det är ditt jobb som utvecklare att få management förstå detta.

Vad har intellisense med kommentarer i koden att göra. Man behöver inte köra xml kommentarer för att kunna få det, man lägger det i separata filer. Sedan tycker jag jag ju att även utan de korta texterna man får med intellisense ska koden gå att förstå. Plus, sällan infon i intellisense är tillräcklig ändå, tex

Du kan inte ovan se denna metod är o(n). Men syns mycket bra på wikin

Citat:

This method performs a linear search; therefore, this method is an O(n) operation, where n is Count.

edit: todos, använder jag också, se ursprungsinlägget

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av CyberVillain:

Kommentarer i kod blir ofta utdaterad och irrelevanta då de inte uppdateras när kod ändras,

Gå till inlägget

Även sådana kommentarer är användbara: Om kommentarer inte matchar koden, då vet man att man absolut inte kan lita på att vare sig kommentarer eller kod är korrekt.
Dvs. det är ett tecken på en dålig, slarvig, och/eller lat programmerare.

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av Erik_T:

Även sådana kommentarer är användbara: Om kommentarer inte matchar koden, då vet man att man absolut inte kan lita på att vare sig kommentarer eller kod är korrekt.
Dvs. det är ett tecken på en dålig, slarvig, och/eller lat programmerare.

Gå till inlägget

Jag tar bort alla ouppdaterade kommentarer jag hittar eller som jag finner överflödiga

Jag skrev en kommentar idag.. fyfan.. Tog emot

                    /*

                    Issue #3997

                    Gamla invoice parser/import-koden fixar inte att man jobbar på befintliga fakturor som detta är. Därav retur av tom lista.
                    Detta är en workaround pga att Skandia inte jobbar med TXID på sin återrapportering.

                    */
                    return Enumerable.Empty<IncomingInvoice>();
Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Medlem
●

Allt beror på

jag har jobbat i SIL4 miljö och ner till mer normala hantering av kod.
SIL4 ser man alltid kommenterar ikoden. dock korta kommentarer av typen // <issue id> <utvecklare>

det är en rest från pre git så klart men när man är van så hjälper de dig förstå väldigt mycket.
bra kod behöver oftast ej kommenteras men gör man något speciellt så kan en kommentar hjälpa.

Det som får mig att se rött är däremot

# publika funktioner som INTE är dokumenterade vad de gör ... Dokumentationen blir lidande av detta!

# utkommenderad kod .... den kan vara bra att spara ... *NEJ DET ÄR DET INTE*

# kod som är rörig och inte har någon form av kommentar alls varför. ingen vill spendera 15-30min med att gräva i 30 underfunktioner för att fatta vad egentligen görs med den.

# kod som saknar unittester, det är utvecklarens skyldighet att bevisa att det hen har gjort funkar! det hjälper också förståelsen att kunna läsa testerna.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av CyberVillain:

Jag tar bort alla ouppdaterade kommentarer jag hittar eller som jag finner överflödiga

Jag skrev en kommentar idag.. fyfan.. Tog emot

                    /*

                    Issue #3997

                    Gamla invoice parser/import-koden fixar inte att man jobbar på befintliga fakturor som detta är. Därav retur av tom lista.
                    Detta är en workaround pga att Skandia inte jobbar med TXID på sin återrapportering.

                    */
                    return Enumerable.Empty<IncomingInvoice>();
Gå till inlägget

Det där är ett typexempel på när kommentarer bör användas - när man skriver kod som ser konstig ut, men är det av en bra anledning.

Redigera
Citera flera Citera
Permalänk
Medlem
●

kommentarer

Skrivet av CyberVillain:

Jag tar bort alla ouppdaterade kommentarer jag hittar eller som jag finner överflödiga

Jag skrev en kommentar idag.. fyfan.. Tog emot

                    /*

                    Issue #3997

                    Gamla invoice parser/import-koden fixar inte att man jobbar på befintliga fakturor som detta är. Därav retur av tom lista.
                    Detta är en workaround pga att Skandia inte jobbar med TXID på sin återrapportering.

                    */
                    return Enumerable.Empty<IncomingInvoice>();
Gå till inlägget

Kommentarer ska säga varför koden gör som den gör, inte vad imo. Den där kommentaren tycker jag är ett klockrent exempel på bra kommentar. Kommer man tillbaka om ett år och ska fixa har man säkert glömt det där och om det inte var för kommentaren så kanske man hade lagt ett par timmar på att fixa bara för att komma tillbaka till samma ställe man började på.

edit: Såg att hen ovanför skrivit precis samma sak

Visa signatur

"Say unto thine own heart, I am mine own redeemer"
Don't touch me when I'm crazy of that airplane glue

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av DarkBob:

Kommentarer ska säga varför koden gör som den gör, inte vad imo. Den där kommentaren tycker jag är ett klockrent exempel på bra kommentar. Kommer man tillbaka om ett år och ska fixa har man säkert glömt det där och om det inte var för kommentaren så kanske man hade lagt ett par timmar på att fixa bara för att komma tillbaka till samma ställe man började på.

edit: Såg att hen ovanför skrivit precis samma sak

Gå till inlägget

JO, det där är den enda form av kommenterar jag skriver
edit: Hen är nog en man med tanke på namnet

Visa signatur

Min blogg

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av cg_thi:

Allt beror på

...

# kod som saknar unittester, det är utvecklarens skyldighet att bevisa att det hen har gjort funkar! det hjälper också förståelsen att kunna läsa testerna.

Gå till inlägget

Nja, här skulle jag säga att det beror på. Alla arbetsplatser låter inte utvecklare göra egna unittester, det är som gjort för att bli fel. Det är struntsamma om en utvecklare gjort ett dåligt unittest och produkten felar. Det kommer inte hjälpa att kunna skylla på utvecklaren efteråt. Oberoende testare ger högre kvalitet. Utvecklaren kan göra funktionella tester för att verifiera och bevisa till rimlig grad att det lever upp till krav men det är testarens ansvar att göra slutgiltig verifiering.
Jag har suttit på en plats där jag själv bara hade en begränsad miljö för att verifiera min kod. Det fanns dyr licensierad utrustning som man bara gav till testare, så även om jag testade och allt såg bra ut hittades fel hos testaren sen som jag aldrig kunde se.

Redigera
Citera flera Citera
Permalänk
Medlem
●

På min utbildning (civil. universitetet) är det obligatoriskt att ha beskrivande engelska variabel-/metodnamn samt kommentarer på engelska i koden. Anledningen är att en annan programmerare/lärare ska kunna titta i koden och snabbt förstå vad som sker.

Redigera
Citera flera Citera
1 2 3 4 5 6 7 8
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara