Tråden för oss som programmerar eller sysslar med IT

[eternallord]

Ursprungligen postat av PixelMiner

Som sagt kolla gamla Microsoft interface. Ta till exempel WinMain, som är alla windows programs ingångsport.

int __clrcall WinMain(
  HINSTANCE hInstance,
  HINSTANCE hPrevInstance,
  LPSTR     lpCmdLine,
  int       nShowCmd
);

Här ser man prefixen h för alla variabler som är handles, lp för long pointer string, n för heltal (int).
https://docs.microsoft.com/en-us/win...inbase-winmain

Jag försöker inte säga att det inte funnits bra anledningar en gång i tiden (och kanske fortfarande finns om man behöver tackla uråldrig legacykod eller använda något obskyrt hårdvaru-nära lågnivå-språk), men i dagsläget kodar den absoluta majoriteten i statiskt typade språk där det är helt redundant eftersom typen är deklarerad eller tydlig från funktionssignaturen, eller i moderna dynamiska språk som Clojure som kompetent och smidigt hanterar eventuella konverteringar mellan närliggande datastrukturer så att man så gott som aldrig behöver tänka på det.

[PixelMiner]

Ursprungligen postat av eternallord

Jag försöker inte säga att det inte funnits bra anledningar en gång i tiden (och kanske fortfarande finns om man behöver tackla uråldrig legacykod eller använda något obskyrt hårdvaru-nära lågnivå-språk), men i dagsläget kodar den absoluta majoriteten i statiskt typade språk där det är helt redundant eftersom typen är deklarerad eller tydlig från funktionssignaturen, eller i moderna dynamiska språk som Clojure som kompetent och smidigt hanterar eventuella konverteringar mellan närliggande datastrukturer så att man så gott som aldrig behöver tänka på det.

Håller med om allt du säger!

Ursprungligen postat av Agitator

Håll det kort och koncist där det går och försök undvika överdrivet långa namn. Bättre att lära sig att kommentera sitt stycke kod begripligt.

Bästa är ju när man bara läser kod och ser vad koden gör istället för att fokusera på kommentarerar och massa komplexa namn.

Jag är inte ett jättefan av kommentarer heller. Det finns situationer där kommentarer kan vara nyttiga, men de är få. Om jag känner att en viss kodsnutt behöver en kommentar, så beror det ju oftast på att jag slarvat med koddesignen och uttryckt mig dåligt i kod.

Det här är ett rätt roligt föredrag kring dåliga kommentarer:


Och detta en timme långa föredrag kring namngivning är definitivt sevärt:

[Köttis]

Ursprungligen postat av PixelMiner

Jag är inte ett jättefan av kommentarer heller. Det finns situationer där kommentarer kan vara nyttiga, men de är få. Om jag känner att en viss kodsnutt behöver en kommentar, så beror det ju oftast på att jag slarvat med koddesignen och uttryckt mig dåligt i kod.

Ja, kommentarer för att förklara/upprepa vad koden gör är inte det bästa.

Jag tycker snarare kommentarer ska användas för att förklara varför man valt att göra på ett visst sätt så inte nästa person behöver komma och tänka "varför fan har det här kukhuvudet gjort X och inte Y?". Det svåra i det fallet är väl att avgöra när det behövs och inte. Känner du inte till Y är det ju svårt.

I stora projekt kan det ibland även vara värt att förklara funktionaliteten på ett större plan än vad som är enkelt att se bara genom att kolla på koden.

Är det egna hemmaprojekt är det förmodligen ingenting man behöver bry sig om dock.

Sent from my FRD-L19 using Tapatalk

[Boston]

Det stämmer, Agitator! Engångsutgift för licensen sedan en löpande månads avgift för driften eller vad man kallar det. Jo det finns en manual och jag ska INTE kasta skit på programmet pga mina tillkortakommanden!

Man behöver kanske inte så avancerad kod för att beskriva lutning på medelvärden osv, att beskriva olika mönster i en graf utifrån olika tekniska indikatorer som grundar sig i enklare matematik behöver väl ingen rocket sience kanske.



Jag förstår PixelMiner, blir väl sjukt luddigt när jag bara klippt in en del av scriptet, variabelnamnet eller mer korrekt villkorsnamnet för funktionen make no sense nu.
Började villkor 1 för att sedan jobba upp mig till nr 14 där jag behövde två versioner av nr 14 för att det i slutändan skulle bli sant, var av A, B och C.

Men kritik och input uppskattas!

Som tur är säger programmet vilken rad som är tokig om syntaxen inte fungerar, hehe.

[Agitator]

Du kan ju alltid posta din kod här eller githublänka den och säga vad du försöker göra i det programmet och se om du får några förslag på förbättringar samt kanske någon annan som blir intresserad av programmet och även kan koda lite.

[PixelMiner]

Ursprungligen postat av Köttis

Ja, kommentarer för att förklara/upprepa vad koden gör är inte det bästa.

Ja, hur ofta har man inte sett följande idioti:

/**
 *  GetTransaction
 */
public Transaction getTransaction() { ... }

Ursprungligen postat av Köttis

Jag tycker snarare kommentarer ska användas för att förklara varför man valt att göra på ett visst sätt så inte nästa person behöver komma och tänka "varför fan har det här kukhuvudet gjort X och inte Y?". Det svåra i det fallet är väl att avgöra när det behövs och inte. Känner du inte till Y är det ju svårt.

