Med anledning av inläggen i tråden 'Lägga ihop' tänkte jag att det kunde vara intressantmed en diskussion kring programmeringsstandard.

Vad är bäst?! Kompakt, 'smart', kod - eller lättläst, 'pratig', kod?!

Diskussionen uppkom efter kommentarer om man skall använda sig av VB:s inbyggda konstanter, som t ex 'vbChecked' eller de konstanternas faktiska värde som t ex '1' när man läser av värden i t ex en CheckBox.

Min åsikt är:

* Använd indentering (indragning av kod på rader som t ex ingåe i el noop eller en funktion) - arbeta fram en egen standard för indentering och HÅLL er till den, försök följa några av de mer erkända varianter som finns. För det mesta brukar de företag man arbetar på ha arbetat fram en färdig standard som man SKALL hålla sig till. Varför? Koden blir mer lättläst och finns det en standard så är det lättare för
andra programmerare att läsa ens kod när det senare behövs justeringar/buggfixar/ändringar i den...

* Använd VB:s inbyggda konstanter 'vb####' där sådana finns att tillgå. T ex för att läsa av eller sätta bakgrundsfärgen på en knapp (använd här konstanter för system-färger framför konstanter för 'hårdkodade' färger).

* Kommentera koden!!!

* Kommentera inte FÖR mycket, bara tillräckligt för att du själv och andra programmerare skall förstå speciellt svåra delar av koden eller för att man skall få lättare grepp på stora delar av koden - det logiska flödet.

* Arbeta gärna fram en standard för att skriva enhetliga kommentarer i början av varje funktion/subrutin/egenskap (i alla fall de publika delarna, varje händelseprocedur behöver INTE kommenteras). Skriv alltid dit kommentarer i varje modul-huvud, dvs överst i varje Class/Module och Form. Kommentarerna bör innehålla vem som skrivit koden, när den skrevs, när den ändrades (och vad), samt en liten beskrivning av vad den skall göra, dess interface och vilka parametrar den kräver etc...

* Använd en standardiserad felhantering på så många platser som möjligt och försök ge ett enhetligt felmeddelande som beskriver vad som gått fel och varför - men i en release är det nog bättre att logga eventuella fel internt i filer/databasen och låta den vanliga användaren slippa kryptiska meddelanden på sin skärm...

* Använd beskrivande variabelnamn av LAGOM längd. Gärna följande Microsofts standard 'camelCase' eller 'PascalCasing' för stora och små bokstäver i längre variabelnamn.

* Angående Ungersk Notation är jag för tillfället lite splittrad. Visst ser man lätt variabeltypen på enklare variabler om man använder sig av s.k. Ungersk Notation - men som Microsoft nu uttrycker det så blir det omöjligt med alla de flera hundra komplexa objekt och variabeltyper som dyker upp i modernare programmeringsmiljöer. Kanske skall man behålla det för de enklaste typerna och låta de mer komplexa ha mer beskrivande namn bara? I .Net räcker det som sagt med att hålla muspekaren över en variabel för att se dess datatyp, men detta funkar ju inte på utskriven kod... *ler*

Fler synpunkter?!

Hm, detta inlägg kanske inte passade SÅÅÅ bra i detta forum?! Ber om ursäkt i så fall... tråden började ju ändå här i det andra inlägget...

// Qez

Använd inte för djupa indent! det är inte kul att läsa all kod längst till höger på skärmen!
Själv använder jag två space i VB, tre i .net samt sql.

Indentera inte allt!
Jag har sett folk som indenterar mellan Open och Close, samt snygga indenter på input/output-funktioner.

Själv använder jag en enkel variant av ungersk notation nämligen:
s = String
n = Numerisk (long, int, double, currency osv)
v = Variant
o = Object

och några tilll, det ger lättskriven, lättläst kod vilket är viktigt för mig.

Håller med båda föregående talare.
Dock tycker jag att Trash kommer med ett bra påpekande.
Koden ska inte bara vara lätt att läsa, den ska vara lätt att skriva också.

Tycker
/Magnus

Vad menar du med standardiserad felhantering?
<code>
Private Sub Test
On error goto Test_Err

Exit Sub

