Vinnaren i pepparkakshustävlingen!
Du blandar ihop två saker här, eller så är ditt inlägg bara grötigt. Jag kan iaf inte se om det fetmarkerade avser mina två kodrader, eller ditt påstående om att kommentarer är bra för att berätta att en funktion sorterar saker.
Jag vidhåller att du kan döpa din funktion till sort om den sorterar, så behöver du ingen kommentar. Gör din funktion fler saker än sorterar? Då borde du laga din kod, inte skriva kommentarer.
Vad gäller de två raderna kod jag postade så tycker jag inte att de beskriver "vad" funktionen gör, är man intresserad av vad gränsvärdena kan vara så läser man koden, för den går att lita på - till skillnad från kommentarerna.
För det andra får man själv lista ut baserat på hur funktionen verkligen gör det den gör, att caps lock och num lock inte påverkas av den.
Så ja, självkommenterande kod och vettig namngivning gör att kommentarer för det mesta inte behövs. Det är inte alltid sådant räcker. Vi kan ha en funktion som heter sort och alla förstår hur den används (åtminstone efter att de läst på internet hur man skriver en jämförelsefunktion). Vår tangentbordsfunktion däremot är av ett annat slag... Om man nu inte vill kalla den för unstick_unlocked_keyboard_except_caps_lock_and_num _lock. Vilket i och för sig skulle få folk att tänka till, men ändå.
Jag tycker fortfarande att undantagen är implementationsdetaljer, och ert problem verkar snarare vara att undantagen står "någonstans i röran". Rensa upp er kod så att den går att läsa istället, så kan man läsa koden istället för kommentarerna - den går att lita på, till skillnad från kommentarerna.
Saken är alltså inte huruvida koden går att läsa eller ej, utan att användaren behöver läsa kod över huvud taget. God namngivning ja, självkommenterande (dvs. välskriven) kod för den som måste sätta sig in i funktionen för att t.ex. uppdatera den, ja. Men att sitta och läsa kod så fort man ska anropa en okänd funktion istället för att läsa en sammanfattning av vad som sker när du anropar den är slöseri med tid.
Tänk dig en kille som ska använda printf för första gången. Du vill då att han ska sitta och traggla igenom allt detta (minus kommentarer). Istället skulle han kunna kolla kommentarerna och direkt förstå vad han behöver göra och vad han kommer att få ut.
Tester är lättare att underhålla, för de säger till när de är fel, vilket kommentarer inte gör...
Jag är ett fan av testdriven utveckling, och då menar jag verkligen testdriven - inte "skriv några tester i efterhand så att vi får lite coverage att visa för managers". Tiden det tar att skriva och underhålla testsviten sparar du in på att du slipper sitta och debugga en massa fel. Naturligtvis kommer du ändå ha buggar, men betydligt färre.
Att läsa tester är dessutom ett lysande sätt att snabbt sätta sig in i hur koden fungerar och hur den används.
Om du skriver koden så att den är lika lätt att läsa som kommentarerna hade varit så är det väl inget slöseri med tid? Om du inte kan sammanfatta i funktionsnamnet vad den gör så är det förmodligen för att den gör för många saker.
Eller så läser han ett unittest och ser direkt hur han ska använda funktionen.
Att läsa testkod är naturligtvis inte ett "lysande" sätt att lära sig använda en funktion jämfört med att läsa dokumentation, speciellt eftersom testkod ofta lägger mer vikt vid felfallen än korrekta fall, men mer generellt eftersom det ändå handlar om att läsa kod.
printf är ju ett väldigt bra exempel på hur ett unittest inte skulle vara bra jämfört med dokumentation, eftersom koden för ett tillräckligt djupgående test (alltså inte bara "skriv ut en siffra" utan formatering osv.) även den skulle vara svårförståelig jämfört med dokumentation.
Har man en massa getters och setters så bör man nog fundera på att refaktorera om sina datastrukturer till riktiga klasser istället. Buggar i testkoden förekommer såklart också, men jag upplever ändå att antalet buggar på det stora hela är lägre.
Det beror helt och hållet på hur du skriver dina testfall. Det klassiska misstaget folk gör är ju att tänka "nu ska jag skriva en klass som gör x" och sedan skriver de 1..n testfall för alla funktioner i klassen, istället för att skriva sina tester utifrån vilka usecase som finns.
Har man skrivit några test som använder printf med lite olika flaggor och olika antal parametrar så är det inte så svårt att se hur man skulle kombinera dessa för att åstadkomma vad man själv vill göra.
Stöd Flashback
Svara
- Ämnesverktyg
- Hitta inlägg efter datum
Citat:
Grejen är att de där två raderna är ju lätta att läsa, men de är en del av koden. En person som ska använda min kod behöver ju inte nödvändigtvis veta exakt hur den gör saker, bara resultatet som blir när han anropar den (t.ex. "listan blir sorterad"). Då vill han ju inte sitta och läsa igenom funktionen, inte ens de fyra-fem, kanske tio, första raderna för att se vad han inte får skicka in osv. Sådant ska självklart stå i en kommentar ovanför. Det är ett klockrent exempel på vad kommentarer är bra för.
Du blandar ihop två saker här, eller så är ditt inlägg bara grötigt. Jag kan iaf inte se om det fetmarkerade avser mina två kodrader, eller ditt påstående om att kommentarer är bra för att berätta att en funktion sorterar saker.
Jag vidhåller att du kan döpa din funktion till sort om den sorterar, så behöver du ingen kommentar. Gör din funktion fler saker än sorterar? Då borde du laga din kod, inte skriva kommentarer.
Vad gäller de två raderna kod jag postade så tycker jag inte att de beskriver "vad" funktionen gör, är man intresserad av vad gränsvärdena kan vara så läser man koden, för den går att lita på - till skillnad från kommentarerna.
Citat:
Jag tycker att det är märkligt att du inte förstår vad det du fetstilat syftar på. Jag kan ge ett exempel.Du blandar ihop två saker här, eller så är ditt inlägg bara grötigt. Jag kan iaf inte se om det fetmarkerade avser mina två kodrader, eller ditt påstående om att kommentarer är bra för att berätta att en funktion sorterar saker.
Jag vidhåller att du kan döpa din funktion till sort om den sorterar, så behöver du ingen kommentar. Gör din funktion fler saker än sorterar? Då borde du laga din kod, inte skriva kommentarer.
Vad gäller de två raderna kod jag postade så tycker jag inte att de beskriver "vad" funktionen gör, är man intresserad av vad gränsvärdena kan vara så läser man koden, för den går att lita på - till skillnad från kommentarerna.
Jag vidhåller att du kan döpa din funktion till sort om den sorterar, så behöver du ingen kommentar. Gör din funktion fler saker än sorterar? Då borde du laga din kod, inte skriva kommentarer.
Vad gäller de två raderna kod jag postade så tycker jag inte att de beskriver "vad" funktionen gör, är man intresserad av vad gränsvärdena kan vara så läser man koden, för den går att lita på - till skillnad från kommentarerna.
Kod:
Här står lite kommentarer om att något händer med tangentbordet, detta något kommer inte att ske med caps lock och num lock. Dessutom får inte kbd->Device (vilket troligtvis är ett objekt som hanterar själva hårdvaran) vara låst när man skickar det till funktionen. Den som ska använda funktionen behöver inte läsa kod alls, utan behöver bara se kommentarerna och sedan kan han använda funktionen. Jämför med detta:
// unstick_keys - unsticks the keyboard
// note: caps lock/num lock not affected
// note: make sure that kbd->Device is not locked before calling
void unstick_keys(keyboard *kbd)
{
// (kod)
}
Kod:
För det första måste man själv läsa inne i funktionen vad som sker för att ens se att hårdvaran inte ska vara låst. Om man alltid har kontroll av inparametrar skarpt avgränsade mot resten av funktionens kod är ju det bra. Men det kan man inte alltid ha (det kanske inte ens finns en isLocked-funktion i objektet, utan kanske bara andra funktioner som alla kommer att returnera felkoder om objektet är låst), och att se till att sådana kontroller är uppdaterade är ungefär lika påfrestande som att se till att kommentarer är uppdaterade.
void unstick_keys(keyboard *kbd)
{
if(kbd->Device->isLocked())
throw new HardwareLockedException();
// (kod, någonstans inne i röran står tangentkoderna för caps lock och num lock med)
}
För det andra får man själv lista ut baserat på hur funktionen verkligen gör det den gör, att caps lock och num lock inte påverkas av den.
Så ja, självkommenterande kod och vettig namngivning gör att kommentarer för det mesta inte behövs. Det är inte alltid sådant räcker. Vi kan ha en funktion som heter sort och alla förstår hur den används (åtminstone efter att de läst på internet hur man skriver en jämförelsefunktion). Vår tangentbordsfunktion däremot är av ett annat slag... Om man nu inte vill kalla den för unstick_unlocked_keyboard_except_caps_lock_and_num _lock. Vilket i och för sig skulle få folk att tänka till, men ändå.
__________________
Senast redigerad av Diamondgrit 2014-08-11 kl. 17:42.
Senast redigerad av Diamondgrit 2014-08-11 kl. 17:42.
Citat:
Jag tycker att det är märkligt att du inte förstår vad det du fetstilat syftar på. Jag kan ge ett exempel.
För det andra får man själv lista ut baserat på hur funktionen verkligen gör det den gör, att caps lock och num lock inte påverkas av den.
Så ja, självkommenterande kod och vettig namngivning gör att kommentarer för det mesta inte behövs. Det är inte alltid sådant räcker. Vi kan ha en funktion som heter sort och alla förstår hur den används (åtminstone efter att de läst på internet hur man skriver en jämförelsefunktion). Vår tangentbordsfunktion däremot är av ett annat slag... Om man nu inte vill kalla den för unstick_unlocked_keyboard_except_caps_lock_and_num _lock. Vilket i och för sig skulle få folk att tänka till, men ändå.
Kod:
Här står lite kommentarer om att något händer med tangentbordet, detta något kommer inte att ske med caps lock och num lock. Dessutom får inte kbd->Device (vilket troligtvis är ett objekt som hanterar själva hårdvaran) vara låst när man skickar det till funktionen. Den som ska använda funktionen behöver inte läsa kod alls, utan behöver bara se kommentarerna och sedan kan han använda funktionen. Jämför med detta:
// unstick_keys - unsticks the keyboard
// note: caps lock/num lock not affected
// note: make sure that kbd->Device is not locked before calling
void unstick_keys(keyboard *kbd)
{
// (kod)
}
Kod:
För det första måste man själv läsa inne i funktionen vad som sker för att ens se att hårdvaran inte ska vara låst. Om man alltid har kontroll av inparametrar skarpt avgränsade mot resten av funktionens kod är ju det bra. Men det kan man inte alltid ha (det kanske inte ens finns en isLocked-funktion i objektet, utan kanske bara andra funktioner som alla kommer att returnera felkoder om objektet är låst), och att se till att sådana kontroller är uppdaterade är ungefär lika påfrestande som att se till att kommentarer är uppdaterade.
void unstick_keys(keyboard *kbd)
{
if(kbd->Device->isLocked())
throw new HardwareLockedException();
// (kod, någonstans inne i röran står tangentkoderna för caps lock och num lock med)
}
För det andra får man själv lista ut baserat på hur funktionen verkligen gör det den gör, att caps lock och num lock inte påverkas av den.
Så ja, självkommenterande kod och vettig namngivning gör att kommentarer för det mesta inte behövs. Det är inte alltid sådant räcker. Vi kan ha en funktion som heter sort och alla förstår hur den används (åtminstone efter att de läst på internet hur man skriver en jämförelsefunktion). Vår tangentbordsfunktion däremot är av ett annat slag... Om man nu inte vill kalla den för unstick_unlocked_keyboard_except_caps_lock_and_num _lock. Vilket i och för sig skulle få folk att tänka till, men ändå.
Jag tycker fortfarande att undantagen är implementationsdetaljer, och ert problem verkar snarare vara att undantagen står "någonstans i röran". Rensa upp er kod så att den går att läsa istället, så kan man läsa koden istället för kommentarerna - den går att lita på, till skillnad från kommentarerna.
Citat:
Du kan lita på att koden är det som körs, men om det är kod som fortfarande är under utveckling kan du inte vara säker på att invärdeskontroller osv. är korrekta. Speciellt inte om det är sällsynta fall. Jo man kan ha testkod, men sådan är ju ännu jobbigare att underhålla än kommentarer.Jag tycker fortfarande att undantagen är implementationsdetaljer, och ert problem verkar snarare vara att undantagen står "någonstans i röran". Rensa upp er kod så att den går att läsa istället, så kan man läsa koden istället för kommentarerna - den går att lita på, till skillnad från kommentarerna.
Saken är alltså inte huruvida koden går att läsa eller ej, utan att användaren behöver läsa kod över huvud taget. God namngivning ja, självkommenterande (dvs. välskriven) kod för den som måste sätta sig in i funktionen för att t.ex. uppdatera den, ja. Men att sitta och läsa kod så fort man ska anropa en okänd funktion istället för att läsa en sammanfattning av vad som sker när du anropar den är slöseri med tid.
Tänk dig en kille som ska använda printf för första gången. Du vill då att han ska sitta och traggla igenom allt detta (minus kommentarer). Istället skulle han kunna kolla kommentarerna och direkt förstå vad han behöver göra och vad han kommer att få ut.
Citat:
Du kan lita på att koden är det som körs, men om det är kod som fortfarande är under utveckling kan du inte vara säker på att invärdeskontroller osv. är korrekta. Speciellt inte om det är sällsynta fall. Jo man kan ha testkod, men sådan är ju ännu jobbigare att underhålla än kommentarer.
Tester är lättare att underhålla, för de säger till när de är fel, vilket kommentarer inte gör...
Jag är ett fan av testdriven utveckling, och då menar jag verkligen testdriven - inte "skriv några tester i efterhand så att vi får lite coverage att visa för managers". Tiden det tar att skriva och underhålla testsviten sparar du in på att du slipper sitta och debugga en massa fel. Naturligtvis kommer du ändå ha buggar, men betydligt färre.
Att läsa tester är dessutom ett lysande sätt att snabbt sätta sig in i hur koden fungerar och hur den används.
Citat:
Saken är alltså inte huruvida koden går att läsa eller ej, utan att användaren behöver läsa kod över huvud taget. God namngivning ja, självkommenterande (dvs. välskriven) kod för den som måste sätta sig in i funktionen för att t.ex. uppdatera den, ja. Men att sitta och läsa kod så fort man ska anropa en okänd funktion istället för att läsa en sammanfattning av vad som sker när du anropar den är slöseri med tid.
Om du skriver koden så att den är lika lätt att läsa som kommentarerna hade varit så är det väl inget slöseri med tid? Om du inte kan sammanfatta i funktionsnamnet vad den gör så är det förmodligen för att den gör för många saker.
Citat:
Tänk dig en kille som ska använda printf för första gången. Du vill då att han ska sitta och traggla igenom allt detta (minus kommentarer). Istället skulle han kunna kolla kommentarerna och direkt förstå vad han behöver göra och vad han kommer att få ut.
Eller så läser han ett unittest och ser direkt hur han ska använda funktionen.
Citat:
TDD är väldigt bra om det används rätt. Jag har sett både och. Då menar jag inte för liten coverage utan tvärt om: folk som gör tester till get/set. Att ha färdiga tester är väldigt bra både under utvecklingen och när man ändrar/buggrättar. Den enda svagheten hos TDD är väl att det blir mer kod och antalet buggar per kodrad är ungefär konstant (dvs. det uppkommer buggar i själva testkoden). Men som sagt, rätt använd är metoden väldigt bra.Tester är lättare att underhålla, för de säger till när de är fel, vilket kommentarer inte gör...
Jag är ett fan av testdriven utveckling, och då menar jag verkligen testdriven - inte "skriv några tester i efterhand så att vi får lite coverage att visa för managers". Tiden det tar att skriva och underhålla testsviten sparar du in på att du slipper sitta och debugga en massa fel. Naturligtvis kommer du ändå ha buggar, men betydligt färre.
Att läsa tester är dessutom ett lysande sätt att snabbt sätta sig in i hur koden fungerar och hur den används.
Om du skriver koden så att den är lika lätt att läsa som kommentarerna hade varit så är det väl inget slöseri med tid? Om du inte kan sammanfatta i funktionsnamnet vad den gör så är det förmodligen för att den gör för många saker.
Eller så läser han ett unittest och ser direkt hur han ska använda funktionen.
Jag är ett fan av testdriven utveckling, och då menar jag verkligen testdriven - inte "skriv några tester i efterhand så att vi får lite coverage att visa för managers". Tiden det tar att skriva och underhålla testsviten sparar du in på att du slipper sitta och debugga en massa fel. Naturligtvis kommer du ändå ha buggar, men betydligt färre.
Att läsa tester är dessutom ett lysande sätt att snabbt sätta sig in i hur koden fungerar och hur den används.
Om du skriver koden så att den är lika lätt att läsa som kommentarerna hade varit så är det väl inget slöseri med tid? Om du inte kan sammanfatta i funktionsnamnet vad den gör så är det förmodligen för att den gör för många saker.
Eller så läser han ett unittest och ser direkt hur han ska använda funktionen.
Att läsa testkod är naturligtvis inte ett "lysande" sätt att lära sig använda en funktion jämfört med att läsa dokumentation, speciellt eftersom testkod ofta lägger mer vikt vid felfallen än korrekta fall, men mer generellt eftersom det ändå handlar om att läsa kod.
printf är ju ett väldigt bra exempel på hur ett unittest inte skulle vara bra jämfört med dokumentation, eftersom koden för ett tillräckligt djupgående test (alltså inte bara "skriv ut en siffra" utan formatering osv.) även den skulle vara svårförståelig jämfört med dokumentation.
Citat:
TDD är väldigt bra om det används rätt. Jag har sett både och. Då menar jag inte för liten coverage utan tvärt om: folk som gör tester till get/set. Att ha färdiga tester är väldigt bra både under utvecklingen och när man ändrar/buggrättar. Den enda svagheten hos TDD är väl att det blir mer kod och antalet buggar per kodrad är ungefär konstant (dvs. det uppkommer buggar i själva testkoden). Men som sagt, rätt använd är metoden väldigt bra.
Har man en massa getters och setters så bör man nog fundera på att refaktorera om sina datastrukturer till riktiga klasser istället. Buggar i testkoden förekommer såklart också, men jag upplever ändå att antalet buggar på det stora hela är lägre.
Citat:
Att läsa testkod är naturligtvis inte ett "lysande" sätt att lära sig använda en funktion jämfört med att läsa dokumentation, speciellt eftersom testkod ofta lägger mer vikt vid felfallen än korrekta fall, men mer generellt eftersom det ändå handlar om att läsa kod.
Det beror helt och hållet på hur du skriver dina testfall. Det klassiska misstaget folk gör är ju att tänka "nu ska jag skriva en klass som gör x" och sedan skriver de 1..n testfall för alla funktioner i klassen, istället för att skriva sina tester utifrån vilka usecase som finns.
Citat:
printf är ju ett väldigt bra exempel på hur ett unittest inte skulle vara bra jämfört med dokumentation, eftersom koden för ett tillräckligt djupgående test (alltså inte bara "skriv ut en siffra" utan formatering osv.) även den skulle vara svårförståelig jämfört med dokumentation.
Har man skrivit några test som använder printf med lite olika flaggor och olika antal parametrar så är det inte så svårt att se hur man skulle kombinera dessa för att åstadkomma vad man själv vill göra.
Ren diskussion om TDD vore väldigt intressant men det är off topic. Detta däremot är ej det.
Jodå, jämfört med att direkt läsa hur man gör i en bra kommentar (dvs. dokumentation) så är det rätt jobbigt att lista ut hur man gör en viss sak via testfall. Det är ju inte så att du bara läser ett testfall, för att det är kanske inte just det du vill göra. Utan istället vill du göra något som kräver att du läser fyra. Men det finns fjorton testfall och du vet inte vilka du ska läsa. Så du måste läsa alla. Och sitta och klura. Istället för att bara läsa dokumentationen.
Jodå, jämfört med att direkt läsa hur man gör i en bra kommentar (dvs. dokumentation) så är det rätt jobbigt att lista ut hur man gör en viss sak via testfall. Det är ju inte så att du bara läser ett testfall, för att det är kanske inte just det du vill göra. Utan istället vill du göra något som kräver att du läser fyra. Men det finns fjorton testfall och du vet inte vilka du ska läsa. Så du måste läsa alla. Och sitta och klura. Istället för att bara läsa dokumentationen.
Stöd Flashback
Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!
Swish: 123 536 99 96 Bankgiro: 211-4106
