Hej,

Slängde ihop en liten artikel (eller notis) ang kommentera kod. Många här (om jag förstått det rätt) är intresserade av att skriva snyggare kod, bli av med spaggettit och få bättre stuktur i arbetet. Jag har tidigare skrivit en liten krönika om den vanligaste metoden ang Refactoring, ett steg i rätt riktning för snyggare kod. Pga tidsbrister m.m. har jag inte kunnat skriva roliga och intressanta saker här på Pelles sida eller någon annanstans. Tack vare min blog kan jag nu kasta upp lite idéer, tankar, synpunkter m.m.
Skall försöka få upp mer krönikor här, men då Pelle verkar vara väldigt upptagen händer det inte så mkt. Men hoppas höra av honom snart. Tillsvidare får jag hänvisa till min blog.
Länken nedan handlar lite om lite sämre vs bra programmerare i mitt synsätt, jag hoppas texten sätter snurr i era tankar och att ni kommer med fler frågor och synpunkter ang ämnet.

http://www.nsquared2.net/Johan/viewpost.aspx?PostID=26

Besök gärna: http://www.nsquared2.net Ej klar, men är i analysstadiet, Vi vill fånga folkets intresse och se vad de vill lära mer om innan vi vet vad vi skall presentera där. Men jag lovar det kommer bara handla om intressanta saker kring, arkitektur, struktur m.m. Områden som exempelvis 2XSunblad blundar för, områden de oftast klandrat. Men som vetyder så mkt mer än tabel modellen.
Jag och min bror hjälper även Microsoft Patterns & Practices (PAG), vi hjälper dom med review och ger dem synpunkter och idéer inom olika områden. Vi ger även feedback angående ASP.Net 2.0 till .Net teamet, som har gett ett possetivt resultat. Jag vill även passa på och säga tack till er alla som kommit med snälla komplimnager och beröm över vårt arbete, med att både hjälpa er och aggera bollplank. Det är uppskattande och kul. Tveka inte om ni har fler frågor eller idéer. Tänk på, vi är inte bäst, långt ifrån men vi har idéer som tar oss nära.

Mvh Johan och Fredrik Normén

Så sant så sant!
Tyvärr stöter jag dessutom ofta på kod som inte beskriver sig själv som dessutom är okommenterad!
Brukar i all hast sätta mig och skriva om den koden (om jag ser att det går snabbt) om jag ändå är inne och modifierar just den koden. Brukar ofta så att säga städa upp efter andra.

Det är just också ett problem. Att skriva massa kommentarer brukar oftast vara tecken på dålig kod. Men om man inte lyckas förklara koden utan kommentarer har du ett ännu större problem. Det finns ingen deoderant (kommentarer som försöker dölja den dåliga koden) som försöker dölja lukten, det stinker och man mår bara dåligt. Ett stort problem vi tyvärr har... Det gäller då att man på nått sätt försöker hjälpa dem som skrivit den dåliga koden att tänka om. Av min erfarenhet dock svårt. För de som skrivit den kanske förstår det ut och innan, för att det är deras dialekt.

Mvh Johan

37 personer har hitils tittat in här. Men bara en har skrivit? Varför?
Håller ni med? Håller ni inte med?
Eller kan ni för lite om ämnet för att ha en synpunkt? Skriv gärna på vad ni tycker och tänker.
Var inte rädda. Argumentationer leder bara till visdom inte tvärt om...

Vi är många som skriver för vi vill ha feedback och diskussioner runt det vi pratar om. Annars blir det lätt att vi tröttnar, och inte orkar eller har lust att skriva något alls. Så vill vi väl inte ha det?

Mvh Johan

Jag är nog fel person än så länge egentligen att reflektera detta på allvar. Jag fick 3 böcker och en månad på mig att lära mig asp.net på mitt jobb och utvecklar nu olika applikationer åt företaget sen i mars. Tycker det går ganska bra. För mig är kommentarer ganska viktigt på de kodbitar som jag inte använder så ofta. Då är det lätt att gå tillbaka och se vad man gjorde, men det ska inte vara för mycket kod. I en fil har jag kanske totalt 1% av raderna som är kommentarer (på 100 rader kod blir det ca 1 rad kommentar). Vet inte om det är för mycket eller för lite, men när jag blivit mer van och kan mer så ska jag gärna reflektera över artikeln igen, eftersom den är intressant :)

jo, jag tycker väl att du har en liten poäng i vad det är du skriver men du kan ju aldrig veta om en person tänker likadant som du själv gör. Det som är självklart för mig behöver inte vara självklart för dig, och tvärtom, trots att båda är "bra" programmerare.

Framförallt tycker jag det är bra att man t.ex. beskriver vad man anser att en metod gör, hur skall man annars kunna validera att metoden gör rätt? om du med ord beskriver vad du anser att en metod gör så kan du ju validera den förklaringen mot vad koden gör. Stämmer inte en av dem får man revidera.

Själv anser jag att jag skriver ganska enkel kod, med förklarande namn på variabler metoder etc, och ändå tycker jag det är svårt att få grepp om vad man tänkte när man skrev en viss metod. Det är ibland t.o.m så att jag testar saker som jag anser skall fungera för att sedan inse att jag redan testat samma sak i samma metod några månader tidigare, då hade ju varit bra om man hade dokumenterat ner att man försökt men valt en annan väg.

Lite tankar...

Kommentera funktioner är ju en sak, de borde iofs kort beskrivas i koden och längre i koddokumentationen.

Men att skriva för mycket kommentarer i funktionen vet jag inte om jag tycker är en sådan bra ide.

Frågan är ju precis som Johan skriver, vad kommenterar du för? Är det för att förklara resultatet av en komplex algoritm, fine. Men en sådan här kommentar:

// Execute the command to the database
cmd.ExecuteNonQuery();

// Read result from command exceution
int iVal = Convert.ToInt32(cmd.Parameters["@val"])

Jo, Alltså jag skriver ju alltid en Summery för att tala om vad metoden gör via Intellisense. Det för att underlätta användandet av APIer. Dock kommenterar jag inte private metoder. Och innhållet i koden.
Om det inte är så att jag måste förklara vad jag skall göra, TODO med andra ord.
I övrigt anser jag att koden är rätt logiskt, och som jag skriver i artiklen, koden skall förklara dokumentation. Om du läser den skall den typ aggera som om det vore dokumentation.
public User GetUser(string userName)
{
Validator.CheckUsername(userName);
return ( this._provider.GetUser(username) );
}

Inte måste jag skriva.
//Check if username is valid.
Validator.CheckUsername(userName)

För det säger koden att den redan kollar.
Om jag nu skulle villja få ut data ut en ny property i min User klass är det bara att gå in o kolal vad är .provernn, (ett provider object som ex pekar på SqlMembershipProvider. Den i sig har metoden GetUser... Jag går in där och där ställs ev en fråga mot databasen en reader returneras och User eniteten fylls. Då lägger jag lätt till mitt attribut och Pang, Klart. Utan några större problem. Öven om detta skulle vara ett årsenare. tack vare bra strukruterad kod. Logiska namn. Alltså självförklarad kod.
Om du måste ange kommenterar anser jag att din kod inte förklarar vad du gör. Den kanske är för stor? för komplex? kanske kan brytas ner? (Se artiklen om Extract Method)

Mvh Johan

Jovisst det fungerar ju så länge du inte gör något som inte är uppenbart eller där resultatet antingen blir rätt eller fel. Ponera att du skall göra nån typ av beräkning där t.ex. metoden spelar roll för resultatet. om du då inte beskriver vilken metod du avsåg att implementera så kan du aldrig validera om metoden är korrekt eller inte. Likadant med grafiska grejer, du kanske avser att en grafisk grej skall fungera på ett visst sätt men någon annan kanske anser att det är fel, om du då inte dokumenterar avsikten kan du få problem.

Men jag tror vi är rörande överrens om att kod inte blir bättre för att man skriver kommentarer. Bra kod borde inte behöva kommenteras, och jag menar inte att man behöver kommentera koden utan mer motivera och dokumentera (för validering etc.) på ett annat plan än i metodens summary...

Då har vi unittesting. Eller så har man slarvat :-)
Kommer troligen skriva lite om unittesting i mån om tid.

Mvh Johan

För att kod inte ska behövas kommenteras så är det vikigt att använda namn på en metod som alla förstår, namnet ska i sig tala om vad som händer. Om namnet inte gör det så kan jag rekommendera att ni som utvecklare eller granskar kod använder er av refactory "Rename method"

Tex denna metod säger inte så mkt:

getinvcdtlmt()

Men om ni byter namn på den till:

getInvoiceableCreditLimit()

så säger den så mkt mer.

Jag skulle en gång gå in och ändra i en arbetskamrat kod och fick se metoder som:

run1, run2, run3

Jag fattade inget, jag förstog inte va dom gjorde, koden va gigantisk stor med variablar som a,b,c ohc d etc. Det va inte lätt att förstå denna kod, det värsta var att koden va inte dockumenterad. Här passar "Rename method" verkligen in.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

>37 personer har hitils tittat in här. Men bara en har skrivit? Varför?

En orsak kan vara att detta inte direkt är någon ny eller ovanlig åsikt du framför.
Känns som man redan tänkt och läst om detta flera gånger.
t.e.x stycket "No Comment" i följande artikel tar upp de åsikter som du och andra framför, känns inte som det finns så mycket att tillägga.
http://community.borland.com/article/0,1410,29608,00.html

