Bästa sätt att lämna sin kod i för att lättast kunna fortsätta senare?

Brukar lämna en kommentar längst upp i source med allt som ska göras.

Börjar med att skapa interface på högsta abstraktionsnivån. När jag sedan ska börja implementera så lämnar jag alla metoder tomma från kod men lämnar istället TODO-kommentarer tills jag hunnit implementera dem.

På så sätt blir det "omöjligt" att glömma saker, och programmet växer på ett (enligt mig) hanterbart sätt.

Brukar ha massa kommentarer i koden och TODO-kommentarer ovanför varje metod som inte är färdig... Om jag måste lämna en metod halvfärdig ser jag till. att skriva en kommentar där jag var om vad det var jag höll på med eller tänkte på...

Klassikern är väl att lämna ett par kompileringsfel där man vet att man ska fortsätta/behöver förbättra koden. Då missar man det garanterat inte dagen efter :). Så gör jag alltid när jag går på lunch och har något ofärdigt.

Beror på situation. En grundregel är att man aldrig någonsin ska checka in något som ej är körbart och absolut inte ej kompileringstid saker. Även om man arbetar själv så ska man aldrig gå ifrån denna regel och det kan mycket väl hända att man behöver ändra en helt annan del av sitt program.

Så det jag gör är såklart att skriva en så kortfattat och tydlig kommentar jag kan. (tyvärr ofta inte tillräckligt bra, något jag behöver träna på) Därefter fattar jag beslutet om koden ska checkas in eller bli en "shelve". I kommentaren anger jag vad som har ändras och eventuella brister. Dumt är inte att ha någon versionshistorik i filen. Det är inte så ovanligt på hobbynivå att man skriver kommentarer över varje funktion.
Hur "proffsen" gör vet jag inte, då jag ej jobbar i större projekt med vanliga språk.

i vilket fall så bör man använda versionshanterare typ från dag 1. Git är en enkel och gratis lösning.

*edit'

Angående lämna tomma metoder så kan det skapa huvudbry för folk som implementerar ens klasser och har stora problem att få någon metod att utföra det som den enligt sitt namn utger sig för att vara. Så mitt tips är att lära sig hur "proffsen gör" och apa efter. Tyvärr så har de flesta som mig inte tid att lära sig hur man borde göra utan vi gör en lösning som knappt fungerar, jobbar man in mindre projekt så kan det gå ändå.

På jobbet försöker vi skriva enhets/integerations-tester först. Om man ger testerna bra namn och skiver dem tydligt får man en rätt bra känsla för vad som är kvar att göra bara genom att läsa igenom de tester som fortfarande failar.

Jag brukar skriva kommentarer i koden samt komplettera detta med https://trello.com/. Ett mycket smidigt verktyg för att ha koll på vad som ska göras och vad som är gjort, det är mest anpassat för teams men fungerar lika bra om man är ensam. Organiserat kaos är den röda tråden när jag programmerar

De där två sakerna i kombination är så jag försöker jobba när jag lyckas avhålla mig från okynneskodande.
Man sätter upp enhetstester (eller integrationstester beroende på projektets storlek) som inte kan lyckas. Sedan tar man ett misslyckat test och skriver det så att det kan lyckas. Sedan skriver man koden så att det lyckas och så tillbaka till ett misslyckat test. Upprepa tills klar eller okynneskodardriften tar över.

När det gäller själva koden så föredrar jag gigantiska variabelnamn som beskriver vad koden gör framför kommentarer. Det och så små kodblock som möjligt. När man sitter med en loop i en switch i en loop så bör man rygga tillbaka. Det blir jobbigt att underhålla annars.

Det här svaret på SO förklarar det bra: http://stackoverflow.com/a/2697810

Jag kanske bör nämna att mitt tillvägaggångssätt med "tomma" metoder gäller bara så länge endast jag själv jobbar med koden. Jag låter inte någon annan ta vid där jag slutat utan att tydligt markera vad som saknas (t.ex. kasta exception som förklarar vad som borde hända istället)