Skriva ut array, varför inte bara på ett sätt?

[arvidb]

Fast kan man språket så är det ju mycket mer läsbart att skriva

Kod: Markera allt

int x[10] = {};

än att deklarera variabeln oinitialiserad och sedan på något annat ställe skriva flera rader kod för att initialisera arrayen. Koden ska förstås vara korrekt (inte ge kompilatorvarningar till exempel), men mer kod blir inte automatiskt mer lättläst. Tvärt om, oftast (om man inte drar det till extremer som i "obfuscation"-tävlingar eller liknande).

[Nerre]

Det är där du gör misstaget, det handlar inte om att kunna språket, det handlar om att skriva tydligt.

Det är samma sak med svenska språket. Byråkratiska texter är oftast helt korrekt svenska, men de är inte särskilt enkla att läsa.

Med en sån där deklaration så är det i alla fall i mina ögon ganska sannolikt att nån i framtiden säger "Ja just ja, jag tänkte inte på den initieras med nollor".

Men visst, man kan lägga in en kommentar istället som förklarar det. Problemet bli när kommentaren och verkligheten inte stämmer överens, och nån tror på vad kommentaren säger. (I just det där fallet är det ingen direkt risk, men det finns gott om andra tillfällen.)

Genom att skriva koden övertydlig behöver man inte ha lika mycket kommentarer, och framförallt behöver man inte ha kommentarer som talar om vad koden gör (för det syns). Risken med en kommentar som talar om vad koden gör är att man missar att ändra kommentaren om man ändrar koden.

[Mr Andersson]

Samma sak t.ex. med casting, ska man skriva tydlig kod så ska all casting vara explicit.

Det tycker jag blir onödigt övertydligt. Din regel skulle inte tillåta t.ex. char i = 0; då det är en automatisk cast från int till char.
Inte ens gcc med -Wpedantic varnar för det.

Jag tycker hellre man ska använda implicita casts så långt det går för att inte åsidosätta kompilatorns egna kontroller.
Ta t.ex. char i = 128; // implicit int to char. Det ger en varning om overflow.
Men char i = (char)128; // explicit int to char tar bort varningen.

Om 128 är ett feltryck som egentligen skulle vara 28 så har du en helt tyst bugg där. Utan cast hittar kompilatorn det direkt.

[Krille Krokodil]

Har jag 10 000 element och vill visa i koden att de är initierade till 0 så gör jag en loop som intierar dem. Även om loopen är helt onödig ur funktionssynpunkt, så är den nödvändig ur läsbarhetssynpunkt.

Samma sak t.ex. med casting, ska man skriva tydlig kod så ska all casting vara explicit.

Som allergisk mot sega system så försöker jag aldrig göra några operationer i onödan och jag kan inte komma
på när jag behövde initiera en array på det sättet "bara för att". Om man är begränsad i minne eller CPU-kraft så
kan där finnas en anledning att göra så men annars så borde det finnas mer eleganta lösningar.

I C går man nog vilse i sin pannkaka om man inte gör "explicit cast" men i C++ (och andra OO-språk) där man
kan definiera sina "casts" entydigt så kan det vara en fördel för tydligheten att gömma undan dem nere i källaren
i väl beprövad kod som man sedan kan tömma ur arbetsminnet (mellan öronen).

[Krille Krokodil]

Tvärt om, oftast (om man inte drar det till extremer som i "obfuscation"-tävlingar eller liknande).

Den tävlingen har väl geniet Adam Dunkels redan vunnit i alla kategorier för all framtid med Protothreads
så där finns väl ingen anledning att tävla mer i det. Totalt obfuscate:rat & totalt nyttigt användbart, hur slår man
det? http://dunkels.com/adam/pt/

[Mr Andersson]

Jag håller med om att ifall man måste skriva kommentarer som förklarar vad koden gör är den för komplicerat eller dåligt skriven. Däremot måste man nog kunna förvänta sig att den som ska läsa koden har grundläggande kunskaper i språket. (Om inte syftet med koden är just att lära ut språket, då kan man vara övertydlig)
Kommentarer ska istället förklara varför man gör saker på ett visst sätt.

Kod: Markera allt

init1(); // initialize adc
init2(); // initialize timer

Skitdålig kod.

Kod: Markera allt

init_adc();
init_timer();

Bättre.

Kod: Markera allt

/* The ADC needs to be initialized before the timer
   because the timer interrupt reads analog values. */