Sedan är det en annan sak om man lever som man lär. Verkligheten består ju av mycket annat än kod deadlines, krav, människor, lathet m.m.

Absolut, men det är inte många som känner till det, och inte många som bryr sig om det heller.
Agile,(XP, SCRUM) m.m. är inte heller nytt, men man vet inte så mkt om det. Det är skillnad att fatta något än att oxå faktiskt göra det. Nokia vet att de har dålig kvalité, men de gör inte så mkt åt det, även om de lätt kan identifiera vart felen uppstår och varför.

Alla vet att sossarna inte gjort ett skit för att samhället skall bli bättre, andra har idéer sm kanske kan fungera, men de får ingen chans man röstar på det som vart och sedan klagar man på att man vet.

Så det är ingen skada att ta upp saker osm man redna vet. O andra sidan vet vi så mycket idag om olika områden att vi alltid kommer tycka, ja klart det är självklart, men struntar i det självklara.

Jag anser att ett tilläg skulle kunna vara din syn på lathet? varför är det så? är latheten att man hellre skriver mer kommentarer än kod? eller är latheten att man inte gör något alls? vad har deadline med snygg kod att göra? det går oftast to m fortare att skriva och rätta till snygg kod och nå en deadline än skriva kass kod. Krav? som vad?

Mvh Johan

>Så det är ingen skada att ta upp saker osm man redna vet.
nej det är inget fel, jag funderade mest på din fråga "Men bara en har skrivit? Varför?"

>lathet?
Tja ibland orkar man helt enkelt inte fixa dålig kod som fungerar.

>deadline
Man helt enkelt tvungen att släppa kod som varken är snygg eller genomtänkt.

>krav
Om man nu släppt kod som fungerar men är dåligt strukturerad och tänker fixa(t.e.x med Refactoring :-)) detta tills nästa release så kan diverse krav(projektplanering m.m) göra att det inte går.

"Om man nu släppt kod som fungerar men är dåligt strukturerad och tänker fixa(t.e.x med Refactoring :-)) detta tills nästa release så kan diverse krav(projektplanering m.m) göra att det inte går."

Då har man gjort en felbedömnign i projektplaneringen :-) Som inte gett plats för dessa viktiga bitar. För varje efterlämnad kod kan man räkna med dubbelt så mycket arbete om inte mer i efterhand, vilket absolut inte ger lönsamhet, Vad man då bör göra är att ha en god prioritering så man har något att leverera i tid som fungerar och är bra strukturerat. Om vissa "funktioner" utelämnas är det mer kostnads effektivt att lägga till dem i efterhand. Allt måste inte vara på sin plats vid en release.
Sedan beror ju mycket even på vilken metod man använder, XP, SRCUM, Itterativ, Vattenfall o sv.

Sedan är det skillnad att lämna snabbskriven kod utan kommentarer pga tidsbrist, än att istället för refactoring lägga tid på att slänga in en massa dumma kommentarer som skulle ta minst lika lång tid eller kanske to m. längre än att dokumentera. Tänk även på att ju mer kod du lämnar efter dig o refactorerad kommer med säkerhet generera en längre testperiod och buggfixeri innan applikationen kan lanseras. Det kan bli 10 ggr mer buggfix tid än om man gjorde allt rätt från början. Och då lämnar man även kass kod bakom sig för nästa release som säkerligen kommer kräva fler buggar. Alltså är vi tillbaka i spagettihärvan.

Så om man anser att man inte har 1 månad att lägga på refactoring och unittesting, lovar jag att man istället har 2-3 månader med en massa bugfixeri eller missnöjda kunder som klagar på att saker inte går. Och nya funktioner som skulle kunna tatt en vecka kan ta en månad. Men det beror ju på vad man vill offra.

Mvh Johan

Tror de flesta håller med dig, men jag tror ochså att alla har eller kommer uppleva projekt som inte uppfyller dina önskemål. Projektplanering brukar ha en otrevlig tendens att inte överenstämma med verkligheten. Sedan är det alltid lätt att beskriva hur man ska undvika/lösa detta men svårare att förverkliga, att vara efterklok brukar heller inte vara så svårt.

"...men jag tror ochså att alla har eller kommer uppleva projekt som inte uppfyller dina önskemål. Projektplanering brukar ha en otrevlig tendens att inte överenstämma med verkligheten."

Mm, ta och fundera på varför det är så.
Kan det vara att man inte förstår utveckling? Kan det vara så att man är rädd för att man inte har något att ta på hela tiden? Man vågar inte ta chanser för man liter inte på andra?
Projektplanering har en otrevlig tedens att inte överresnstämma med verklighetwn för att de inte förstår verkligheten, så enkelt är det. Amerikanarna kan, Japanarna kan, då kan vi oxå. Om vi bara vill och vågar. Jag anser att man måste ge saker en chans, efter 3 chanser med misslyckande bör man göra en justering för en chans med en ny justering som argumenterar för dessa 3 misslyckanden kan ju inte gå värre än de 3 misslyckanden man redan haft, och skulle det bli värre, vet man i alla fall detta tidigt i ett projekt som baseras efter en itterativ modell. Eller en Agile modell med itterativa modellen som en liten krydda.

Du vet troligen som jag att rush to code pga tidspress ger fler buggar och det går en massa tid åt att fixa dem och i många fall tar de aldrig slut och man måste bygga om allt, eller hur? Om man nu även vet att en god strukturerad kod ger mindre brister, vet man att detta ständiga buggproblem kommer att minimeras och koden kan hålla längre än vanligt. Att blunda för denna verklighet är ju rätt dumt eller hur? Att göra samma misstag om och om igen när man vet att det är fel är ju inte så klokt, då man även vet att andra metoder faktiskt bevisat sig fungera i många projekt. Bara om alla känner till den så klart.

Du får gärna förklara för mig varför Projektplanering brukar ha en otrevlig tendens att inte överenstämma med verkligheten... Vad menar du med att de inte skulle fylla mina önskemål?
Önskemålen att få göra strukturerad kod tidigt för att minimera test och buggfix faserna?

Mvh Johan

En sak som är viktig att tänka på är kundenskrav. Kunderan vill ha sin lösning så billigt som möjligt och så snabbt som möjligt (Ofta de kunder som inte är kvalitets belägna). Detta kan försvårar arbetet med en bra projektplanering. Ett annat strort problem vi har är EKONOMI. Den börjat arta sig lite men är fortfarande dålig i världen, detta leder till att de företag som lever idag och vill få in pengar gär "Nästa" allt för att sälja, så som att dra ner på priset, lovar leverans innan det igentligen är möjligt etc.

Något som leder ofta till dålig kod (enligt min erfarenhet) är att en utvecklare kan bli ryckt från ett projekt till ett annat, utvecklaren tappar fokus på sitt tidigare arbete. Det tar tid för en utvecklare att sedan återkomma till sitt tidigare projekt. Det är lätt i en sådan situation att glömma att färdigställa (eller fortsätta där man var) sin kod som tidigare är påbörjad. Det är inte lätt för en programmerare att ha flera olika projekt i huvudet sammtidigt det resulterar bara till dålig kvalité.

