TODO: Løse problemet

I tillæg til Dijkstras klassiske udtalelse “Gotos considered harmful”, kan vi så ikke lave en tilføjelse? “TODOs considered harmful”. Efter i mange år at have lavet kode - og kigget i andres kode - er jeg efterhånden kommet til den konklusion, at man ofte gør mere skade end gavn ved at skrive en TODO; mestedelens fordi man sjældent kommer tilbage og gør noget ved den TODO i tide.

En TODO-kommentar kan føre til, at man med mere sindsro, end man egentlig har belæg for, efterlader et hack - nu har man jo ligesom gjort opmærksom på det, ikk’?! Så den næste der læser koden ved godt, at man ikke er så dum, som éns kode ser ud til:

// TODO: This is a serious hack. Find a neater and more generic way to delegate method calls to the customizer
Hvis det er så alvorligt, burde man så ikke have taget tyren ved hornene med det samme?

// TODO: Could be better than this!
Jaeh... Og hvad skal vi så bruge den oplysning til?

// REVIEW(Developer XX): This is highly suspect

Det havde måske været nemmere at gå ind på kontoret ved siden af og gøre ham opmærksom på problemet, end at efterlade en kommentar i koden og håbe på, at han en dag falder over det.

Nogle TODOs er også svære at forstå, måske endda modstridende:

// TODO: Throw error instead. Probably not a good idea to throw errors, since this is the error reporting channel
Hva’?
Men så kan det jo være, at der kommer en og laver en tilføjelse til den TODO, ikke at nogen af os bliver klogere af den grund...:

// TODO: with recursive document writes, this may not be the original document.write.
- Developer X: What does this mean?

Nogle gange får man indtrykket af, at det at skrive en TODO-kommentar kan have mere karakter af at bede til tandfeen om et godt råd. Især når der skrives kommentarer i kode, der er oprindeligt er lavet af udviklere, der ikke længere er i virksomheden eller på det pågældende projekt - hvem er det så lige, man tror, der vil svare?

// TODO: what happens here?

Nok bedre at bruge en livline i dette tilfælde.

Hvis man endelig skal skrive TODOs, så bør det være klart, hvilket projekt, de hører til, og hvornår de forventes at være løst, og sørge for at følge op på dette - eksempelvis er det så trist at finde TODOs à la

// TODO: Remove before release

laaang tid efter releaset...

Og når du en dag rammes af en bug, der viser sig at føre tilbage til en TODO - måske endda en, du selv har skrevet - så er det altid noget, hvis der er en lille smule humor at finde:

// TODO: A special case, I left it unspecified (for you to fix)

// TODO: Cite(Developer X): “Exotic error”
(den kan han så passende hænges op på et par år senere)

;-)

Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Krogh Andersen

Det lyder mere som om der mangler en politik for hvad man bruger TODOs til?
Efter min mening kan man med fordel anvende dem til at huske op noget, som skal løses, men som der ikke er tid til, eller mulighed for pt. (Den der kan hjælpe er på kursus, er syg el. lign).
Flere IDE'er kan oveni købet hjælpe med at kategorisere og overskue TODOs (så der fx. kan benyttes REVIEW/FIXME o.lign i stedet for TODO).
Politiken må vel være at visse type TODOs skal være væk inden release?
Mht. forfatter, så bør man vel skrive sine initialer ved en TODO, så andre slipper for at kigge i scm historikken..

  • 1
  • 0
Christian Schmidt

Opgaver bør som minimum oprettes i en bug-tracker og ikke udelukkende indsættes som kodekommentarer hist og her. I en bug-tracker er der bedre plads til at beskrive problemet, og løsningsforslag kan diskuteres, og frem for alt bliver problemet synliggjort, så det kan prioriteres blandt andre opgaver.

  • 0
  • 0
Morten Krogh Andersen

Jeg mener at det giver unødig støj i en bugtracker, at have opgaver á la "spørg lige Christian om det her ved lejlighed" i en sådan. Det vil til gengæld passe fint i en todo imo.
Desuden kan det have en stor værdi at spørgsmål/opgaver er uadskilleligt fra koden. Dette betyder dog ikke at man ikke også kan repræsentere en opgave i en bugtracker.

  • 0
  • 0
Johnny Fribert Lauridsen

Jeg må sige at jeg er enig med Poul-Henning. Og, tilføj 'NOTE:' til listen. Jeg grep'ede lidt på noget kode jeg begik i starten af halvfemserne, og her er en smagsprøve på ting som aldrig blev taget op igen. men som jeg håber de der overtog koderne fik glæde af senere ;-):
/* NOTE: We may have memory leak somewhere here /
/
NOTE: NEED TO CUT AROUND THIS AND MOVE TO APPROPRIATE PLACE. /
/
NOTE: MOST FROM INFO, BUT I'LL SPICE THIS LATER WITH EXPERIENCES. /
/
NOTE: This might be wrong. It is also stated that rfc1323 extras is 8.../
/
NOTE: NEXT 3 LINES TO BE USED ONLY FOR SOME DAYS ON PROD. TESTS. /
/
NOTE: REMEMBER OOB DATA AND SNA EXPEDITED FLOW AND SO FORTH... */
og desværre mange flere...

  • 1
  • 0
Morten Hattesen

Opgaver bør som minimum oprettes i en bug-tracker og ikke udelukkende indsættes som kodekommentarer hist og her...