Jo, håller med om att i vissa specifika fall kan man behöva berätta varför man gjort på ett speciellt sätt. Framför allt när ens kod ser ut ovanlig ut. För egen del är det framförallt när jag gjort hastighets-optimeringar som resulterar i extremt tät och svårläst kod, men där alternativet är att programmet går magnituder långsammare.

Ursprungligen postat av Köttis

I stora projekt kan det ibland även vara värt att förklara funktionaliteten på ett större plan än vad som är enkelt att se bara genom att kolla på koden.

Jo, men då skriver man ju ofta separata designdokument. Jag har själv aldrig varit med om något projekt där man lägger in detta direkt i koden.

Känns generellt som mycket kommentarer som skrevs förr var kopplade till att man saknade bra stödfunktioner som versionshantering, issue trackers osv...

[Brofessorn]

Ursprungligen postat av PixelMiner

Ja, hur ofta har man inte sett följande idioti:

/**
 *  GetTransaction
 */
public Transaction getTransaction() { ... }

Hur hade du kommenterat en sådan enkel getter?

[PixelMiner]

Ursprungligen postat av Brofessorn

Hur hade du kommenterat en sådan enkel getter?

Är det tillåtet att gå över till "utvecklaren" som skrev kommentaren och utdela en rejäl örfil?

Nej? Synd...

[Rickard]

Ursprungligen postat av PixelMiner

Ja, hur ofta har man inte sett följande idioti:

/**
 *  GetTransaction
 */
public Transaction getTransaction() { ... }

Jo, håller med om att i vissa specifika fall kan man behöva berätta varför man gjort på ett speciellt sätt. Framför allt när ens kod ser ut ovanlig ut. För egen del är det framförallt när jag gjort hastighets-optimeringar som resulterar i extremt tät och svårläst kod, men där alternativet är att programmet går magnituder långsammare.



Jo, men då skriver man ju ofta separata designdokument. Jag har själv aldrig varit med om något projekt där man lägger in detta direkt i koden.

Känns generellt som mycket kommentarer som skrevs förr var kopplade till att man saknade bra stödfunktioner som versionshantering, issue trackers osv...

Det finns en dimension av den där superkommentaren.
När man får höra att det finns dokumentation. Som senare visar sig vara just en sån kommentar och funktions deklarationen, utav alla funktioner i programmet.

[Köttis]

Ursprungligen postat av PixelMiner

Jo, men då skriver man ju ofta separata designdokument. Jag har själv aldrig varit med om något projekt där man lägger in detta direkt i koden.



Känns generellt som mycket kommentarer som skrevs förr var kopplade till att man saknade bra stödfunktioner som versionshantering, issue trackers osv...

Ja, så är det. Finns specialfall för allt i princip och man får försöka anpassa sig efter hur det ser ut i övrigt tycker jag så inte din kod är helt utan kommentarer för du tycker det är överflödigt medan resten är ganska välkommenterad. Eller tvärtom.

Sent from my FRD-L19 using Tapatalk

[Brofessorn]

Ursprungligen postat av PixelMiner

Är det tillåtet att gå över till "utvecklaren" som skrev kommentaren och utdela en rejäl örfil?

Nej? Synd...

Är det nyutexaminerade "utvecklare" månntro? När där jag läser fortfarande lärde ut Java var de stenhårda på att varenda metod skulle ha Javadoc, annars fick man underkänt direkt. Vilket ledde till ganska hjärndöda kommentarer på getters och setters. Kanske någon neurotisk newbie som försöker undvika en bassning.

[shut teh face]

Ursprungligen postat av PixelMiner

Är det tillåtet att gå över till "utvecklaren" som skrev kommentaren och utdela en rejäl örfil?

Nej? Synd...

Skulle rekommendera att man pratade med den berörda och gjorde sin åsikt hörd istället.

[PixelMiner]

Ursprungligen postat av Brofessorn

Är det nyutexaminerade "utvecklare" månntro? När där jag läser fortfarande lärde ut Java var de stenhårda på att varenda metod skulle ha Javadoc, annars fick man underkänt direkt. Vilket ledde till ganska hjärndöda kommentarer på getters och setters. Kanske någon neurotisk newbie som försöker undvika en bassning.

Jo, Javadoc har påtvingats många högskolestudenter, så även för mig. Finns givetvis projekt som har bra javadoc, doxygen, ReadTheDocs, eller motsvarande. Men för varje bra projekt så finns det säkert 10 ggr fler dåliga, där beskrivningarna är meningslösa eller än värre fel. Skriver man dessutom bara sådana skitkommentarer som ovan, så går det ju ofta lika bra att strunta i dem. Då många av ovanstående generatorer kan skapa funktionsbeskrivningar automatiskt.

Ju längre jag jobbar desto mer inser jag att de som lär ut programmering på högskolor och universitet har väldigt lite koll på vad som sker i verkligheten. Många av dem har aldrig skrivit kod i ett större system, utan bara konstruerat lite mindre utilities och kodexempel som kanske har några tusen rader kod.

I en del språk så pratar i industrin om "akademisk-stil" för kod som innehåller en massa språktekniska finesser, men som för det första gör koden svårläsbar och för det andra många gånger leder till kod som exekverar mycket långsammare.

[PixelMiner]

Ursprungligen postat av shut teh face

Skulle rekommendera att man pratade med den berörda och gjorde sin åsikt hörd istället.

Självklart! Om ironin inte gick fram, så klargör jag härmed att jag inte örfilar mina kollegor.

[Brofessorn]