En anna sak som ofta kan inträffa är att företaget har för lite resurser och när en utveklare hoppar från ett projekt till ett annat, så tar en annan utvecklare och förtsätter på en annans projekt. Ibland så måste andra utvecklare fixa andras bugger vilket jag anser är helt FEL. En utvecklare ska aldrig lämna ifrån sig sitt ansvar, hon ansvarar för sitt projekt och ska därför ansvara för kvalitén, det ska inte överämnas till någon annan. Men som sagt, resursbrister leder ofta till att ansvar överlämnas :(

Men jag anser att det finns en lösning på problemet och det är en öppen kommunikation och tydlig där helst olika jargong inte används och färdiga arbetsprocesser och riktlinjer och mål som alla är håller sig till. Mål ska inte vara kortsiktiga, dom ska vara långsiktiga annars blir det brandkårsutryckningar som kostar mycket pengar. Det är också viktigt att förmedla kunden om hur viktigt det är med kvalitet. Levereras en produkt till kund med dålig kvalitet, så kan det leda till en stor kostnad inte bara för leverantören uan även för kunden.

Vad har allt detta med dålig kod att göra? Jag anser att det har mycket med saken att göra, för resursbrist och kvalitetsbrister leder ofta till att utvecklare inte hinner och tappar motiviationen och skapar dålig kod.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

Det är oxå en skillnad att skriva kod där man påstår att man har tid att kommentera än att factorera.

Mvh Johan

Naturligtvis vore det en dröm om alla programmerare i ett företag var helt samspelta och låg på en hög kunskapsnivå. Dock är mina erfarenheter att så ofta inte är fallet, speciellt med ASP.NET där många inte hänger med i steget från ASP 3.0. Vissa har helt enkelt problem att ta till sig objektsorientering (oavsett hur många kurser de går på och hur många böcker de läser), men samtidigt kan man inte sparka varenda kotte som inte förstår det heller. Mindre företag som kanske endast har en "duktig" programmerare kan samtidigt inte hela tiden låta den personen skriva varenda kodrad eftersom den tiden inte skulle finnas. Här är det enkelt att säga att man skall sparka de mindre kunniga och satsa på ny personal men det fungerar inte så.

Att programmera innebär så mycket mer än att tillfredsställa sina egna behov. Det handlar främst om att tillfredsställa kundens behov. Om en kund exempelvis inte vet vad han vill ha utan kommer på sina idéer för sin applikation under arbetets gång är det verkligen svårt för en programmerare/projektledare/databasdesigner/m.m att planera och strukturera. Det man har strukturerat ena veckan kan visa sig helt meningslöst en vecka senare. Eller ännu värre, det man gjorde för 1 år sedan måste byggas om till viss del för att anpassas till det som man bygger just nu. Det blir ett system av ihoplappningar, men kanske ännu värre, det är verkligheten, och kundens val. Det kan vi inte råda över, oavsett hur duktiga programmerare vi blir.

Ett annat perspektiv som kan vara värt att nämna är att om vi har två utvecklare. En som skriver jättebra kod och en som skriver mindre bra kod. Den som skriver bra kod, gör det snabbt och den som skriver mindre bra kod tar lite längre tid på sig. När detta företaget får en förfrågan från ett annat företag om att utveckla det som kunden efterfrågar. Vem skall företagsledningen låta göra jobbet? Om det är betalning per timma får företaget in mer pengar om en mindre duktig programmerare gör jobbet eftersom det tar längre tid, och de flesta företag vill tjäna pengar. Men å andra sidan kanske kunden får en sämre produkt vilket i längden kan ge ett sämre rykte om företaget.

Att dumförklara alla programmerare som kommenterar kod tycker jag är fel. I ett företag finns det personer som behärskar olika kompetensområden. Om vi exempelvis tar kalle som är duktig på c++ och skriver en applikation i det. När sedan olle - som inte är lika duktig på c++ - kommer in och skall göra någon liten enkel ändring (eftersom kalle har slutat) kan det förenkla otroligt mycket om kalle har kommenterat sin kod. Självklart behöver man inte kommentera getUser() osv som tidigare nämnts. Men jag tycker att man få se ett lite bredare perspektiv än bara utifrån sina egna behov.

Absolut.
Grejen är inte att dumförklara utan förklara att det inte behövs. Om man har en metod, låt säga DoSort() och "skriver Sorterar namn efter bokstavsordning" Skulled et gå fortare att välja metodnamnet,
SortNameAfterCharacters() eller liknande, heltplötsligt säger metoden smma som kommentaren.

Jag vet att det varierar mycket i kvalité bland utvecklare, det är just det allt hjandlar om, att få dem att öka i kvalité. Kan man inte få ge kritik kommer de ju aldrig att förstå vad de kan göra bättre, men lika viktigt är det ju att ge god kritik.

Allt det du skriver lever vi i, jag lever i det etc... Det är så verkligheten ser ut, speciellt innom MS utvecklingvärld. Detta vet MS om och försöker göra allt för att öka folkets intresse samt kvalité. EN rad böcker har kommit. De som ex gått kurs kanske förstår OO men inte hur man tänker. Object thinking är en god bok på vägen, för att strukturera sin kod är Refactoring av Martin Fowler trevlig.

Jag vill med mina inlägg ge tips idéer och antydningar på saker och ting som gör att man som utvecklare börjar fundera om, för det är det som behövs. De måste bryta sitt mönster. Jag säger inte att de skall göra det nu på studs.

Jag lever ständigt i det problem du tar upp med kund och projektledare. Det finns en jätte bra metod framtagen för att lösa dessa problem och skapa bättre kvalité, det är Agile. Ta gärna en titt på den.
Det handlar om att skriva strukturerad kod, felminskad kod och ändå dynamisk kod för att utföra de ändringar kunden kräver. En bra strukturerad kod baserad efter objekt tankegång gör att man enklare kan ändra funktioner genom att i princip kasta om metodanrop.

Att sparka någon skall man heller inte göra, men bra utv-samtal kommer ju bevisa varför de har svårt att ta åt sig av informationen, vart problemet ligger. Det är då viktigt att en kompetensansvarig vet hur han skall lägga upp denna personens utbildning.

Nu skall jag fira midsommar. Men syftat var inte att smutskasta andra utvecklare, utan att få dem att tänka djupare... Jag kommer presentera flera krönikor ang strukturerad kod, då kommer troligen flera bita falla på plats. Har redan fått en hel del possetiva kommentarer och frågor kring det jag sagt och skrivit, de är väldigt possetiva till det hela, även om det kan verka lite hårt...

Kul att du skrev. Vi hörs...

Mvh Johan

Ett problem som jag ser är som det tidigare nämnts att alla kanske inte KAN ta till sig ny metodik eller objekttänkande. Det finns flera sorters anställda på ett företag. Det finns dem som brinner för sitt jobb, läser forum, msdn, läser böcker och funderar över problemlösning och metodik dag som natt.
Sen finns det dem som helt enkelt vill ha ett jobb att gå till mellan 8 och 5. När dagen är slut är arbetet slut. Kanske har personen läst en KY-utbildning eller läst systemvetenskap på 90-talet och känner att "Ok, jag har studerat mitt, nu arbetar jag". Det finns för denna personen alltså inget intresse att varesig lära sig mer om objektstänkande eller nya metoder, särskilt inte i jämförelse med intresset för att läsa nyheter, romaner eller syssla med annat.

Personen har säkert inget emot att utvecklas, men något eget initativ och intresse finns inte. Företaget diskuterar då en lösning och kommer fram till att en mer drivande och kompetens utvecklare ska lära upp och utbilda några mindre framgångsrika utvecklare under ett par månader framåt (ett par timmar/vecka). Personen får även gå på kurs. Utbildningen går bra, men så kommer problemet, personen har nu lärt sig att skriva AV exempel på ny metodik och objekttänkande, men egna idéer eller EGEN nyutveckling är i princip uteslutet då personen endast tagit till sig exakt de exempel som den fått serverade. För den här personen handlar det alltså inte om att bitarna ska falla på plats, utan snarare om att personen inte har fallenhet för att ta till sig objektstänket. Att ta till sig av färdiga exempel kan alltså gå jättebra, men att sedan göra nyutveckling utan att bara kopiera gamla exempel går inte alls.

På detta kommer det rent ekonomiska. En kurs kostar ett företag ca 50.000kr/vecka (inkl. förlorad arbetstid), dessutom behövs mer inlärningstid och övning. Så då lägger vi på ca 10.000kr på det (ca 15 timmars "övning"). För att det ska var lönsamt att skicka personen på kurs KRÄVS det att personen kan prestera MYCKET bättre efter avslutade kurser, och det finns det ju absolut ingen garanti för. Kanske faller personen bara tillbaka till sitt "gamla vanlig" sätt, och då är pengarna kastade i sjön. För ett mindre företag är det helt ohållbart.

Vad är då nästa steg?
Som du skrev i din blog angående XP: "If you think Object thinking is hard, maybe see if other areas can make you success instead. Like be an expert in code testing, performance or security?". Ja, det funkar
säkert på ett stort företag, men hur går det då på ett mindre?

Kanske är ditt svar att personen ska leta efter ett nytt jobb. Ja, kanske, men personen har nu ett jobb som den trivs på och som tillägg kan man även lägga till att personen i övrigt gör ett mycket bra jobb, särskilt med lite äldre tekniker som denne behärska bra.

Jag vill härmed poängtera att det inte går att hitta en generell lösning. I teorin fungerar det bra att skicka alla på kurs, men rent praktiskt så går det inte av dels personlig fallenhet och ekonomiska skäl.

När det gäller just att skriva förståelig kod så tycker jag inte att det spelar någon roll vad man kan, om man kan ta till sig nytt eller annat. Det handlar inte om någon NY metodik utan bara att man ska skriva förklarande funktions- och variabelnamn, indentera samt lämna blankrader mellan kodblock. I alla fall till att börja med.
Istället för att skriva Run1(), Run2(), Run3() så döper man funktionerna till SortOrderByChar(), GetFileSettings(), InstantiateAddressList() eller vad man nu ska ha funktionerna till.

Det är en rätt liten sak för att få kod läsbar och det handlar varken om metodik eller komplicerad teknik.

Sen om man ska gå in på objekt-orientering, refactoring och dylikt då är det en helt annan sak. Men man kan varken skylla på tidsbrist eller bristande kunskap när det gäller att döpa en variabel till RowCounter istället för i.

Om man bör se på verklugheten, skulle du villja att en snubbe byggde det flygplan du flög i om han int eorkade öka sin kvalitéts känsla för sitt arbete? skulle du verkligen villja at en snubbe som inte vill lära sig att bli bättre skulle bygga ditt flygplan? Svar NEJ eller hur?
Det är trist att folk väljer yrken som kräver kvalité personal men int eorkar med kavlité. Tycker det är rätt skrämmande det du säger. Men visst är det så. Om jag var chef och mina utvecklare inte ville ta in mer information för att effektivisera arbetet så måste jag ju som chef göra något åt detta eller hur? Även om det handlar om människor så handlar det ju oxå om överlevnad. Om 5 utveckare och 10 sliter som djur med att lära sig nytt för att effektivisera ett arbete och 10 andra skiter fullständigt i det för de arbetar bara för en lön. Då brinner de ju inte för sitt intresse och sabbar för de andra 10 som vill utvecklas. Då de ger mig mer lönsamhet medans de andra inte effektiviseras ger de mig och de andra 10 sämre förutsättningar, är det lojalt? Det är bara en fråga, jag vet inte just nu hur jag skulle reagerat men jag vet att jag blev sur på dem som sa till mig, jag skiter i hur jag bygger om du inte förstår vad jag byggt jag gär detta endast för pengar. Det är jäkligt ego. Här fick man sitta med as sunkig kod för att personen inte ville lära sig bli bättre. Jag som vill utvecklas och som utvecklas fick sitta och pilla med saker jag är emot. Spagetti kod. Buggar i massor för att de inte orkat bry sig om kvalitén.
Jag vet hur det ser ut där ute. Men jag försvarar det inte, för jag vill och önskar att andra oxå orkar öka sin kreativitet och bli bättre än vad de redan är. Men jag vet inte hur det skall gå till, det är allt från bra personalpolitik, ekonomi, effektivisering bland andra roller m.m. som spelar roll.
Jag vill främst säga vad jag tycker och vad jag anser rimmligt för mig, baserat på mina erfarenheter. Jag vill att folk tar mer ansvar och ökar sin kvalité, o inte yttrar ord som. "Men jag kan inte poåverka för jag bestämmer inte! Då gör jag som alla andra gör.!"

Om jag fick önska, hade jag velat ha bättre metodik på företagets organisationer, bättre effektivitet, framförhållning, och det viktigaste bra personalvård som ökar moralen bland de anställda som oxå ökar motivationen...

Detta är min syn just nu, den kommer att ändras, den är inte fast. Men jag anser fortfarande att man skriver kommentarer (för mycket) för att förklara vad ens kod gör. När man istället hade kunnat göra koden mer självbeskrivande och lagt tiden på refactorering. I Vs .Net 2005 kommer det finnas stöd för att öka refactoring samt unittesting m.m. Det växer, även MS har nu insett fördelarna. Jag anser att det är dags att bryta gamla vanor och införa de nya... De nya kommer innom en snar framtid att bli gamla. Allt försändras så länge världen inte slutar att förändras.

Så om du vill effektivisera dig, lära mera, känna att du gör ett bra jobb, kräva högre lön eller personalvård så gör det.

På dig låter det mer som, "Loppet är kört! Du är dum som inte inser det Johan!" så har jag oxå känt, känner så varje dag. Men jag har ett start hopp som för mig framått. Jag har ett mål och vill även att mina kollegor i branchen oxå vill ha det och inte ger upp för att ALLA andra gör eller någon hindrar en från att göra. Jag presenterar min utv-politik. Och säger inte så måste man göra. Det är min åskit. Som jag även vet att jag delar med andra. Jag vill skapa nyfikenhet hos dem som vill.

Nej, jag hade absolut inte velat ha det så (angående flygplansjämförelsen), lika lite vill jag ha det så att jag själv som utvecklare ofta ser min kod "gå i spillror" för att den tas över och modifieras av andra personer. Problemet som jag ser det är som sagt att det är svårt att hitta en lösning. Jag har drivit denna fråga i över 3 år, pratat med chefer, kollegor osv. och jag driver den än idag, just för att jag inte gett upp hoppet. Har provat olika metoder för lösningar, men även om man skulle få upp motiviationen hos medarbetare så krävs så otroligt mycket tid! Många personer har barn och familjer att ta hand om och har helt enkelt ingen tid över till egen läsning. Och hur ska ett företag ställa sig till det? (Alternativ att all utbildning ska läggas på arbetstid är ohållbar rent ekonomiskt).

Och nej, jag fördummar inte dina inlägg eller svar, jag bara reflekterar ett problem som jag tror är ganska vanligt. Och just vid diskussionen om "Bra Vs Dålig" programmerare passar den ganska bra in.

Inte min mening att sprida någon negativ ton eller klanka ner på dig eller nån annan här. Känner bara frustration över problemet och vill höra andras erfaranheter av problemet och dess lösningar / icke lösningar.

/Fredrik

Ang utbildning på arbewtstid. Där ser man oxå ett tecken på kortsiktlighet hos företag.
De tänker inte på att de i längden kommer vinna in dessa pengar de lägger på en bra utbildning
Tänk om den kostar 30 000 kr, men under 3-6 månader gav den så bra kunskaper att man tjänat in pengarna pga att projekten vart klara långt innan dess deadline. Effektiv kod ger minde utv tid, mindre fel och snabbare justering av fel. Men jag känner igen ditt problem, lever exakt i samma.
Önskade bara att människan kan tänka längre än näsan ibland.

Mvh Johan

Fredrik:

Tänkte bara tips om tre böcker som jag tycker är otroligt bra som handlar just om hur man ökar motiviationen, effektiviteten etc hos människor:

"Gung Ho!"

Jag har skrivit en jätte kort översikt om den bok som klart är en av dom bättre "ledarskap" böckerna jag har läst. Du kan lästa lite kort om den på ming blog:

http://normen.mine.nu/MyBlog/viewpost.aspx?PostID=95


Bringing Out the Best in People: How to Enjoy Helping Others Excel

http://www.amazon.com/exec/obidos/tg/detail/-/0806621516/qid=1088268396/sr=8-5/ref=sr_8_xs_ap_i5_xgl14/103-2431345-0756626?v=glance&s=books&n=507846


Till sists har vi en bok som ALLA borde läsa. Det är från samma författare som har skrivit "Bringing Out the Best...".

The Balanced Life: Achieving Success in Work & Love

http://www.amazon.com/exec/obidos/tg/detail/-/0806635703/ref=pd_sim_books_4/103-2431345-0756626?v=glance&s=books

/Fredrik Normén NSQAURED2
http://normen.mine.nu/myblog

Med risk för att låta kritisk i överkant. Grad av struktur är givetvis en måttstock när det gäller att bedöma en utvecklares kvalitet. En annan faktor är analytisk förmåga. Att komma fram till att en mer eller mindre binär inställning till om man skriver kommentarer eller ej när man kodar kan ligga till grund för om man är en bra programmerare eller inte är rent absurt och tyder på stora brister gällande förmåga att analysera problem. Kort sagt, en bra programmerare kan gott skriva kommentarer. Eller så kan han utelämna dessa och förlita sig till läsbarheten på koden. Detsamma gäller en dålig programmerare och det påverkar inte kvalitén på vare sig koden eller utvecklaren åt endera håll. I vilken utsträckning man använder sig av kommenterad kod är alltså rent personligt och påverkar inte kvalitén på utvecklaren och oftast inte på det som utvecklats heller.

Problemet är att om man läser kod som en undermålig programmerare skrivit - eller för den delen dålig kod som en bra programmerare skrivit, för det händer givetvis det med – som är okommenterad så ligger man troligtvis mycket sämre till än om man har tillhörande kommentarer till denna kod. Skall man då bara kommentera om man är en dålig programmerare eller om man för tillfället skriver dålig kod? Vem bedömer då detta?

Som jag ser det finns det ett antal olika anledningar till att kommentera. Ni har i andra meddelanden i denna tråd redan tagit upp kommentarer för att beskriva publika metoder för externa användare. Men det finns som jag ser det helt klart andra anledningar till att kommentera.

Hur bra och lättläst kod en utvecklare än skriver så är det i praktiken alltid så att denne utvecklare sitter på verksamhetskunskap som inte syns i koden. Nästa utvecklare som skall justera eller bara granska koden sitter förhoppningsvis, men långt ifrån säkert, på likvärdig verksamhetskunskap inom området. Kunskap som kanske rent utav skiljer sig från den ursprunglige utvecklarens kunskaper i något avseende. Kommenterad kod kan mycket väl fylla i informationsluckor så att koden blir lättläst utan att den senare utvecklaren behöver konsultera annan dokumentation eller rådfråga en verksamhetskunnig person. Det vill säga kommentarerna gör koden mer lättläst.

Som jag ser det är skrivande av lättläst kod med god struktur och tydligt beskrivande metod-, attribut- och variabelnamn ingen ursäkt för att inte kommentera väl. Lika lite som välkommenterad kod är en ursäkt för usel struktur eller illa valda namn. För ett enmansprojekt kan det ofta kvitta – även om det efter ett par års frånvaro från koden kan vara avgörande för förståelsen -, men så snart man riskerar att någon annan skall granska eller justera koden så finns det ett mervärde. Naturligtvis bör man inte kommentera in absurdum med kommentarer som beskriver vad varenda rad kod gör och som dessutom på ett meningslöst sätt beskriver precis vad raden nedanför redan beskriver.

Bortsett från kommentarer gällande specifik verksamhetslogik eller beskrivning av omständliga algoritmer som man inte kan förenkla och därmed göra mer lättlästa, så ser jag personligen gärna att man använder sig av kommentarer ungefär som man använder rubriker när man skriver vilket dokument som helst. Alltså för att lättare få en överblick över koden. Tänk er att läsa facklitteratur utan rubriker och underrubriker. Hur drygt skulle inte det vara? Att kommentera koden på detta sätt i efterhand medför dessutom att man i samband med detta per automatik bygger in en form av kodgranskning. Inte för att ersätta riktigt kodgranskning av annan part, utan för att hitta uppenbara felaktigheter som kan åtgärdas före den slutliga kodgranskningen.

Jag säger inte att man är usel om man kommenterar, utan syftar på att man inte behöver kommentera koden och många som gör det gör det oftast för att de skriver kass kod.

Men svara för mig varför i hela världen jag skall speca kunskaper i kod och inte i specifikatoioner elle rusa case? Om jag kan mycket innom ett område, har jag väl fått en spec eller? Det är ju inte så att jag bara skriver kod ur tomma intet. Så om Nisse som inte kan FTP program skall ändra i min kod så har han ju en specifikation över funktionalitet som skall fungera. Är det en bugg så är det kvalitén inte kunskap innom ett just område som räknas. Analytisk förmåga = kunskap. Kan man inte läsa kod som utvecklare vad det än gäller så är något på tok fel. Antingen är koden kass skriven så denna inte kan orientera sig. Eller så är utvecklaren kass som inte kan läsa koden.

Man skall inte utebliva information som måste ges till en oinsatt. Men jag anser att den informationen ligger inte i koden utan i specar. Det är lätt att skriva kod som en datro förståre men kräver mycket mer att skriva kod som en männsika förstår. Det är vad refactoring handlar om, och refacotring är just att slippa skriva kommentarer m.m. de skall inte behvävas. Strukturen skall vara uppbyggt så självkörklarande som möjligt. Förstår man inte detta anser jag att man troligen inte förstår hur en välstrukturerad kod kan se ut. Då är Refactorign ett bra ämne att skola sig vidare på.
Objekt thinking är oxå en väldigt viktig bit i det hela. Kan en användare läsa ett språk syntax anser jag att denna kan läsa allt och hitta fel om den är analytisk nog utan kommenterar som informationsspridare i kod, med god struktur.

Ge mig gäran ett case där du anser att man måste ha kommentarer i koden. Det är lättare att se då, för jag ser inte vitsen. Eller kanske inte förstår vitsen, särkilt inte argumentet om man inte har kunskaper innom området... Har du kod exempel så går det oxå bra...

Mvh Johan

Detta är inte ett svar till vad Robert skrev, inte iheller till något annat svar i tråden utan bara en observation i sammanhanget.

Man skriver inte dokumentation för idag, imorgon eller för om 1 månad. Man skriver dokumentation så när man kommer tillbaka 2år ner i produktens livslängd och behöver uppdatera / buggfixa eller liknande så finns det kommentarer för vad som sker.

Oftast har företaget haft lite förändringar i personalstyrkan och ny personal (och givetvis gamal också) skall kunna sätta sig in i koden som skrevs för länge sen. Oavsett om man har en kodstandard mm på företaget så beskriver denna bara hur man bör namnge, struktuera saker etc. och inte hur de olika programmerarna analyserar och skriver lösningar till problem. Samma problem kan kodas på otaligt anal sätt även om alla följer en angiven kodstandard.

Det är sånna här skillnader som kommentarerna används till .. två duktiga programmerare kan ha "svårt" att följa varandras tankegång men med en välskriven kommentar kan allt trilla på plats direkt.

Andreas.

Du kommenterar för att förklara något eller hur? Kör du refactorign rename method så ersätter du kommentarer med ett beskrivande namn utifrån kommentaren.

//Sorterar efter namn, äter glass och går på toa...
Sort()

Här gör du flera saker, troligen kan du köra en extract method på äter glass och går på toa.
Byta namn på Sort till. SortByName() i StortByName har du två nya metoder,
EatGlas(), och GoToTheToilet()

public void SortByName()
{
EatGlas();
GoToTheToilet();
}

behöver du verkligen för programmeraren skriva samma kommentar som ovan? Att du sorterar efter namn äter glass och går på toa? JAg tycker koden lätt förklarar detta. Rätt onödigt att upprepa sig då.
När du kommer hit efter 2 år säger koden fortfarande. Sortera efter namn, Soreta efternamn äter glass och går på toaletten... Behöver du speca mera så har man specar till detta. Ex vad man förväntar sig att få ut. Om man inte har det i specar har man det det u test casen. Ex Unittesting. Där framgår det oxå tydligt hur saker skall fungera. Och utmärkt att nyttja för framtida testning även efter 2 år.

Mvh Johan

Robert:

Som du säger algortimer mm kan behövas dokumenteras för att göra det lättare för en annan utvecklare att sätta sig in vad algoritmen gör (Om det är omöjligt att köra refactoring).
Men praktiskt så skulle du kunna göra varje rad till en metod och på så sätt sätta ett namn som beskriver vad metoden gör, då skulle du inte behöva dokumentera, men jag skulle inte själv underhålla ett sådant system, men tänk på saken ;)

