programkodsstil

• Alla namn definierade i din programkod ska vara döpta så att de reflekterar variabelns/funktionens/klassens kontext, syfte och betydelse. Inga k, n, l för nod-idn till exempel.
• DRY, don't repeat yourself. Separera återkommande kodsnuttar eller satser i funktioner. Detta är lite av en balansgång. Om man har counter = 0 på några ställen i koden behöver det nödvändigtvis inte betyda att man separerar det till reset(counter). Om du däremot upptäcker att du behöver en sats till tillsammans med counter = 0 bör du omedelbart tillverka en funktion för det.
• Dela upp filerna så att de reflekterar vilken del av labben de bidrar med. Labb 2, sortering, har med fördel en upddelning i sorteringsalgoritmer, indatagenerering, tidsmätning (med rapportering).
• Håll hierarkin av satsblock så platt som möjligt.
• Använd en stilkonvention i hela projektet. Blanda inte PascalCase, camelCase och snake_case för samma typ av namn.
• Undvik magic numbers.

Magic numbers

if(edge.weight != -1){
    visited[edge.first] = 1;
}

Blir mer lättläst om man istället använder döpta konstanter.

if(edge.weight != NOT_CONNECTED){
    visited[edge.first] = VISITED;
}

Läsbarheten ökar och programkoden blir betydligt enklare att felsöka och underhålla. Tänk på att i 9 fall av 10 spenderar du väsentligt mycket mer tid på felsökning än på att skriva programkod. Lär dig använda din debugger.

QOTD: "The problem with magic numbers is when they are magic" - whatsisname

Att göra blöt programkod torr

if(neighbours.count() > 1){
    addToStack(neigbours);
    mark_visited(current_node);
    visit(neighbours[0]);
}else{
    if(neighbours.count() == 1){
        mark_visited(current_node);
        visit(neighbours[0]);
    }else{
        mark_visited(current_node);
    }
}

Problemen här är liknande idéer utryckta på tre olika ställen, samt att vi har ett djup 3 i satsblocken/indenteringen. Genom att välja en lämplig styrsats. Vi lägger märke till att koden ovan uttrycker 2 distinkta fall neighbours.count() == 0, neighbours.count() == 1 och ett allmänt fall. en switch-sats kan vara lämplig.

switch(neighbours.count()){
    add_to_stack(neighbours);
case 1:
    visit(current_node);
case 0:
    mark_visited(current_node);
}

Namnet på funktionen add_to_stack polerades lite också. Man kan hävda att switch-konstruktinoen i sig är svårläst, men det är min hållning att man ska vara välbekant med alla vanliga språkliga konstruktioner, switch/case är inget undantag. Vi har åstakommit torr programkod, plattat till hierarkin och sett till att vi använde samma konvention för funktionsnamn, snake_case. 0 och 1 i det här exemplet är inte att betrakta som "magic numbers". Att introducera NO_NEIGHBOURS och ONE_NEIGHBOUR förenklar ingenting.