Test_Err:
msgbox Err.Description
End sub


</code>
standardiserad felhantering är något som int hör hema i programmering. Lat programmerare använder det som ursäkt för att slippa skriva egen felhantering.<br>
<br>
Felhantering bör vara utförmat enhetligt över applikationen. Men skall ta till vara på det förutsatta fel som kan uppstå. Samt även hater oförutsetta fel på ett så korrekt sätt som möjligt.<br>
<br>

Kul med alla inlägg!

För det mesta finns det väl en standard i det företag där man jobbar, då får man för det mesta rätta sig till den, även om man oftast får vara med och påverka...

Har färdiga dokument med sådana standards även där jag jobbar idag, sedan får man vidareutveckla dem efterhand som luckor uppstår. Vi har valt att använda Ungersk Notation, men den korta varianten med endast ett tecken för de grundlägande variabeltyperna. Vi använder dock även enstaka tecken för att markera en variabels 'scope', om den är global, modulär eller enbart 'existerar' inom den aktuella proceduren (så slipper man trycka 'Shift+F2' på alla variabler för att se vart de har deklarerats någon stans (och sedan 'Ctrl+Shift+F2' för att komma tillbaka dit man var)) *ler*. Vi använder sedan ÄVEN enstaka tecken för att markera om en viss variabel är in-, ut- eller både in- och ut-data (ByRef) i en procedur, samt att privata procedurer ÄVEN markeras med sitt scope och ATT de är just en procedur.

Blir en hel del, men man vänjer sig snabbt faktiskt och fördelen är att alla på företaget snabbt kan läsa andras kod, så i DET fallet är det INTE upp till var och en...

Sedan har vi (givetvis) standardiserade 'kommentars-huvuden' för början av modulerna och de viktiga procedurerna - fördelen är samma här, alla vet vart de skall leta efter information om en specifik metod som de kanske skall ändra i, även kortfattade beskrivningarna av ändringarna, vem och när de utfördes etc, finns med i kommentarerna. (Inte alltid man har lust att gå in i SourceSafe och kolla...).

Fördelen med enhetliga kommentarer är flera, vi har t ex inhouse-tillverkade verktyg som tillverkar dokumentation över objektmodeller etc utifrån kommentarerna, sedan tillverkar det enkla webbsidor som ger en bra översikt över alltsammans. Tyvärr kan jag inte släppa de verktygen här, men ni kan säkert tillverka egna efter behov. Är man fler än EN programmerare i samma projekt, över en längre tids utveckling, så är det nästan nödvändigt - förutom den vanliga dokumentationen i ren pappersform, UML-diagram, UseCases etc etc etc *bläh?* *ler*

Håller fullständigt med om att två spaces räcker mer än väl *ler* för indentering, att sedan bryta långa rader med '_' på ett bra sätt gör också koden lättläst (så man slipper scrolla i sidled!)

T ex för en tilldelning av en SQL-sats till en variabel:

psSQL = "SELECT id, fnamn, enamn, kommentarer " _
& "FROM kunder " _
& "WHERE fnamn = '" & isFNamn & "' " _
& " AND enamn LIKE '" & isELetter & "%' " _
& "ORDER BY id"

Det viktigaste är nog ändå att man utvecklar en egen standard (om man inte påtvingas en från ett företag) och håller sig till den.

Vad gäller standardiserad errorhantering menade jag bara att det kan va bra att 'skicka' felmeddelanden till ett egenutvecklat objekt som visar upp felen på ett standardiserat sätt med Caption och Ikoner samt t ex ser till att logga ytterligare information till en textfil/databas/etc.

Att använda 'Goto' (utom i On Error...), eller 'End' eller 'On Error Resume Next' (utom i vissa fall?) anser jag bara är 'lata' lösningar då man inte orkar se till att interna objekt och formulär etc laddas ur och avslutas på et korrekt sätt. :-) (ja, ja, inga *pekpinnar*, men det är la bra att lära sig 'rätt' från början?! Var rätt tuff på detta när jag jobbade som lärare.. *ler*).

// Qez - short for 'Qezlot' - short for 'Quetzalcoatl'

