Jump to content
Sign in to follow this  
qdos

Spre koden over flere sider

Recommended Posts

Nå begynner jeg å få vel mye kode, og jeg bruker mye tid på å finne frem. Hva er den beste måten å strukturere koden på? Jeg bruker selvsagt //Fritekst og {Fritekst} for å lage huskelapper, men koden blir ikke noe kortere av det.

 

Finnes det en måte å splitte .pas-siden på, slik at jeg kan ha en side for hver del av koden? Eller er det en bedre måte å dele opp koden på?

Share this post


Link to post

Så lenge du skriv strukturert, så vil koden din ikkje vere uoversiktlig sjølv med 1000 linjer med kode. Eg har sjølv skrive program der ei fil inneheld godt over 10 000 linjer med kode, og det meste av koden er stort sett svært lesbar.

 

Mange har svært mykje imot å følgje ein satt stilart når dei kodar, men Object Pascal Style Guide er definitivt verdt å lese uansett. Dersom du skriv kode slik som det er foreslått her, vil koden din vere svært lesbar.

 

Dersom du meiner at du kan strukturere koden din logisk inn i grupper; t.d. ting som har med stringbehandling å gjere, kan du legge dette som funksjonar i andre units (.pas-filer), men det kan vere vanskelig avhengig av kor mykje erfaring du har.

 

Les Object Pascal Style Guide, den kan eg sterkt anbefala. Sjølv om det ikkje heiter Object Pascal lenger, men Delphi. Så det så. :)

Share this post


Link to post
Dersom du meiner at du kan strukturere koden din logisk inn i grupper; t.d. ting som har med stringbehandling å gjere, kan du legge dette som funksjonar i andre units (.pas-filer), men det kan vere vanskelig avhengig av kor mykje erfaring du har.

Hvordan kan man peke til andre .pas-filer, og hvordan skal .pas-filen det pekes til se ut?

Share this post


Link to post

File->new->unit lager en ny .pas fil

 

får å ha aksess til det som er i den nye .pas fila må du peke på den fra den orginale .pas fila

 

la oss si at den orginale heter unit1, og den nye unit2, da vil det se sånn ut

 

unit Unit1;



interface



uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Unit2;

Share this post


Link to post
Vil dette ha noen betydning for hastighet eller størrelse etter kompilering?

 

tviler jeg sterkt på.

å spre koden er god OOP-skikk og gjør gjennbruk av kode kjempelett

Share this post


Link to post

Får ikke tatt i bruk den nye .pas-filen uten videre. Den nye uniten ser slik ut:

unit Unit2;



interface



implementation



end.

Må jeg deklarere prosedyrene i unit1? Betrakter Delphi unit1 og 2 som en hel unit ved kompilering? Finner ingenting om dette på nettet...

Share this post


Link to post
Må jeg deklarere prosedyrene i unit1? Betrakter Delphi unit1 og 2 som en hel unit ved kompilering? Finner ingenting om dette på nettet...

 

Du deklarerer og skriver prosedyrer i Unit2. I Unit1 leiter du så etter uses-klausulen (heilt øverst i fila), og legg til Unit2 i lista. Du treng då ikkje gjere noko meir for å kunne bruka metodane som ligg i Unit2, direkte frå Unit1. Dersom du har funksjonar i Unit2 som har tilsvarande namn som funksjonar i Unit1, kan du nå desse ved å bruke Unit2.FunksjonsNavn(Parameter).

Share this post


Link to post
Så lenge du skriv strukturert, så vil koden din ikkje vere uoversiktlig sjølv med 1000 linjer med kode. Eg har sjølv skrive program der ei fil inneheld godt over 10 000 linjer med kode, og det meste av koden er stort sett svært lesbar.

 

CodeRush er visst nok implementert stort sett i en fil... Vare et intervju med utvikleren i et Delphi Magazine for noen måneder siden hvor han motvillig måtte inrømme at var slik.

 

Men det betyr jo ikke at det er lurt...

 

-Vegar

Share this post


Link to post

når det er lurt å spre kode er en vurderingssak. det er f.eks ingen vits i å spre kode over flere uniter bare fordi du kan. med erfaring så finner man ut når det passer seg å spre koden.

når applikasjonene man lager blir større så blir det viktigere å spre koden. stikkord er da innkapsling, informasjonsskuling, kobling, kohesjon, kompleksitet, arv, gjennbruk blablabla. da blir også analyse og design viktigere slik at et team kan arbeide uavhengig av hverandre, men om hver sin del av applikasjonen.

 

en grei måte å starte på kan være å ha to uniter, hvor den ene er for brukergrensesnittet og den andre for prosedyrene og data. på denne måten kan en raskt endre brukergrensessnittet uten å påvirke selve programmet

Share this post


Link to post
en grei måte å starte på kan være å ha to uniter, hvor den ene er for brukergrensesnittet og den andre for prosedyrene og data. på denne måten kan en raskt endre brukergrensessnittet uten å påvirke selve programmet

 

Legger man seg til den vanen kommer man til å tjene rått på det når prosjektene vokser. Lag objekter for stort sett alt som er. Minimer bruken av eventer. Trenger du å reagere på et event så bruk det kun til å sparke i gang kode andre steder, ikke implementer hele 'bissnisslaget' i OnClick( )..

 

Det er faktisk mitt støreste ankepunkt mot Delphi. Det er alt for lett å peise på med kode og eventer om hverandre og først etter mange års erfaring begyner man å forstå hvordan man burde ha gjort det den gang man begynte, men da er det ofte vanskelig å gjøre noe med det.... :-(

 

-Vegar

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...