JcV

Ernie: Vel du kom vel egentlig ikke med noe godt poeng her. Jeg sa at det man kanskje bør kommentere er struktur og avanserte algoritmer, slik som denne du gir som et eksempel her.

Men jeg finner ikke denne koden til å være et godt eksempel, den er både lang (bør deles opp i flere ledd som kan testes individuelt.)og variablene dine er lite beskrivende. $mUcs4 ville ikke ha sagt meg eller noen andre noe som helst. Derfor MÅ man kommentere dette for å forstå hva som hender.

Poenget mitt er at man bør heller bruke mer tid på å skrive mindre og ryddig kode framfor eksemplet ditt her.

Hvordan presentasjon tenker du på? Hvis du skal ha animasjoner blir det fort litt tullete å ikke bruke powerpoint.

Dette : $this->bruker->ID == 4 betyr at du har en variabel inne i et objekt, som igjen ligger inne i det objektet du kaller koden fra.

Jeg tar ikke helt hva du spør etter, men hvis du ikke sliter med denne tanken, hadde jeg sett litt nærmere på objekt orientering.

Jeg tror faktisk jeg aldri hadde latt en bruker få lov til å sette inn html i et tekst felt. Fort så begynner de å kopiere inn tekst fra Word og andre programmer som har med seg en del tagger som kan gi deg ganske mye krøll på siden din.

Jeg stripper altid bort html og andre tags før jeg setter noe inn i basen min.

Tenkte jeg skulle høre litt med dere som har erfaring fra litt større programmeringsprosjekter. Hittil når jeg har programmert noe nytt begynner jeg som regel med å programmere litt fort og "gæli", til jeg har fått det til å fungere. Deretter går jeg gjennom og rydder opp, renamer variabler og kommenterer kode.

 

Har hørt mange si at det er lurt å være nøye og ryddig fra starten av når man programmerer større ting. Men er ikke det mye ekstra jobb all den tid koden sikkert må omgjøres kraftig.

 

Hvilken praksis anbefaler dere?

Jeg tror at de som mener at man kan planlegge og konstruere store prosjekter uten å reskrive kode, faktisk ikke har prøvd seg på store ting. Jeg er helt enig at man bør holde seg til en kode standar fra begynnelsen, samme hva den er bare man holder seg til det. Etter vært vil det sitte i fingra og du trenger ikke å tenke så mye på det. Det finnes mange nettsider og bøker om dette temaet, så ta foreksempel en titt på denne siden : http://www.dagbladet.no/development/phpcodingstandard/ .

Men alle programmerer som jobber med utvikling, vet at man bør refaktorere koden etter at man har skrevet den. Del opp koder i mindre logiske biter ved hjelp av objekter eller funksjoner. På den måten kan du lett reskrive og teste deler av koden din i etterkant.

I forhold til kommentering, føler jeg at det faktisk ikke er så veldig viktig!.. ja dere høret meg .. lol ..

Kommentering inne i kode burde ikke være nødvendig, konsentrer deg heller om å skrive ren kode, mye luft og gode navn på variablene, så vil det være like enkelt å lese koden som å lese kommentarer. Det man kanskje bør kommentere er generelle ting som struktur og avangserte algoritmer som er vannskelig og snurre hode sitt rundt.

Dette er et relativt komplekst problemstilling. Med utrolig mange løsninger.

Jeg kjører for eksempel alle html kode inn i noe jeg kaller ett presentasjons objekt. Det er egentlig bare en vanlig php klasse som extends en baseklasse. Alle presentasjons klassene mine har da en atomisk identifikator som da metoder i baseklassen sjekker opp mot. Samtidig lager jeg aldri linker på vanlig <a href .. måten , men heller bruker en metode i baseklassen som jeg kaller Link(), som da kaller opp sider ut ifra presentasjons objektets identifikator. På den måten kan jeg sjekke sikkerheten i forhold til siden før jeg laster de opp og eventuelt ikke vise linken.

En annen måte er og bruke sql injection, slik at du lager joiner mot sikkerhets profilene dine inne i selve sql spørringene. På denne måten får du aldri opp verdier brukeren ikke skal se, men du får opp sidene.

Som sagt er dette er ganske stort tema, og det jeg har opplevd er at selve sikkerhets systemet, aldri bør skrives tilslutt, men heller først. På den måten må du lage et rammeverk som passer til sikkerheten og ikke omvendt.