Det tager typisk 20 sekunder at skrive en TODO kommentar men 5 minutter at oprette et issue, så konsekvensen af at kræve, at der oprettes et issue i issue/bug tracking systemet hver gang man indsætter en TODO/FIXME i source koden er, at en størstedelen af TODOs ikke bliver dokumenteret overhovedet, eller måske på en post-it på udviklerens skrivebord.

For alt i verden: gør det let at dokumentere mangler, og stil krav om, at der i en release til produktion/test ikke må forekomme TODOs i source koden, men at de skal fjernes eller overføres til en issue tracker.

  • 0
  • 0
Kaj Bonfils

Ofte er der et behov for at huske at ændre noget senere, eksempelvis fjerne hardcodede værdier som er indsat indtil de rigtige værdier kan hentes etc.. Men i stedet for todo's som jo netop kan s i koden i årevis uden at nogen ændrer det, kan man passene lave en warning i koden. Den bliver fanget af compileren - og vil Sætter jo alle "Treat warnings as errors" når vi laver release compile ikke?

Uncle bob har skrevet en række bøger, f.eks. clean Code, hvori ham plæderer for at alle kommentarer i koden er et tegn på at der er noget galt med koden. Enten strukturen eller navngivningen. Og jeg er tilbøjeæig til at give ham ret, selvom det kan være svært at undgå indimellem.

  • 0
  • 0
Morten Andersen

Jeg synes TODO's er fine, hvis man vel at mærke scanner sin kode igennem den og retter dem INDEN man leverer noget til produktion. Det indebærer løbende at checke for om man har nogen tilbage så der ikke er for store overraskelser til sidst.

Tilgengæld kan man spare en masse tid, idet man kan komme videre med nogle ting selvom man venter på noget andet osv. Og en TODO er jo langt bedre end alternativet: Nemlig ikke at skrive en kommentar! Så af alle onder synes jeg en TODO er en god ting -- det svarer jo bare til en huskeseddel, men dog placeret det sted den vedrører, i koden.

  • 0
  • 0
Morten Andersen

Et andet problem jeg har bemærket er at folk ofte retter selve fejlen/manglen men glemmer at fjerne TODO kommentaren! Det er ikke så smart for den næste der læser koden, og prøver at gennemsue hvad der skulle være galt.

  • 0
  • 0
Kaj Bonfils

Der er da fint hvis du kører med warnings as errors mens du udvikler. Men jeg mener ikke det har den store relevans, da der ofte vil være legale warnings mens man er i en udviklingsfase, jf min kommentar. Det der er vigtigt i min optik er, at de ikke slipper igennem release.

Om du syns det er dumt, må stå for egen regning.

  • 0
  • 0
Kaj Bonfils

Der er da fint hvis du kører med warnings as errors mens du udvikler. Men jeg mener ikke det har den store relevans, da der ofte vil være legale warnings mens man er i en udviklingsfase, jf min kommentar. Det der er vigtigt i min optik er, at de ikke slipper igennem release.

Om du syns det er dumt, må stå for egen regning.

  • 0
  • 1
Allan S. Hansen

I den ideelle verden - jo.
I den praktiske og virkelige ... ehh - virkelighed - mange sidder i, så er det nemmere sagt end gjort når ting skal pushes gennem et produktionsmiljø for at være rentabel.
Alle løsninger kan ikke altid være perfekte i en uperfekt verden. Men det er en dejlig drøm og en god retningslinie.

  • 1
  • 0
Morten Hattesen

Hvorfor tager det så lang tid at oprette et issue? Det lyder som et meget omstændeligt system, du bruger.

Jeg bruger, og har brugt, Jira, Bugzilla, Google Code m.fl. til issue tracking. Det er ikke systemet der gør processen langsom. Det er konsekvensen af, at når du skal dokumentere et issue uden at have en direkte relation til kode-konteksten skal du ud over at skrive TODO kommentaren også beskrive konteksten (source fil/klasse, metode, og beskrive indgående hvad der mangler på hvilke steder. Ellers har du en løsrevet TODO i et separat system, som INGEN vil kunne relatere til nogen kode og løse.

Hvis der på den anden side er nogle TODO's som ikke relaterer til source kode (fx "vi skal huske at udarbejde en unit-test der verificerer ....", så forankres den i Issue tracking systemet, og så tager det kun 30 sekunder at oprette det).

Håber det giver mening.

  • 1
  • 0
Christian Schmidt

Ok, jeg forstår.

Jeg tror dog, at man ved at slække på formkravene til issues kan reducere tidsforbruget. Evt. bare copy-paste af det relevante stykke kode og en sti til filen som erstatning for eller supplement til en inline TODO-kommentar. Det er selvfølgelig et issue i telegramform, som ikke er selvforklarende for andre end udviklere, og den slags regnes måske som uacceptabelt visse steder. Men det er trods alt ikke mindre uddybende end en to-linjers TODO et sted i koden. Evt. kan man give issuet et "TODO"-tag, så udenforstående kan se, at det er en kodeoprydningsopgave, og for at signalere, at formkravene til den type issues er mindre end ellers.

En TODO-opgave er jo typisk ikke en lille opgave, der er overstået på et øjeblik (hvis den var det, ville man jo som regel have løst den med det samme). Derfor virker det optimistisk at tro, at opgaven nogensinde bliver løst, hvis den ikke bliver prioriteret og får afsat tid til at blive løst, og det kræver, at der gøres opmærksom på den andre steder end i koden.

Hvis man ikke nævner sine TODO's andre steder end i selve koden, risikerer man så ikke bare at slæbe rundt på dem til evig tid?

  • 0
  • 0
Log ind eller Opret konto for at kommentere