Her listar eg opp nokre råd eg meiner er nyttige når ein skal programmere.

Sjølv er eg UNIX-bruker, og dette innlegget er nok delvis farga av det, men dei fleste råda burde fungere uansett kva språk du skriv i.

Følgjande punkt er viktige:

• Papir og blyant. Før du tar til å kode må du vite kva du skal skrive.
• Kunnskap om språket du skal skrive.
• API
• Dokumentasjon som høyrer til språket, eks. php.net for php.
• Feilmeldinger.
• Tid til å fikle

Papir og blyant...
Mange som skal byrje med programmering finn dette underlig, sidan det å kunne programmere er å mestre datamaskiner på øverste nivå, langt over snittet av befolkinga. Likavel vil eg påstå at dette er nøkkelen til eit vellukka program!

Du må kunne formulere det du skal skrive på morsmålet ditt (norsk?) før du har sjans til å skrive det i eit såpass formalisert språk som dei fleste programmeringsspråk er. Skriv normal norsk, og forklar kva du vil gjere.

Kunnskap om språket
Samme kva språk du vel å skrive i, er det viktig at du kan grunntinga i språket, slik som løkker (if-, elseif-, when-, dowhile-, for-løkker etc etc.), så du ikkje brukar tid på slikt. Om du ikkje kan det, har dei aller fleste språk relativt gode tutorials som du finn med google (Søkeord: <navn på språket> tutorial, eks C++ tutorial).

API...
Om du skal skrive noko som gjer litt meir enn Hello World må du til med API - Application Programming Interface. API er som namnet seier et grensesnitt til eit anna program, som gjer at ein slepp å finne opp hjulet på nytt kvar gong. Ein del språk, slik som PHP har mange API innebygd, slik at ein slepp tenkje på det (Døme: php nyttar t.d libcurl for ein del http-funksjonar), medan andre treng ein deklarasjon over kva API ein vil bruke, og kor kompilatoren kan finne dei APIa. Avhengig av kva språk ein skriv i er ulike API tilgjengelege, men nemneverdige API er Internet Explorer sitt, som kan nyttast til HTML-rendering og slikt.

Det å lære seg å nytte API handlar stortsett om å ikkje finne opp hjulet på nytt, men bruke det andre har skrive. API har den fordelen at dei er somregel lettare å nytte enn å implementere ting på nytt sjølv, men til gjengjeld skjer det endringar i API som kan føre til omskrivingar i koden din.

...og dokumentasjon
Før eller seinare treff du på eit API du aldri har sett eller hørt om før. Det har kanskje ein ukjent funksjon, som tek imot tre ukjende parametrar. Då gjeld det å ha dokumentasjonen for APIet og språket ein skriv i klart. Det meste av dette ligg på nett, iallefall for dei APIa som er mest nytta. Igjen er google ein sikker treffar!

Dokumentasjon om språket
Du bør også ha litt dokumentasjon om språket, slik at du kan finne kva som skjer med ulike funksjonar som er innebygd i språket. Det er bortkasta tid å spørje her på forumet kva sprintf(); gjer til dømes, det svarer google på betre. Så om du finn ein funksjon du får lyst til å bruke; google it! Om du leitar etter ein funksjon finst den antakeleg. Google it! Og som nemnt bør du ha brukbar kunnskap om språket, slik at du enkelt og raskt kan lage løkker, arrays og anna Nyttig(TM)

Feilmeldinger
Så du har fått ei feilmelding? Det får vel alle, sjølv proffane. Mange språk gir faktisk ganske nyttige feilmeldinger, som det er lurt å lese. Om du har lese feilmeldinga, og ikkje ser kva feilen er, løner det seg ofte å printe 10 linjer kode før og 10 linjer kode etter feilmeldinga, og lese gjennom den steg for steg og sjå kva den faktisk skal gjere, og kva koden du har skrive gjer. Her kjem igjen papir-versjonen, på norsk, av programmet til nytte. Om du er lat søkjer du etter feilmeldingsteksten på google, og håper at du ikkje er den første som har fått den. Når du har gjort dette (ikkje nødvendigvis i denne rekkefølga; googling er ofte det første eg gjer) så kan du kontakte diverse forum rundt om, bruke IRC o.l for å finne ut av det.

Tid til å fikle
Programmet er ferdig, og fungerer slik som papirkopien din skulle fungere. Då er du nesten i havn. Du bør ta deg tid til å fikle, prøve kva som skjer om ein brukar tastar inn feil data dersom programmet tek imot input, finne ut kor ting verkar forvirrande, og slikt. Finpussen med andre ord. Om du skal bruke programmet sjølv er ikkje det viktigast.

Andre viktige punkt
All kode bør dokumenterast. Å ta fram ukommentert kode er vondt, sidan det er raskare å skrive kommentarar i koden enn å prøve å finne ut kva den if-løkka gjer, når du tek framigjen koden om 5 år.

Ellers meiner eg at folk bør halde seg langt unna Basic, av den enkle grunn at det øydelegg all sans for koding. Ein får rett nok resultat relativt raskt, men til gjengjeld lærer det folk dårlege vanar, som dei har lite att for seinare. Å kunne VB er ikkje å kunne programmere, og det er ikkje så mykje verre å skrive i andre språk, t.d Java, C# (som er eit bra språk etter det eg har høyrt), PHP, Python (min personlege favoritt, sjølv om eg berre såvidt pirkar i overflata).