Johan:

Som du säger, en metod beroende på namn kan mycket väl beskriva metoden och dess syfte, vilket leder till att dokumentering inte skulle behövas. Dokumentering tar tid, men kan under olika situationer hjälpa till att förstå koden lättare.

Till alla:

En kommentar är bra om du ska säga "varför" du gjorde något. Denna typ av information kan hjälpa andra personer som ska modifiera koden, spelciellt för personer som lätt glömmer av saker.

Om du känner behov av att skriva en kommentar, försök först med refactoring av koden så inte kommentaren blir överflödig.

Om ni behöver beskriva vad ett "kod-block" av koden gör, använd Extract method. Om metoden redan är utdragen men du behöver fortfarande en kommentar för att förklara vad den gör, använd Rename Method.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

"Jag säger inte att man är usel om man kommenterar, utan syftar på att man inte behöver kommentera koden och många som gör det gör det oftast för att de skriver kass kod."

Jag kanske har en skev bild av programmeringsvärlden. Jag har sett mycket usel skriven kod under mina år som utvecklare, men aldrig kommentarer som är skrivna för att koden är usel. Som jag ser det är du helt enkelt på tok för kategorisk i dina påståenden.


"Men svara för mig varför i hela världen jag skall speca kunskaper i kod och inte i specifikatoioner elle rusa case? Om jag kan mycket innom ett område, har jag väl fått en spec eller?"

