Spre koden over flere sider

[qdos]

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å?

[kilogram]

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å.

[qdos]

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?

[Legion]

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;

[qdos]

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

[Legion]

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

[qdos]

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...

[CarlChr]

Se uses i help fila.....

 

uses betyr vel omtrent det samme som include i C...

[kilogram]

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).

[Format71]

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

[Legion]

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

[Format71]

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

[michaenh]

Helt enig med deg der Format71.. det er sant det. Men iblant så glemmer man bort å bare legge til alt koden på eventer.

[Legion]

populært kallt spaghettikode

et mareritt å gjøre endringer