Glömde nämna att det finns en del bra hjälpmedel där ute, som t ex 'Code Smart' där man kan lägga upp mallar för sina standardiserade kommentarer så man lätt kan sätta in dem, även standardiserade lösningar för felhantering etc kan lösas av den produkten - personligen är jag dock inte helt nöjd med produkten än, den har vissa 'barndoms-fel = buggar' som irriterar ibland.

Angående felhantering så finns det även där en del externa produkter som kan hjälpa till, som t ex 'FailSafe' som i princip låter en applikation gå fel, ger möjlighet för användaren att rapportera felet och sedan försöker den köra vidare, så man i största mån skall slippa elaka 'guru meditations', dvs minnesdumpningar och abrupta avslut av applikationen som ju kan ge användarna viss besk bismak för att fortsätta använda produkten (även om den bara är en Alfa eller Beta). Nackdelen med FailSafe är att den skriver in en hel del kod i samtliga procedurer samt lägger till et par egna moduler för centraliserad felhantering, men detta kan man senare välja att 'rensa bort' automatiskt när man närmar sig en mer stabil produkt.

// Qez

PS! Heja VB.Net etc, med sina Try - Catch! ;-) DS!

Hej
Måste göra ett inlägg här.
Att skriva ett program är en konstart, samma som att
skriva en roman eller novell.

Dvs jag vill inte ha nån djävla pekpinnar hur jag skriver
eller disponerar mitt alster.

Det är ju ganska bra om det är tydligt och lättläst men
budskapet är skriv och indentera som du vill.

Dvs fall inte in i dessa "beserwisser nissars" bullskit

Det enda som kommer att bedömmas är FUNGERAR programmet.
Var romanen bra ?

Tack för ordet
Sven

Titta bara på hur folk skriver här ovan, tänker på avstavning Tydlighet
Finns ingen djä.... som orkar läsa deras bull

DS

>Det enda som kommer att bedömmas är FUNGERAR programmet.

Nja, en viktig sak är att det ska vara lätt för andra att förstå programmet. Med enhetligt indenterad kod och enhetlig namngivning blir det betydligt enklare. Nu beror det ju givetvis på vad programmen ska användas till, och vem som ska göra ändringar i framtiden, men av erfarenhet har jag lärt mig att det underlättar för mig själv om jag har skrivet programmet på ett enhetligt sätt.

/Johan

Hej
Finns ingen motsättning mot det du skrev
frånsett att det var svårläst.

Jag köper inte att någon kommer med pekpinnar.

Fungerar programmet.? Ja oki finns inte mer att tillägga.

Ds

Förutom om man programmerar för något företag, då får man snällt följa deras 'pekpinnar' för att kollegor senare skall kunna modifiera koden, även om ens alster är 'konstverk' i de fallen så ägs koden av företaget och de har rätt att sätta upp vissa strukturella regler som gör koden mer användbar och mer lättunderhållen i framtiden = mer värdefull i långa loppet.

Kod som inte följer enklare standards (t ex de som Microsoft rekomenderar) tenderar att bli mycket svårare att underhålla i framtiden, och då krävs det mycket mer tid att sätta sig in i koden för att kunna leta buggar, även om det var man själv som skrev programmet en gång i tiden - ingen skriver buggfria program!

Skulle jag envisas med att använda en 'egen' kodstandard eller inte använda nå'n alls så skulle jag nog snart få se mig om efter ett annat jobb, en anledning så god som någon att följa uppsatta 'pekpinnar' tycker jag!

Försökte 'styra' in mina elever på en strukturerad programmeringsstil så fort som möjligt, ÄVEN när det rörde små enkla rutiner eller testapplikationer, lika bra att lära sig rätt från början. Där märkte jag att nybörjare hade ett övertag mot äldre hemmasnickrare till programmerare trots att de givetvis kunde överblicka möjliga lösningar mycket snabbare (i början).

// Qez

Nu gör jag väl nån upprörd men men...

Eftersom det är bra att ha en personlig standard när man skriver kod (specielt när man är nybörjare och ska lära sig) tänkte jag (om ingen annan tänkte det före) skriva en artikel om detta.

Alla Tips och egna erfarenheter kring kodskriving skickas till min Imail.

På tiden att detta ämne äntligen kom upp // R-mus