Tänk om världen vore så härlig att det alltid fanns ordentliga Use Cases eller ens nedskrivna specifikationer till alla projekt. Om inte information spreds informellt, kanske rent utav från mun till mun i flera steg före den når utecklaren som skall implementera idén. Om det vore så att källkoden till ett projekt skrivet i någon 16-bitars VC++ någon gång i början av 90-talet verkligen fanns tillgänglig på en VSS-databas på en aktiv server tillsammans med beskrivande dokumentation. Mer generellt kan man väl säga att projekt där dokumentationen finns tillgänglig och består av formella specifikationer skulle med all sannolikhet aldrig behöva kommenterad kod. Men så härlig är ju inte världen.


"Analytisk förmåga = kunskap"

Antar att du inte menar det riktigt. Visst är kunskap en förutsättning för analytisk förmåga, men att analytisk förmåga skulle vara samma sak som kunskap är givetvis helt galet.


"Det är lätt att skriva kod som en datro förståre men kräver mycket mer att skriva kod som en männsika förstår. Det är vad refactoring handlar om, och refacotring är just att slippa skriva kommentarer m.m. de skall inte behvävas."

I min värld handlar refactoring om att skriva om kod av en eller annan anledning. Må det vara av prestandaskäl, för att underhåll skall underlättas eller något helt annat. Att det skulle finnas någon koppling till att slippa kommentarer är i mitt tycke helt uppåt väggarna.


"Ge mig gäran ett case där du anser att man måste ha kommentarer i koden."

Jag anser inte att man måste ha kommentarer i koden. Jag anser att de kan underlätta läsförståelsen av kod. Överblicken när man ser en sida med kod. Precis som man lättare hittar information i ett dokument skrivet i Word om man har rubriker i detta. Jag är fullt medveten om att det är en smaksak.

Johan,

Är lite rädd för att du är fast i din refactoring snurra. Det finns så mycket mer som man måste kommentera upp än variablenamn och metoder. Vi snackar om algoritmer, kommunikationsprotokoll och liknande, dvs det finns så mycket mer som man inte kan refactora för att göra mer beskrivande.

När vi ändå är inne på kommentering av metoder och variabelnamn så finns det faktiskt ingen ursäkt (mer än lathet) att skriva XML kommentarer (VB.NET folket får juh tillgång till det iom VB.NET 2005). Det, tillsammans med vettiga variabelnamn och metodnamn mm (som regleras av en kodstandard på företaget) ger bra dokumentation av hela projektet (och gå givetvis kommentation av algoritmer och dylikt)

Robert:

Refactoring handlar om att göra om existerande kod till en bättre kod genom att ge den en bättre disign och struktur. Refactoring har inget med att optimera prestandan att göra. Refactoring handler även om att skapa kod som är lättare att förstå, dessa förändringar leder ofta (behöver inte) till lite sämre prestanda.

Du kan läsa om "Refactoring" på denna site:

http://www.refactoring.com

Mvh Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

Jepp menade fel med "Analytisk förmåga = kunskap" vad jag mena rär att det oftast skapar kunskap. Då du lätt kan förstå saker och få ett grepp om dem som du sedan nyttjar till nästa likartat problem.

Oftast kan kommentarer i kod snurra till det än ge dig fördelar. Ibland kan det to m. vara så att man ändrat en hel del i koden och inte skrivit om dokumentationen pga tidsbrist. Ett sådant senarie är oftast mycket mycket värre än om man direkt skrev kod som förklarar sig självt.

Sedan är inte förr nu. Alla utvecklas och saker och ting effektiviseras. Rafactoring är så mkt mer än effektiv kod. Det är oftast mer prestanda krävande då det orsakar mer anrop så det argumentet håller jag inte alls med om. Dock kan refactorign underlätta ökandet av prestandan av den refactoriserade koden. Men bäst prestanda får du genom att minska antal metodanrop.
Refacotring går ut på att strukturera om koden för att effektivisera den, där ingår det förståelse, mindre kodstycken för att lättare ha översikt av vad som sker, att minimera buggar genom mer återanvändbarhet mellan metoder etc... Ja en hel del fördelar för det med sig.

