[Conny Westh]

Ursprungligen postat av jayzee

Personligen har jag ingen PDF att referera till, har professionellt jobbat med både front- och backend i 10+ år (bla. på Opera Software där jag fortfarande har väldigt bra kontakter) så det mesta sitter i ryggmärgen

Här är dock några bra länkar:
https://developers.google.com/speed/...es/rules_intro
http://isobar-idev.github.com/code-standards/
http://taitems.github.com/Front-End-...nt-Guidelines/

(OBS!!! Såg att när jag har mer än ett mellanslag i rad eller tab ('\t') klipps dessa bort i mitt inlägg så källkoden jag skrivit in blir helt sjuk i inlägget, men den ser bra ut i editläget)

Jag såg på githubben att de hade en rekommendation som jag tycker är helt fel. Som jag vill kommentera.

Måsvingar ska alltid stå på egen rad när man markerar block, för att det er en tydlig linje för ögat att följa. I den ursprungliga boken om K&R C så skrevs måsvingarna på det dåliga sättet men Kernigan själv ändrade denna standard när han skrev boken om ANSI C.

Det var enmycket logisk och begriplig ändring därför att det är hart när omöjligt att följa strukturen i koden om man måste flacka med blicken till slutet på en rad för att hitta en matchande måsvinge.

På githubben så had eman motsatt rekommendation och det motsätter jag mig bestämt.

Enkelt exempel:

// Dåligt
if (foo){
bar();
}

// Bra
if (foo)
{
bar();
}

Mer komplext exempel:

// Dåligt
if (foo1){
bar1a();
if (foo2){
if (foo3){
bar3a();
}
else{
bar3b();
}
}
else{
bar2b();
}
}
else{
bar3b();
}

// Så här blir betydligt bättre...
if (foo1)
{
bar1a();
if (foo2)
{
if (foo3)
{
bar3a();
}
else
{
bar3b();
}
}
else
{
bar2b();
}
}
else
{
bar3b();
}

// Se den tydliga linjen för ögat.....
if (foo1)
{
| bar1a();
| if (foo2)
| {
| | if (foo3)
| | {
| | | bar3a();
| | }
| | else
| | {
| | | bar3b();
| | }
| }
| else
| {
| | bar2b();
| }
}
else
{
| bar3b();
}

Använd alltid måsvingar för att markera vilka block. Det är ett extremt vanligt problem att man missar att lägga till måsvingarna när man lägger till en rad i koden och då får man inte den funktionalitet man önskat. Samtidigt är det betydligt svårare att snabbt öga igenom en kod och frstå vad den gör om man använder olika "format" för att skriva sin kod, var konsekvent och använd alltid måsvingar.

// Dåligt
if (foo)
bar();

// Bra
if (foo)
{
bar();
}

Det finns ett undantag och där är om man har extremt många korta oberoende if satser (som i sig inte kan ersättas av switch/case) som i detta exempel:

// Dåligt!
if (foo1) bar1();
if (foo2) bar2();
if (foo3) bar3(); bar7(); // bar7() Kommer alltid att exekveras,
if (foo4) bar4(); // men det är lätta att missa det.
if (foo5) bar5();
if (foo6) bar6();

// Ok! men inte idealiskt.
if (foo1) bar1();
if (foo2) bar2();
if (foo3) bar3();
if (foo4) bar4();
if (foo5) bar5();
if (foo6) bar6();

Men såna här villkorssamlingar är inte så vanliga och man ska använda dem med försiktighet. För lägger man till en sats till på samma rad så kommer den alltid att exekveras och det var kanske inte vad man tänkt.