init_adc();
init_timer();

Ännu bättre.

[Nerre]

Som sagt var, även om man kan språket är det lätt att göra tankemissar.

Poängen med att skriva övertydlig kod är just att det ska vara övertydligt så man undviker tankemissar, eller att nån som granskar koden direkt kan se tankemissarna.

Både MISRE och MITRA kräver t.ex. explicit initialisering innan en variabel används.

[Palle500]

Håller med Nerre till 100%
Är så enkelt att skriva snygg kod som förklarar vad man vill åstadkomma.
Initdel i början eller ett funktionsanrop som fixar detta i en funktion. och bra kommentarer är guld värd.
Kolla bara på all gratis kod för tex arduino ofta riktigt trevlig kod.

[TomasL]

Det finns ju en anledning till att kommentarerna och dokumentationen inom jpl är typ 100 ggr större än koden i sig.
Vill man skriva så buggfri kod som möjligt skall varje kodrad förklaras oavsett hur trivial den till synes verkar vara.

[TomasL]

Håller med Nerre till 100%
…..
Kolla bara på all gratis kod för tex arduino ofta riktigt trevlig kod.

Det gäller i princip all gratiskod, och även majoriteten av köpta bibliotek, tyvärr.

[sodjan]

Tomas, du får nog läsa vad Palle500 skrev en gång till.
Jag tror inte inte alls att du håller med, baserat på dina
tidigare inlägg i samma ämne...

[svanted]

betyder det att en person inte kan skriva buggfri kod?
alltså utan att den granskas och avlusas av flera andra.

[johano]

Jag håller med om att ifall man måste skriva kommentarer som förklarar vad koden gör är den för komplicerat eller dåligt skriven. Däremot måste man nog kunna förvänta sig att den som ska läsa koden har grundläggande kunskaper i språket. (Om inte syftet med koden är just att lära ut språket, då kan man vara övertydlig)
Kommentarer ska istället förklara varför man gör saker på ett visst sätt.

Håller med till 100%!

Kod: Markera allt

init_adc(); // initialize adc
init_timer(); // initialize timer

Riktigt skitdålig kod.

Jag tar tusen gånger hellre helt okommenterad kod än för mycket kommenterad.
Värst är såklart felkommenterad som lätt uppstår när man har massor med kommentarer om precis varenda rad och man sen börjar göra
ändringar & fixar

Kod: Markera allt

const int WAIT_ONE_HOUR = 2*60*60; // 1 hour in seconds

Sämst kod

Jag lever efter "the code is the documentation"

[Mr Andersson]

Det finns ju en anledning till att kommentarerna och dokumentationen inom jpl är typ 100 ggr större än koden i sig.
Vill man skriva så buggfri kod som möjligt skall varje kodrad förklaras oavsett hur trivial den till synes verkar vara.

Jag vet inte om man kan ha JPL som förebild för välkommenterad kod.
Länk. Tog en slumpmässig fil från deras open source rover. 6 kommentarer på 372 rader. Och ingen av dem är förklarande; det är bara bortkommenterad kod.

Måste man förklara varenda rad då är koden dåligt skriven.
Eller menar du allvarligt att du skriver sån här kod?

Kod: Markera allt

int x = 3; // initialize x to 3
y = 7; // assign 7 to y
++z; // increase z by 1

Bra kod är självdokumenterande.

Kod: Markera allt

for(int i=0; i<sizeof(tmrs)/sizeof(*tmrs); ++i)  {
  disable_int(tmrs[i]);
}

Skriver man kod liknande ovan förstår jag att man tycker att kommentarer ska finnas överallt. Helt omöjligt att förstå vad som händer.

Kod: Markera allt

for(auto timer : running_timers) {
  timer->disable_interrupt();
}

Ingen kommentar behövs för att förklara att man stänger av interrupts för alla startade timers.
Då skriver man istället en kommentar om varför man måste stänga av interrupts just här.
Ett kommentar-block ovanför loop-blocket. Att kommentera varje rad individuellt är bara ordbajseri som sänker produktiviteten och skapar frustrerade programmerare.

[Icecap]

Jag brukar skriva först i ett funktionsblock VAD som ska lösas.
Är det sedan så att det utförs svårtolkade operationer, t.ex. avancerat bitmanipulation eller liknande skriver jag kommentar om vad tusan som utföras och evt. formeln för det.

Men ett bra program ska hälst vara självförklarande.