Men visst allt är politik. För är god refactoring mycket mycket bättre att ta än att strunta i det och slösa tid på kommentarer i koden. Att både refactorsiera och skriva kommentarer är oxå rätt mycket slöseri då du faktiskt kan förklara koden med goda namn. Jag kan fortfarande inte se vaför jag måste görklara en sak när metoden tydligt gör detta åt mig. Om en bugg hittas och man skall rätta detta är det ännu enklare att debugga eller följa anropskedjan än om man inte körde refactoring. Kommentarer får en mindre roll i ett väl beskrivande system. Att man skriver kommentarer beror på att man inte litar på den som tar över koden, eller att man har svårt att beskriva i kod vad sakerna gör. Om man ändå måste beskriva en självbeskrivande kod för andra beror inte på att du som skriver dem kanske inte förstår utan att de andra inte besitter det tankesätt OO egantligen kräver.
Jag kommenterar kod, men bara på API nivå. Skriver aldrig (eller oftast inte) vad jag gör på vissa ställen. Om jag har en ifsats som man inte förstår så lägger jag denna i en metod istället och beskriver i metodensnamn vad jag kontrollerar. IsTaxesLowerThanPrice eller nått. Istället för att göra en if sats och skriva samma kommentar ovan...

Bra programmerare kan kommentera koden ingen tvekan. Men det är för många som kommenterar för att de inte kan skriva självförklarande kod. Det är det jag syftar på. Jag tror inte ens Martin Fowler som yttrar samma mening syftar på de duktiga som skriver kommentarer för att andra med kanske mindre kunskap skall förstå. Utan han syfter på dem som skriver kommentarer för att de själva inte förstår eller inte behärskar strukturerat kodande.

Mvh Johan

Andreas.

Jo visst. Men oftast använde rdu ju färdiga APIer för detta som redan är dokumenterade via specar.
Annars kan du mycket väl lägga en algoritm i en flrklarande metod som säger vad algoritmen gör.
Det är ju det du ändå kommer förklara med kommentar. Sedan kan man förtydliga i själva algoritmen vad man gör om det inte går att få fram det tydligt eller om man inte har en skriven spec på algoritmens krav... Jag syftar mest på den övergripliga onödiga kommenterandet, av variabler, av metoder, av if staser, av loopar m.m. Men oftast, jag säger oftast så har man faktiskt specar som man bygger utifrån, Har man inte det saknas en arbetsmetod, och då är man ju redan fel ute och behöver
slösa tid på att skriva specen i koden istället för på ett papper bredvid... Men det är ju andra faktorer, nu utgår jag från att man har en fungerande process i bakgrunden... Finns alltif undantag till varför man gör saker eller inte gör dem....

Mvh Johan

Orkar inte läsa igenom alla inlägg i den här tråden men det känns som om någon/några precis upptäckt refaktorering och andra delar av XP som har funnits i ganska många år...den här diskussionen tillför inte mycket nytt tyvärr.

Bra för dig... Är det nått i denna världen som tillför något nytt? Tror bekant det mesta redan är upptäckt. Vad du måste missaär att ALLA faktiskt inte har upptäckt dessa bitar, eller skall vi kalla det, har inte studerat dessa bitar hur gamla de än är? Och vad detta handlar om är att väcka intresse hos dem som inte har snuddat områderna hur gammal infon än är och hur lite den än ger dig. Tycket bekant du kan dela med dig av dina erfarenheter istället, det är vad syftat med detta var. Det handlar inte om att lära ut XP, AGILE; SCRUM, Itterations modelle, Refacotring, Objekt tänkande etc...

Mvh Johan

Nils:

Bra då vet vi ALLA nu att du redan kan det.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

Nils,

När majoriteten av pellesofts besökare kan anses som nybörjare och när syftet med communityt är att föra ut kunskap till andra så är väl inte diskussionerna så värst fel? Jag är helt övertygad om att av de 375 personerna som läst tråden i skrivandets stund så har en stor del inte någon tidigare erfarenhet inom detta. Är det då inte bra att det finns ett forum där denna information kan föras ut på svenska med möjlighet för en diskussion kring ämnet ?

Som dagsfärsk medlem på pellesoft är dina möjligheter oändliga. Om du känner dig ha bra kompetens inom ett/flera områden så uppmanar jag dig att bistå med lite av din kunskap till alla andra, i form av artiklar och diskussioner kring intresanta ämne. Och du Nils.. välkommen till Pellesoft :P

Vill inte göra detta till någon följetong. Det är inte så att jag bestrider dina åsikter om nyttan med vare sig Refactoring eller att i största allmänhet skriva tydlig och läsbar kod. Det är rena självklarheter som jag ser det. Tråden började trots allt med att du kategoriskt klankade ned på kommentering av kod, eller snarare på de som gör detta.

Jag ville bara kommentera det lustiga med ditt exempel om att sortera och käka glass, eftersom det är ett ypperligt bevis på att kommentarerna tydligen behövdes i just det fallet. Om en utvecklare kommer tillbaks till den koden efter säg två år, så är han tvungen att veta saker som inte finns att utläsa ut kommentarerna, och heller knappast lär finnas dokumenterade på annat håll. Denne nye utveckalre måste veta att du är svensk och kanske just därför inte kan göra skillnad på glas och glass, eller snarare glas och icecream. Hade kommentaren funnits där, om den så hade varit på svenska, så hade denne utvecklare möjligen haft en bättre chans att förstå koden.

Hehe. Kom på att jag skrev Glas o inte IceCream när jag lagt in inläggget, men hade brådis till bussen.
Skall ändra detta nu. Glömde av det. tack för att du tog upp det.

Eftersom utvecklaren som läser koden skulle se de tre rader kod samt SortByName metoden så ser denna direkt att jag äter glass :-) Så varför säga det i en kommentar?

Du måste oxå se skillnaden från dålig programmerare vs bra gällande mitt inlägg. Eftersom Refatoring är en del av XP och Agile (vanligvis) så anser jag att man jobbar efter denna metoden. Då skall man inte behöva kommentera en massa, de som gör det Brukar i allmänhet vara av sämmre virke. Jag tycker även att jag är rätt tydlig på att säga De Som kommenterar för att de inte förstår vad de gjort är sämre än dem som inte kommenterar och skriver självförklarande kod. Det är en viss skillnad mellan de som skriver kommentarer trotts självförklarande kod för att andra skall förstå (om man vet med sig att viss aär lite sämre) än att skriva kommentarer för att man inte kan förklara sin kod genom självbeskrivning.

Så Nej jag klandrar inte dem som kommenterar sin kod. Utan på dem som skriver kod som en datro förstår men som inte männsikan förstår och måste då skriva en massa kommentarer.

Men jag anser att du som programmerare inte skall behöva kommentera i koden, utanden skall vara så självbeskrivandeatt du efter 2 år kan läsa vad du gjort. Om du inte kan det, har du troligen utvecklats och blivit ännu bättre. Är du säker åa tt du inte kommer kunna läsa din kod efter två år får du väl kommentera i den (om det finns tid).

Jag föredrar Refactoring före kommentering. Har man tid med båda så fine för den som vill eller den organisation som kräver det av olika skäl.

Hoppas jag vet mer tydlig nu?

Tidsfaktorn är väldigt intressant som jag ser det. Det är ju väldigt få projekt som har obegränsade resurser, och tid till leverans likväl som tid i pengar är oerhört viktigt.

Vad har det med kommentering att göra?

Jo, att kommentera kod i efterhand kostar ofta bara en bråkdel av vad omskrivning av kod kostar. Jag har hört någonstans att för varje utvecklare på MS så har de en ratio på ungefär tio testare. För varje timme utveckling så går det alltså tio timmar testning. Vet inte hur sant det är, men det är vad jag har hört som sagt. Skriv till lite kommentarer efter att man checkat in koden för leverans medför en kostnad på precis den tid det tar att kommentera. Ändrar du en enda rad kod så måste all test som påverkas av modulen göras om. Inte helt gratis även om mycket automatiseras idag.

Hur ställer man sig till sådant inom XP och Agile? Jag frågar därför att jag har väldigt begränsade erfarenheter av dessa metoder. Har man samma testapparat som i "vanliga" utvecklingsprojekt?

Ang kommentering sker ju det oftast under utvecklandet. Ibland ändrar man ju i koden och måste skriva om kommentarerna, det är du med på?

För varje rad text du skriver kod som kommentarer så tar det tid. Ju mer kommentarer du har ju större risk är det att du måste ändra dem efterhand, då buggar hittats eller man velat ha annan funktionalitet.
Ibland kan koden vara så stror och klumpig att man har flera rader med kommentarer. Tänk vid lilla minsta ändring så måste även denna text läsas genom och uppdateras. Inte nog med det har man en policy att uppdaera specar så tar det ytterligare tid. Det spelar alltså ingen roll vilken metod du använder så blir det ett problem. Oftast skriver man många kommentarer för att förklara en metod som man lätt skulle kunna förklarat via ett bättre namn och bättre struktur (refactorering ger bla. denna fördel.) På så vis minimeras antal rader kommentarer. Som jag ser det behövs de inte där koden är väl självbeskrivande. Refatorering tar inte så lång tid, särkilt inte med något verktyg. I Vs .Net 2005 kommer detta verktyg att ingå. Att makera en if statement och skapa en metod av denna som förklarar vad man gör går ottroligt fort om man är rutinerad. Oftast snabbare än att behöva slänga in kommentarer. Då kommenteraerna oftast säger vad en metod gör behövs de inte om metoden har ett bra namn. Ex:
<code>
//Check if value is 250 for OK or 450 för Success then change password.
public void CheckData(Object object)
{
if(......)
do stuff
dp stuff...
do stuff...

next next next...
....
}
</code>

Låt säga att du inte skrev kommentaren. och snabbt gör detta:

<code>
public bool CheckForOkValues(int value)
{
resturn (value == 250 || value == 450);
}

public void ChangePassword(string newPassword)
{
...
}

public void UpdatePassword(int value,string newPassword)
{
if(CheckForOkValues(value))
ChangePassword(newPassword);
}
</code>

Koden blir mycket tydligare, blir enklare att ändra och är rrätt självbeskrivande.
Det tog mig kanske 5 sekunder extra att skirva detta än att skriva kommentaren. Vill jag göra koden smidigare kan jag ändra så 250 samt 450 ligger i två globala variabler för att i framtiden kunna justera dessa ok värden. Ex.
<code>
private int OK_VALUE1 = 250;
private int OK_VALUE2 = 450;
</code>
<code>
resturn (value == OK_VALUE1|| value == OK_VALU2);
</code>

I min Guideline säger jag att versalaer är globala variabler så jag kan lätt hitta dem i toppen av min klass om jag vill ändra värdet. I gamla koden hade jag behövt gå genom en del rader kod, ändra i koden, uppdatera kommentaren. Nu behöver jag bara ändra OK_Value* till nått annat. Koden är fortfarande väldigt självbeskrivande och lättförståelig.

Om man inte kan få den självbeskrivande så finns ju ingen annan utväg än att kommentera. Men det är något man bör göra efter refatoring om inget av de olika metoderna hjälpe till.

Mvh Johan

Johan,

Använd < code > taggarna annars får du smiskt :P

Så :-)

Vänder stjärten till.. Slå inte för hårt ;-)

Hej!
Jag har inte läst exakt vad alla har svarat, men här är mina synpunkter...

Jag anser inte att rikligt kommenterad kod NÖDVÄNDIGTVIS måste vara sämre än okommenterad - det är bara en fråga om att hitta en balans mellan kod och kommentarer.

Personligen så brukar jag faktiskt kommentera en hel del, men inte exakt vad kodraderna gör, utan mer hur dataflödet är tänkt att fungera och samarbeta med andra avsnitt. Jag brukar dessutom börja med att BARA skriva kommentarer om hur jag skall utforma mitt program så att jag snabbare kan återta mitt arbete efter en paus eller ett avbrott.
Ofta låter jag kommentarerna vara kvar efter att projektet är avslutat - mest för att jag är för lat att plocka bort dem, men ibland kan det vara bra att ha de ursprungliga tankarna kvar för att kunna fixa buggar, vidareutveckla programmen, överlämna till andra programmerare mm.

Naturligtvis kommenterar man inte en funktion som t.ex. "Sort" vad den gör, utan snarare vilka argument som den förväntas ta emot och vad den är tänkt att returnera:

Function Sort(ByVal StringToSort As String, ByVal SortType As Integer) As String

Här kan det vara på sin plats att kommentera vad det andra argumentet förväntas innehålla och vilka värden som är giltiga. Bara som exempel alltså... Ofta kan funktioner vara mycket mer komplexa och det är oftast lätt att se vad funktionen är tänkt att göra, men det kan vara mer obskyrt att utläsa vilka giltiga argument som funktionen accepterar och förävntas ta emot.... och för att inte nämna vad den returnerar.

Dessutom är det svårare sagt än gjort att koda med självförklarande kod: Om du får skriva ett helt nytt program från scratch så är det inga problem, men i dagens verklighet så får du oftast ärva dåligt skriven kod som du måste bibehålla en massa junk, och då är kommentarer verkligen på sin plats. Kom inte och påstå att det går snabbare att skriva nytt! Det argumentet har jag aldrig sett fungera i verkligheten där jag jobbar.

Annars är det här en nyttig diskussion - en god programmerare bör alltid eftersträva att förbättra sina kunskaper och dit hör definitvt att skriva kod som andra programmerare kan förstå och vidareutveckla. Frågan är bara om det finns något "ultimat sätt" att skriva - vi kanske får acceptera att alla människor är olika och vi kommer nog aldrig att tänka likadant och därför kommer vi aldrig att koda likadant. Och tur är väl det! Då skulle vi aldrig kunna utvecklas...

Axident

Hej... Så sant så. Men vad händer om din kod förändras och du har mycket kommentarer? Är du säker på att dessa kommentarer uppdateras? har man tid till det? vad hände rom du struntar i att ändra alla kommentarer då tror ju utvecklaren att koden gör annat än vad den gör. Detta är oxå ett stort problem.
Jag av erfarenhet vet hur lätt det är att ändra andra kommentarer då man fixat en bugg för att man kanske inte var helt insatt i hela rutinen utan bara insåg att = skall vara != ...

Jag syftade inte på API kommentarer. Jag nyttjar dem för att intellisense skall visa andra utvecklare vad metoden gör. Absolut, ingen tvekan. Jag syftar mer på de kommenterar man lägger i scopen m.m.

Jag vet att kod kan se usel ut, men om man en gång kommenterat kod men man inte har någon bra självbeskrivning i syntax, variabler etc... så är ju dessa kommentarer en stor hjälp för att även vid bugg fix kanske snygga till koden och dra ner på antalet kommentarer. Det som ny utvecklas måste ju inte byggas på samma synga som det man gjorde för två årsedan?

Och det är helt rätt det du säger, du kommenterar mycket där du skall göra saker för framtiden.
Jag avslutade faktiskt med att tala om det på min sista rad på bloggen:
"A good time to use comments is when you don’t know what to do, to comment future modifications. "

Jag har även omformulerat vissa bitar i min text, då jag personligen anväde för grova ord.
Självklart kan en väl beskrivande kod även kommenteras för att underlätta för andra. Det betyder inte att koden är kass. Men det betyder att andra inte är tillräckligt bra och behöver kommentarerna för att förstå kod som egentligen talar för sig själv. Det är ingen nackdel att inte vara tillräckligt bra, de som tar åt sig och känner fasen jag gör nog en massa kommentarer i onödan kan ju bli bra genom att ta åt sig och sniffa vidare på områden för att strukturera koden bättre. Alla har vi varit lamers eller hur?
Jag skrev jätte sunkig kod för bara något årsedan. Och anser fortfarande att jag lär mig effektivisera koden varje dag som går. Och eftersom jag gillar att studera i ämnet lär jag mig nya och smartare trick eller lösningar som jag även presenterar här eller på bloggen. Sedan är det ju inte alltid så att jag använder mig av dem. Det är mer tankar hur man kan göra. Inte att man skall göra. Vill man sedan göra som jag skriver är det upp till var och en. Det är en smaksak... Bara för att jag skriver om ett ämne betyder inte det att jag gillar det. Och oftast hinner jag skriva mina personliga åsikter eller så gör jag det inte. Det är därför jag öppnar för diskusion här. Så man kan prata mer om ämnet. Blogga lite aptit retare för att få ett huvudmål :-)

Mvh Johan

Om koden förändras så förändras även kommenteringarna i den mån det behövs! Som jag sa: Jag skriver ingen kod innan jag har kommenterat hur saker och ting skall flöda i programmet. Så om jag skall göra någon förändring i redan färdigskriven kod så är min första punkt att gå igenom kommentarerna och förändra dem vid behov. Det gör att jag försöker också att undvika allt för mycket kommentering av ren självbevarelsedrift.

Som jag också sa: Nyutveckling av kod gör saker och ting MYCKET enklare och då behöver man inte bry sig om gammal dynga - men oftast är man tvungen att göra förändringar i redan existerande (och ofta dålig) kod och då blir det en hel del besvärligare.

Något som jag hellre ser som en viktigare del i bra kod är att man är konsekvent. Om du har funnit ditt "personliga" sätt att koda - gör då det KONSEKVENT. Det gör det lättare för mig att sätta mig in i ditt programmeringssätt och kan då lättare förstå kod som jag skall ändra i. T.ex. vill du deklarera alla variabler på modul-nivå så gör det då ALLTID. Kom då inte med någon deklaration i en sub/funktion, och använder du prefixer på variabler så gör det då ALLTID och släng inte in någon "Dim i As Integer"... osv...

Nu skall jag läsa vad alla andra har skrivit också...! :)

Axident,

Vad johan utgår ifrån, men som inte riktigt framgår, är att detta är en del i en utvecklingsprocess där man redan har färdiga kravspecar och system design. Då vet du flödet i programmet eftersom man troligen har någon form av uml-diagram, use case, state-diagram etc. som underlag.

Axident,

Hej, vet ej om jag var tydlig, men hoppades på det.
Många, kanske inte du säger till mig, men man kanske inte har tid att refactorera och måste skriva en massa kommentarer. Det köper jag, men jag köper inte att man väljer en massa kommentarer före refactorering. Sedan så säger en del, man kanske inte hinner skriva en massa kommentarer heller för att man inte har tid. Då är det ännu viktigare att man kodar strukturerat så man kan förstå någerlunda.
Sedan säger andra, Jag har inte tid med refactorering. Hur har man då tid att kommentera? Några säger att koden kan bli rörig och då måste man ha kommentarer. DÅ anser jag, skriver man rörig kod så har man oftast brottom, då kommer säkerligen kommentarerna bli lika röriga.
Du har kanske tid att fixa en bugg, men inte tid att uppdatera andras eller dina egna kommentarer. Av samma skäl då man struntar i kommentarer kommer man strunta i att ändra kommentarer som redan finns. Det är kostasamt att ändra kommentarer, men mindre kostsamt att ha en självbeskrivande kod. Då du oftast har bättre kvalité.

Så summeringen av alla kommentarer jag fått bevisar att självbeskrivande kod är effektivare. Och som sagt du skriver kommentarerna för att andra skall veta vad du gjort eller för att du själv skall veta vad du gjorde. Om du inte kunnat berätta det med koden så har du oftast gjort dålig kod. OBS! Oftast inte alltid.

Jag kodar aldrig på ett företag utan att man har en Guideline för strukturen. Vart man placerar variabler, etc.. Så jagär väldigt noga med att ha kod som är strukturerad på samma sätt hela vägen. Dock kan man komma på smartare lösningar och strukturera om sin kod. Men det är utvecklingens väg till något effektivare. Även här är det då viktigt att man har (om man jobbar i team) en uppdaterad Guideline.

Ang gammal vs nyutvecklad kod. Så pekar jag inte på gammal kod i mitt argument om självbeskrivande kod. Jag skiter i gammal kod. Är den gammal så fine, går det att snygga till den så gör det. Gammal kod är oftast även sämre skriven än ny, då man lär sig nya saker. Då är det viktigt att man strukturerar om den gamla koden så den speglar mer den nya så gott det går. Skiter man i att kommentera en massa så refactorera gammal kod istället för att ta den tiden åt att uppdatera en massa kommentarer.

Jag säger heller inte att du är kass som kommenterar lite om du anser att du måste göra detta i din kod. Men om du verkligen måste säga vilket flöde en metod har i en kommentar så kanske det inte går att läsa av flödet tidigt i koden? då har ju redan där ett svar på varför. Koden kanske inte håller så hög kvalité trotts allt. För varför läsa några rader kommentarer hur koden fungerar när du sedan ändå läser koden? dubbelt arbete tycker jag. Du kommer ju ändå se flödet i just koden och läsa koden som om det vore en förklaring hur flödet lyder.

Mvh Johan

Det vore ju en dröm om det alltid fanns uml-diagram, state-diagram, kravspecar etc... Jag har nog haft otur i alla år som har jobbat på företag som inte förstått vikten av den första grundläggande analysfasen.
Det har alltid varit att om jag har sagt att ett jobb tar 50 timmar så klagar kund och chefer på att det är för lång tid - och därför är det alltid dokumentation och analys som får stå tillbaka. Trots att det till 100% alltid slutar med att ett sådan förfaringssätt tar MER än de ursprungliga 50 timmarna... Har inte lyckats få någon chef eller kund att begripa detta. Nåja... det är ju ett annat problem!

Helt rätt - Självbeskrivande kod är det bästa att eftersträva. Liksom en guidline. har dock bara jobbat på en enda arbetsplats som haft en guidline... Och upptäckte efter redan ett par timmar att den inte var uppdaterad...

I allmänhet så tenderar all form av dokumentation att bli inaktuell för att man ändrar kod och arbetssätt utan att ändra i dokumentationen. Därför hävdar jag ändå att kommentering i kod av arbetsflödet (såsom man gör i kravspec och uml-/state-diagram) ändå kommer i slutändan att vara mest aktuell eftersom det är det naturliga stället för en programmerare att skriva.

Men jag håller med dig i princip...

Axident,

Därför man har någon som är kvalitetsansvarig som får ansvara för kvalitetsplanen. Tyvärr är det som du säger att allt för många chefer inte förstår sig på processen och tycker att det bara är ytterligare en utgift =/

Axident...

Det där med porblem med chefer och folk som inte direkt vill förstå är du inte ensam om. Har alltid haft samma problem oxå. Det enda recept mot det hela är att man själv får ha en egen process så gott det går. En process som kanske fungerar bäst i dessa förhållanden. Jag brukar oftast analysera och skissa lite innan jag börjar koda en sak. Jag delar oftast upp arbetet i itterationer, rätt korta sådana, då hinner jag med min analys och design samt implementation och testing samtidigt som jag kan visa chefen att jag har nått man kan se. Det är oftast detta de har problem med. De vill hela tiden se resultat ett papper, en massa skisser eller brainstormin gmöten utan kod gör dem tokiga. De tror lixom inte man gör något och känner sig mer trygga när de ser saker, Kvalité har alltid kommit i efterhand, det är nordiska länder rätt beryktade om. :-( Men det är ju oftast inte vi utvecklare som bygger dålig kvalité utan ledningen som hindrar oss från det. Men vem får skiten om saker inte fungerar som de skall? Jo vi...

Testa att inte skriva kommentarer om ditt flöde i koden utan försök se till så koden ger en klar bild på flödet genom god struktur och bra namn. Om det ändå blir svårt måste man nog kommentera. APIerna anser jag att man bör kommentera. med <summery> taggarna etc...

Jag kan ibland tycka att kommentarerna är i vägen för koden, att det blir så plottrigt så jag inte vet vad saker gör, jag blir då mer beroende av kommentarerna än vad koden säger. Detta i de fall då man stöter på kod från kommentarglada människor.

Hur många rader kod brukar dina metoder ha? om de överstiger 100 är de oftast för stora, helst skall de ligga runt 10-20 rader eller nått. Med väl beskrivande ord. Har man 100 eller mer kan man mycket väl refactorera ner dem till kanske 10 metoder med 10 rader vardera. eller to m tack vara refactorign bli av med en massa rader då man har redundatn data, eller data som har samma mönster men olika variabler. Då kan man bygga en metod som tar varibeln som input istället och få en mer generell hantering. Ex:

<code>
if(minSträng == null || minSträng.Length == 0)
do stuff..

if(minSträng2 == null || minSträng2.Length == 0)
do next stuff
</code>

Det tar tid att skriva varje if och kommer du sen på att 0an skall ersättas med 1 så har du flera ställen att ändra på. Oftast kommenterar man här oxå.
typ:

<code>
//Kollar om minsträng är null eller har 0 som längd, då skall jag kasta ett exception.
if(minSträng == null || minSträng.Length == 0)
throw new Exception();
</code>

Här har man en typiskt onödig kommentar. Läser du de två andra raderna så ser du ju vad du gör, måste man verkligen berätta det? Om denna hantering upprepas för alla stängar man har så är extract method en fördel, där man ta och anger ett namn som påminner om kommentaren.

<code>
public void CheckIfNullOrEmpty(string value)
{
if(value== null || value.Length == 0)
throw new Exception();
}

CheckIfNullOrEmpty(minSträng);
CheckIfNullOrEmpty(minSträng2);
</code>

Får vajre Check minimerade jag koden från 2 rader till en rad, och då syntaxen för kontollen är kortare vinner jag utv tid m.m. Om en bugg finns i checken så ändrar jag bara på ett ställe.
Ju renare och smidigare kod man har, ju lättare att orientera sig i den och läsa av vad man gör.

Sedan finns det ju de som gillar kommentarer för att de tycker det är snyggt.

Mvh Johan

Johan:
Mina funktioner och subrutiner brukar sällan överstiga 20-talet rader... Om jag skriver mer än 20 rader i en funktion så kommer jag direkt att börja fråga mig själv om jag inte har komplicerat saker och ting eller om jag egentligen försöker göra allt i en funktion där man borde dela upp på två eller flera funktioner. Eller om jag rentutav har missuppfattat vad som skall göras.

När man håller funktionerna små (dvs med minsta möjliga antal rader) så medför detta ett antal fördelar:
- Koden blir lättöverskådlig
- Det blir lätt att ta bort eller lägga till ny funktionalitet i sitt program vilket minskar utvecklingstider och kostnad
- Kommentarer blir ofta överflödiga
- Man kommer ett steg närmare med återanvändning av kod...
mfl

eh... just det - refactoring... Hmm. Känns som jag predikar för redan frälsta..! :)

"Det finns de som gillar kommentarer för att de tycker det är snyggt." - Det var det värsta!! Kommentarer för kommenterandets skull (eller för att det är "snyggt") är fullständigt bortkastad tid...

""Det finns de som gillar kommentarer för att de tycker det är snyggt." - Det var det värsta!! Kommentarer för kommenterandets skull (eller för att det är "snyggt") är fullständigt bortkastad tid... "

mm. tyvärr, träffat på en del utvecklare som faktiskt tycker koden blir snyggare med en massa kommentarer... Men oftast beror det på att de inte kan skriva självbeskrivande kod.

Jag tyckert du verkar ha en helt ok kontroll över ditt skrivande, det är kul. Återigen syftar jag faktiskt på de som skriver kod för att förklara kod som de själva inte förstår sig på. Kod med över 100 rader per Metod... urgaha... Låter som du har rätt bra struktur och lättöverskådlig kod. och som du säger, du minimerar antalet kommentarer pga detta. Det är det jag vill komma fram till. Strukturerad och bra namngiven kod kräver knapt några kommentarer och i många fall kanske inte en enda kommentar.

Mvh Johan