How To Code: Pascal [Slovenian]

0
85

Original in English by Stan Sieler

Kako kodo: Pascal

Allegro Consultants, Inc.

sieler@allegro.com

92/06/08
(spremenjeno 2000-05-03)
(spremenjeno 2009-06-05)
(spremenjeno 2010-06-09)
(spremenjeno 2015-06-12)

0. Uvod

Ta dokument obravnava pisanje kakovostne Pascal kode. Poudarek je na kodirnih vidikih pisanja Pascalove kode.

Primer programa: roman.p.txt, program za pretvorbo rimskih številk v arabske številke.

Primer slabe kode: trim, dejanski resnični del slabe kode.

Kako zaprositi za pomoč pri programiranju: tukaj.

Opomba: ta dokument uporablja Pascal / iX, Pascal na računalniku HP 3000, vendar skoraj vse točke veljajo za vsako različico Pascala, večina pa velja tudi za druge programske jezike.

Želim, da bi razprave v tem dokumentu pokrile štiri programe programiranja: filozofijo, uspešnost, probleme in prenosljivost. Razmišljal sem o tem, da bi rad razdelil ta dokument na štiri poglavja, eno za vsako od P-jev, vendar sem spoznal, da bi se za številne teme, ki bi jih postavil v eno poglavje, lahko postavili enako dobri argumenti, da bi ga postavili v drugo. Torej, namesto da bi imeli eno poglavje na P, sem pripravil ta članek v poglavjih: Slog, Izbira kodiranja, Težave pri izvedbi in Prenosljivost.

V vsakem poglavju se kot načeli, na katerih temeljijo smernice, uporabljajo 4 P. Predlaganih pravil ne bi smeli obravnavati, kot da so 10 (ali% 12 ali $ A) zapovedi. To so moja pravila, tista, ki sem jih uporabil (v različnih oblikah za različne jezike) pri pisanju več kot dveh milijonov vrstic kode. Smernice morajo rasti, tako kot ljudje. Lahko gledam programe, ki sem jih napisal leta 1970, in vidim spremembe v slogu v vmesnih letih. Kljub spremembam je celoten videz ostal enak.

Osnovni namen tega prispevka je spodbuditi bralce k razmišljanju o različnih vidikih sloga in oblikovanju lastnih smernic za kodiranje. To je pomembna podlaga za pisanje kakovostnih programov … v Pascalu ali katerem koli jeziku.

Od leta 1970 sem napisal več kot milijon vrstic jezikovne izvorne kode na visoki ravni. To seveda vključuje nekaj praznih vrstic, vrstic komentarjev in vrstic, ki so klonirane iz drugih datotek. Kljub temu me je to ozadje naučilo, da je “pogled” (ali videz) programa ključnega pomena za razumevanje tega, kar počne koda.


Kazalo

Glavni deli so:


0.1 Odmetna koda

Smernice:

# 1-1. Ni kode, ki bi jo lahko uporabili. Zato vaše smernice veljajo za vse, kar pišete. Še posebej programi “povračila” ali “enkratni posnetki”.

Komentar:

# 1-1. Opazil sem, da skoraj vedno znova uporabljam svoje domnevno vrteče se ali enkratne programe. In, če zmanjšam uporabo svojih smernic, moram vedno plačati za to.

(nazaj na kazalo)


1. Slog

Slog ali njegovo pomanjkanje lahko dramatično vpliva na kakovost programa. Koda kakovosti mora biti napisana tako, da je pravilna, učinkovita in vzdržljiva. Izbira in sledenje določenemu slogu lahko poveča verjetnost, da bo vsak od teh treh ciljev dosežen. Ta razdelek bo najprej razpravljal o spremenljivkah in nato o preostalem delu programa.

(nazaj na kazalo)

1.1 Imena: Osnove

Eden od ključev za uspešen program je pravilna izbira imen.

Uspeh Pascalovega programa je v dobrem razumevanju podatkov, s katerimi program manipulira. To razumevanje se odraža v izbiri podatkovnih struktur in spremenljivk, ki jih uporablja program.

V tem dokumentu se izraz »imena«, kadar se uporablja brez kvalifikatorja, nanaša na imena spremenljivk, konstant, tipov, postopkov in funkcij.

Smernice:

# 1-11. Uporabite samostalnike za spremenljivke, konstante in vrste; uporabite glagolske fraze za postopke in funkcije.

# 1-12. Vrste naj bi običajno imele “_type” na koncu svojega imena.

# 1-13. Imena morajo biti v celoti majhna, podčrta (“_”), ki ločuje besede (npr .: card_count).

Komentar:

# 1-11. Naslednji enovrstični primer bi moral zadostovati za prikaz pomembnosti teh smernic:

if card_count = 52

Je “card_count” cela števka ali funkcija? Razlika je ključnega pomena za razumevanje programa. Edino vodilo, ki ga ima lahko bralec, je njegovo / njeno razumevanje angleščine. (Pravilo kapitalizacije ne bi bilo dovolj!)

Pomembno je vedeti, da bodo drugi ljudje nekoč prebrali kodo. (“Drugi” ljudje vas vključujejo dan po tem, ko ste napisali kodo!) Potrebovali bodo “kazalce”, da bi jim pomagali pravilno razlagati kodo, ki jo berejo.

V skladu s smernico # 1-11 je “card_count” spremenljivka. Če naj bi bila funkcija, bi moralo biti njeno ime nekaj podobnega kot “count_the_cards”.

# 1-12. Nekateri programerji predvajajo “t_”, “typ_” ali “type_”. Drugi dodajo »_t«, »_typ« ali »_type«. Nekaj ​​zgrešenih duš je bilo tako navdušeno nad to idejo, da vsakemu tipu dodajo “t_” in dodajo “tip”.

Prednost dodajanja namesto priprave je, da bodo spremenljivke, povezane z isto stvarjo, razvrščene skupaj, v abecednem seznamu spremenljivk.

Osnovna ideja je jasno razlikovati imena uporabniško določenih tipov od spremenljivk in postopkov (ali funkcij).

# 1-13. Ta smernica odraža dejstvo, da smo angleško govoreči. Če bi bili nemški govorci, bi morali naši programi verjetno uporabiti črke pisave na začetku vsake spremenljivke. Opazite, koliko je težje brati to?

Vidim tri razloge za kapitalizacijo prve črke (ali vseh) nekaterih vrst imen. Noben ni vreden truda:

  • izbrali ste slaba imena za vaše spremenljivke in menite, da bo kapitalizacija nadomestila. … ne bo.
  • niste prepričani, da prevajalnik ve, da je ime spremenljivka, če ni napisana z velikimi črkami v določenem slogu. Presenečenje: prevajalnik je pametnejši od vas!
  • (večinoma za programerje C) želite imeti možnost, da temeljito zamešate bralca z dvema različnima spremenljivkama, ki se razlikujeta le v primeru njihovih imen (npr .: int foo; char FOO).
    … obstaja več častnih poti do varnosti zaposlitve.

Ko pišem v C, naredim velika imena makrov (“#define FAIL (s) …”), ker je to najbolj priljubljen način. Kljub temu pa ni brez obžalovanja. Ko boste sledili tej konvenciji, boste izgubili nekaj prožnosti.

Zdaj, če spremenim preprosto spremenljivko, kot je “lines_cached”, da bo definirana (morda zato, ker zdaj spremljam število predpomnjenih vrstic na podlagi posameznega), ne morem samo reči: #define lines_cached cached_lines_count [clc_simple ] Moram reči #define LINES_CACHED cached_lines_count [clc_simple] * in * narediti globalno spremembo “lines_cached” v “LINES_CACHED”.

V dnevih C-programiranja, ki se nanašajo na nizke vrednosti, sem lahko nekaj spremenila iz preproste spremenljivke v bolj zapleteno, brez opazne spremembe v preostalem delu kode. OTOH, zdaj, ko vidim LINES_CACHED, je opomnik, da je koncept bolj zapleten kot “lines_cached”.

(nazaj na kazalo)

1.2 Imena: Več podrobnosti

Imena za tipe morajo biti opisna in jasno razločljiva kot vrste, tako da izstopajo, kadar se uporabljajo v izrazih prisile ali “velikosti”.

Smernice:

# 1-21. Generične vrste, ki so zapakirane matrike znakov, naj bodo poimenovane “pac” s številom znakov.

type
      pac8        = packed array [1..8] of char;
      pac80       = packed array [1..80] of char;

# 1-22. Vrste, ki so nizi, morajo imeti “ime” v svojem imenu. (Izjema: imena pac ## tipov (glejte # 1-21).)

# 1-23. Vrste, ki so kazalci, morajo imeti v svojem imenu “ptr”. Vrste, ki so dolgi kazalci (64 bitov), ​​morajo imeti v svojem imenu “lptr”. (V Pascalu / iXu so navadni kazalci široki 32 bitov … “dolg” kazalec je 64-bitni kazalec, ki lahko pokaže kjerkoli v spominu.)

# 1-24. Zapisi morajo imeti imena polj s predpono, ki odraža zapis, v katerem so del.

# 1-25. Enostavne vrste običajno ne smejo odražati njihove “velikosti”.

# 1-26. Poskusite se izogniti uporabi »resničnih« in »napačnih« za funkcionalne rezultate. Namesto tega uporabite tip, kot je “good_failed_type”.

Komentar:

# 1-21. Pascalov jezik ima posebna pravila za spremenljivke, ki so zapakirane matrike char z nižjo mejo 1. Ta posebna pravila so bila dodana v poskusu, da bi standard Pascal uporabili za manipulacijo besedila. Posledica tega je, da se večina implementacij Pascala nanaša na “PAC” kot spremenljivko (ali tip), ki je zapakirano polje znakov, z spodnjo mejo 1. Zato je primerno, da se ta standardizacija odraža v naših lastnih vrstah.

Upoštevajte, da so v tej smernici navedeni generični tipi. Ko uporabljam TurboIMAGE (DBMS na HP 3000) in želim ustvariti tip, ki ustreza elementu IMAGE, bom poskusil tipu dati ime, ki je podobno imenu izdelka:

{IMAGE items:     }
         {   cust_name x20;}

   type
      cust_name_type          = packed array [1..20] of char;

V zgornjem primeru sem v deklaraciji tipa uporabil “20” samo zato, ker je bila neposredno očitna vrednost (glede na komentar o elementih IMAGE). Nikoli ne bi uporabil konstante “20” kasneje v programu. Če bi se moral sklicevati na “20”, bi uporabil bodisi Pascal / iX konstrukt “sizeof (cust_name_type)” ali pa bi dodal “const cust_name_len = 20” in uporabil to konstanto za razglasitev zapisa.

# 1-24. Ta smernica omogoča, da se polja zapisa takoj prepoznajo, ko se uporabijo v izjavi »z«. Primer:

bad:

   type
      hpe_status  = record  {name matches MPE/iX's usage}
         info : shortint;
         subsys : shortint;
         end;
      hpe_status_ptr_type = ^ hpe_status;
      ...
   var
      hs_status_ptr : hpe_status_ptr_type;
   ...
   with hs_status_ptr^ do
      begin
      info := my_info;
      subsys := my_subsys;
      end;
good:

   type
      hpe_status              = record       {name matches MPE/iX's usage}
         hs_info              : shortint;
         hs_subsys            : shortint;
         end;

   ...
   with hs_status_ptr^ do
      begin
      hs_info := my_info;
      hs_subsys := my_subsys;
      end;

V slabem primeru bralec, ki ne pozna kode, ne bo vedel, da se polja kazalca spreminjajo. V dobrem primeru je to očitno.

# 1-25. V SPL (programski jezik, podoben ALGOL-u) je precej pogosta uporaba pripone ali predpone za označevanje »tipa« spremenljivke. (Primer: double ktr’d). Z Pascalovimi omejitvami za vrste ujemanja je to precej manj potrebno.

# 1-26. »True« in »false« pomenita malo sami. Primeri:

bad:

   function open_files : boolean;
      ...
      open_files := false;
   ...
   if open_files then
      ...
good:

   type
      good_failed_type        = (failed, good);

   function open_files : good_failed_type;
      ...
      open_files := good;
   ...
   if open_files = failed then

V slabem primeru bralec nima pojma, ali je “open_files”, ki vrne resnično vrednost, dobro ali slabo.

Ta smernica je še pomembnejša pri programiranju v več jezikovnem okolju, saj imajo različni jeziki (in različni operacijski sistemi) čudne ideje, ali “0” (ali “false”) pomeni dobro ali slabo.

V mojem programiranju C uporabljam:

#ifdef GOOD
   #undef GOOD
   #endif

   #ifdef FAILED
   #undef FAILED
   #endif

   #define GOOD 1
   #define FAILED 0

“Undefs” so prisotni, ker je s presenetljivo slabimi odločitvami nekdo, ki je vključen v razvoj BSD ali Mac, odločil, da mora imeti datoteka /usr/include/protocols/talkd.h makro, imenovan FAILED, ki ima vrednost 2. (ali , na HP-UX, ima datoteka /usr/include/sio/scsi_meta.h dobro kot 0 in datoteka /usr/include/sys/netio.h ni uspela kot 3.) (obstajajo drugi slabi primeri DOBRO in NEPRAVILNO. !)

Datoteke, ki jih dobavlja ponudnik operacijskega sistema, NIKOLI ne smejo kooptirati “znanih” besed, kot so pošiljanje, prejemanje, polaganje, napaka ali brezplačno. Takšne besede so preprosto preveč splošne, da bi imele kakršenkoli pomen. Na žalost smo obtičali s številnimi besedami, ki so že v uporabi.

(nazaj na kazalo)

1.3 Razvrščanje vira

Naročanje izvorne kode lahko dramatično vpliva na berljivost programa. Smernice za naročanje spadajo v tri področja: vrste in konstante, spremenljivke ter postopke in funkcije.

(“vključi datoteke” je težje kategorizirati … včasih morajo biti na prvem mestu, včasih morajo biti po vseh vrstah / spremenljivkah.)

Smernice:

# 1-31. Enostavne konstante je treba postaviti na začetek območja deklaracije, ki mu sledijo vrste, strukturirane konstante in nato spremenljivke. V vsaki skupini morajo biti identifikatorji razvrščeni po določenem vrstnem redu. Če ni drugega naročila, se uporabi abecedni vrstni red. Primer:

const
      max_queues              = 10;

   type
      aardvark_quantity_type  = 0..9;
      queue_name_type         = packed array [1..8] of char;
      queue_names_type        = array [1..max_queues] of queue_name_type;
      zoo_fed_arrdvarks_type  = array [aardvark_quantity_type] of integer;

# 1-32. Potreben je le en primer “tipa” in “var”, do dva primerka “konst” (eden za preproste konstante in eden za strukturirane konstante).

# 1-33. Identifikatorji v deklaracijskem območju (konstante, vrste, spremenljivke) naj bodo razvrščeni v eno vrstico v nekem vrstnem redu. Abecedni vrstni red je privzet. Če se uporabi drugo naročilo, ga je treba pojasniti s komentarjem.

# 1-34. Identifikatorje v območju deklaracije je treba vnesti tako, da so znaki “=” poravnani za konstante in vrste, znaki “:” pa so v zapisih poravnani za spremenljivke in polja.

# 1-35. Vrste zapisov, ki vsebujejo ugnezdene zapise, se nikoli ne smejo deklarirati kot “anonimne vrste”. Primeri slabih in dobrih praks so:

bad:

   type payment_record_type = record
         pay_date : date_type;
         pay_time : time_type;
         pay_style : (paid_cash, paid_check, paid_charge);
         end;
good:
   type
      payment_style_type      = (paid_cash, paid_check, paid_charge);

      payment_record_type     = record
         pay_date             : date_type;
         pay_time             : time_type;
         pay_style            : payment_style_type;

# 1-36. Izogibati se je treba “zapiranju” zapisov, razen če potreba po tesnem pakiranju polj ne prevlada nad izgubo zmogljivosti, ki jo povzročajo.

Pascal / iX podpira “zdrobljen zapis”, razširitev preko preprostega “zapakiranega zapisa”. V zdrobljenem zapisu so * ne * neuporabljeni bitovi. Če prijavite zlomljen zapis z 1 bitnim poljem, ki mu sledi 8 bitno polje, ki mu sledi 1 bitno polje, bo celoten zapis zasedel 10 bitov, 8-bitno polje pa bo zahtevalo dodatno kodo za nalaganje / shranjevanje.

# 1-37. Velike zunanje spremenljivke bloka (> 256 bajtov) morajo biti deklarirane zadnje, čeprav to krši smernico # 1-33. (Podobno je treba najprej deklarirati velike lokalne spremenljivke.) (Opomba: to je nasvet za zmogljivost Pascal / iX … drugi prevajalniki na drugih strojih verjetno drugače delajo stvari!)

# 1-38. Postopki in funkcije so prepleteni (t.j. ne ločujte postopkov od funkcij).

# 1-39. Postopke (in funkcije) je treba deklarirati v nekem vrstnem redu (privzeto je abecedno).

# 1-40. Izogniti se je treba več kot eni stopnji ugnezdenega postopka.

# 1-41. Intrinzične znake je treba deklarirati enkrat, na zunanji ravni, za vsemi konstantami, tipi in spremenljivkami in pred vsemi zunanjimi, naprednimi ali dejanskimi postopki. (“Notranji” je sklic na vrsto predhodno pripravljene “zunanje” deklaracije o postopku, ki jo podpira večina jezikov na HP 3000.)

# 1-42. Intrinsics mora biti v abecednem vrstnem redu, urejen z notranjimi datotekami. Primer:

Function ascii    : shortint;  intrinsic;
   Function binary   : shortint;  intrinsic;
   Procedure quit;                intrinsic;

V zgornjem primeru sta bila za besedo “Funkcija” postavljena dva prostora, tako da bi bila imena vseh intrinzičnih lastnosti poravnana, ne glede na to, ali gre za funkcije ali postopke. Žalostno je, da nas je Pascal prevajalniku dokazal, da poznamo funkcionalno vrsto vsakega intrinzičnega.

Zapomnite si velike črke “P” in “F” v zgornjem primeru. To je en primer zelo uporabne discipline kodiranja, ki je pojasnjena v smernici št. 1-45 spodaj.

# 1-43. Vse postopke in funkcije je treba prijaviti z deklaracijami “naprej”, ki so v abecednem vrstnem redu.

# 1-44. Vrste, ki so “polnila”, morajo biti deklarirane kot “celo število” ali “bajt” (kjer je “bajt” deklariran kot 0..255) namesto kot “char” za njihove osnovne vrste.

# 1-45. “naprej”, “zunanji” in “notranji” deklaracija postopka (in funkcija) bi morala z začetno črko izpisati prvo črko “Postopek” in “Funkcija”.

V mojem programiranju C imam svojo eno glavno povezovalno datoteko (“stddefs.h”, ki določa zastavice, primerne za trenutni operacijski sistem (npr. #Define HAVE_STRTOLL 1, če ima platforma funkcijo strtoll), sledi OS / vendor vključuje (npr. stdlib.h, ki mu sledijo moji drugi podatki (npr. “sstypes.h”,), potem vsi moji globalni tipi, enum, spremenljivke, definirajo fragmente kode, deklaracije funkcij ‘naprej’, nato vse moje funkcije. Komentar:

# 1-34. Na splošno poravnam “=” za vrste in consts v stolpcu 31, “:” za polja znotraj vrste tudi v stolpcu 31 in “:” za spremenljivke v stolpcu 19. Če imajo spremenljivke dovolj dolga imena, Pogosto preprosto uskladim “:” v stolpcu 31. To poravnavo uporabim za “:”, ki se uporablja v izjavah parametrov, tako da se ime spremenljivke začne v stolpcu ??:

procedure parse_gribbitz (
                  a_token     : str80;
              var status      : boolean;
           anyvar stuff       : char)
         option default_parms (
                  stuff       := nil);

V zgornjem primeru upoštevajte, da so imena parametrov poravnana. (Očitno to ni vedno mogoče, še posebej, če je parameter podatek o $ usklajevanje $.

# 1-35. Spremenljivke (in polja zapisov), ki so anonimni tipi, se nikoli ne morejo posredovati z referenco (kot “var” parametri) navadnim postopkom. Pravzaprav anonimnih zapisov običajno ni mogoče prenesti po vrednosti v postopke.

# 1-36. Dostop do polj “zdrobljenih” zapisov lahko traja do trikrat toliko, kolikor bi bilo potrebno, če zapis ne bi zdrobljen. Razmislite o naslednjih dveh vrstah:

type
      bad_type                = crunched record
         bad_misc             : shortint;    {Bytes 0, 1}
         bad_status           : integer;     {Bytes 2, 3, 4, 5}
         end;  {Total size: 6 bytes}

      good_type               = record
         good_misc            : shortint;    {Bytes 0, 1}
         good_status          : integer;     {Bytes 4, 5, 6, 7}
         end;  {Total size: 8 bytes}

Ko je dostopno polje “bad_status”, Pascal / iX oddaja tri navodila (LDH, LDH in DEP). Ko je dostopno polje “good_status”, Pascal / iX oddaja eno navodilo (LDW).

# 1-37. Pascal / iX lahko učinkovito dostopa samo do prvih 8,192 bajtov globalnih ali * zadnjih * 8.192 bajtov lokalnih spremenljivk. Pascal / iX dodeljuje spremenljivke na (grobo) prvi viden, prvi dodeljen način. Tako je za globalne spremenljivke bolj pomembno, da najprej postavimo majhne in druge velike. Za lokalne spremenljivke, ki najprej postavijo velike in druge majhne, je bolj učinkovito.

  • Ker Pascal / iX dodeljuje zunanje (“globalne”) spremenljivke v nasprotnem vrstnem redu kot lokalne spremenljivke, velja pravilo:
  • V zunanjem bloku najprej razglasite svoje majhne spremenljivke in svoje velike spremenljivke;
    V postopkih / funkcijah najprej deklarirajte vaše velike spremenljivke in majhne spremenljivke.

Razmislite o naslednjih primerih:

bad:

   var                                 {outer-block variables}
      big_array   : array [0..9999] of integer;  {40,000 bytes}
      ktr : integer;
   ...
   procedure foo;
      var
         ktr2     : integer;
         big_array_2 : array [0..9999] of integer; {40K bytes}
good:

   var                                 {outer-block variables}
            {small variables...}
      ktr         : integer;

            {big variables...}
      big_array   : array [0..9999] of integer;
   ...
   procedure foo;
      var
               {big variables...}
         big_array_2 : array [0..9999] of integer; {40K bytes}

               {small variables...}
         ktr2     : integer;

V slabem primeru bo Pascal / iX za dostop do “ktr” in “ktr2” uporabil dva navodila. V dobrem primeru bo Pascal / iX uporabil en ukaz za dostop do “ktr” in “ktr2”.

# 1-38. Pascalova diferenciacija funkcij in postopkov je v najboljšem primeru žalostna. Ne bi smeli spodbujati oblikovalcev jezikov, da bi ohranili to napako.

# 1-39. Stavek Pascal / iX “$ locality” lahko uporabite za sporočanje povezovalcu, da združi določene postopke skupaj, ne glede na njihov vrstni red v izvorni kodi.

# 1-40. Pascal omogoča prijavo postopkov v postopkih, ki so prijavljeni v postopkih, ki so …

Ugnezdeni postopki plačajo kaznovalno zmogljivost med izvajanjem, ko jim dostopajo do globalnih spremenljivk, ki so lokalne za okoliške postopke.

Postopki, ki so ugnezdeni več kot skupno dve globoki (tj. Postopek “zunanje ravni” in en notranji postopek), navadno pomenijo, da obstajajo drugi problemi oblikovanja.

Nekateri razhroščevalniki imajo težave pri nastavljanju prekinitvenih točk pri gnezdenih postopkih.

# 1-43. To dodatno delo se pogosto dobro izplača pri pisanju “modula”, ki bo povezan z drugimi programi. Pogosto postavljam vse svoje deklaracije za posredovanje v datoteko in nato z naslednjimi ukazi QEDIT ustvarim datoteko “zunanjih” deklaracij za druge module, ki vključujejo $:

t myfile.forward
   c "forward"(S)"external"@
   k myfile.external

(QEDIT je pogosto uporabljen urednik na HP 3000)
# 1-44. Debug / iX’s Format Virtual ukaz (FV) bo ustvaril veliko bolj berljiv izhod za naključne podatke, ko je osnovni tip številski in ne znak. (Debug / iX je razhroščevalnik v paketu z MPE / iX na HP 3000)

# 1-45. S tem navodilom in povezanim v naslednjem razdelku ukaz QEDIT, kot je:

l "procedure" (s)

bo prikazal prvo vrstico vsake deklaracije postopka. Upoštevajte, da bo navedena samo dejanska deklaracija, ne pa deklaracije “naprej” ali “zunanja”, ker bi bile deklarirane z glavnim “P” v “Postopek”.

Opomba: urejevalniku ne povejte, da samodejno prestavlja vse besedilo, ki ga iščete (npr .: nastavite Window (UP) v QEDIT), saj to ne bo vplivalo na namen te smernice.

(nazaj na kazalo)

1.4 Izvršljiva koda

V tem razdelku so opisani slogi kodiranja za izvedljivi del programa Pascal.

Smernice:

# 1-50. Vsa koda mora biti majhna.

# 1-51. Pripombe morajo biti v angleščini in morajo biti v mešani zadevi, kot je v angleščini.

# 1-52. Komentarji naj bodo prikazani v enem od dveh slogov, odvisno od njihove velikosti:

  • poravnano v izbranem stolpcu, desno od kode (tako da oko lahko razlikuje med kodo in komentarji).
  • poravnalo je 6 presledkov desno od trenutnega zamika kode s prazno vrstico nad in spodaj.

Primer:

{the following loop looks for a null character}

   null_index := -1;                   {-1 will mean "not found"}
   test_inx := 0;                      {index of first char}
   done := (len = 0);                  {don't loop if no data}

   while not done do
      begin
            {see if current character is null...}
      if buf [test_inx] = chr (0) then
         begin                         {found a null!}
         null_index := test_inx;       {remember location}
         done := true;                 {terminate loop}
         end

      else
         begin                         {incr inx, check end}
         test_inx := test_inx + 1;
         if test_inx >= len then       {inx is 0-based}
            done := true;
         end;
      end;                             {while not done}

# 1-53. Komentarji z več vrsticami se lahko zapišejo z “{” in “}” na vsako vrstico ali s “{” in “}”, ki se pojavita samo enkrat, na vrsticah, ki jih sami.

# 1-54. Znaki “{” in “}” se uporabljata za zagon in prekinitev komentarjev, nikoli parov “(*” in “*”).

# 1-55. “{” običajno ne sledi presledek, niti “}” navadno ne vsebuje presledka (razen če ga želite poravnati s predhodno vrstico “}”).

# 1-56. Vrstice ne smejo biti daljše od 72 bajtov, čeprav Pascal / iX omogoča daljše vhodne vrstice.

# 1-57. Prazne vrstice v času izvajanja ne stanejo, zato jih je treba uporabiti za ločevanje odsekov kode. Primer:

if ktr > max_ktr then
      max_ktr := ktr;                  {remember new high water}

   done := false;
   while not done do
      begin
      ...

# 1-58. V izjavi »konec« ni treba komentirati. Pascal nikoli ne preveri, ali vaš komentar ustreza resničnosti.

# 1-59. Osnovna enota zamika je 3, ne 4 ali 2.

# 1-60. Zamaknite “3” več kot za začetek prejšnje vrstice. Koda po “start” (do in vključno s “end”) je na isti ravni kot “start”.

# 1-61. Nadaljevalne vrstice so več kot v začetku prve vrstice.

# 1-62. “Nato” stavka “if / then” je običajno na isti liniji kot preostanek booleanskega izraza, ne na naslednji vrstici sam po sebi (razen če je to potrebno za razmik, potem pa je zamaknjeno 6) in nikoli v isti vrstici kot izjava, ki sledi “nato”.

# 1-63. Konstrukcija “else if” se lahko obravnava, kot da je nov Pascalov konstrukt: “elseif”. (Toda: “če” sledi “drugemu” na isti liniji.)

# 1-64. “Goto 999” je sprejemljiva metoda razvejavanja do konca postopka (ali funkcije).

# 1-65. Nobena druga “goto” -a ni potrebna.

# 1-66. Poskusite ohraniti postopke pod petimi stranmi (300 vrstic).

# 1-67. Nikoli ne uporabljajte besede “postopek” ali “funkcija” v komentarju v vseh malih črkah. Namesto tega uporabite “rutinsko” ali “PRocedure” ali “FUnction”.

# 1-68. Vedno zaključite postopek ali funkcijo s komentarjem obrazca:

end {nameofroutine proc};

# 1-69. Med imenom postopka / funkcije in “(” seznama parametrov) postavite prazno polje.

# 1-70. Po vsaki vejici vnesite prazno polje v seznam parametrov.

# 1-71. Postavite presledke okrog operaterjev (npr .: “: =”, “+”, “-“) in pred leve oklepaje (“[“).

Komentar:

# 1-52. Usklajeni komentarji omogočajo, da je koda videti lepša. Ta praksa omogoča bralcu, da zlahka prebere kodo ali komentarje.

# 1-55. Praksa vedno sledenja “{” s presledkom in pred “}” izgublja dragocen prostor na liniji.

# 1-56. Dolge vrstice ne bodo dobro prikazane na večini terminalov, prav tako niso sprejemljive za vse urednike.

# 1-58. Jaz sem dal komentar na “konec” izjavo, ko je več kot približno 10 vrstic iz ustreznega “začeti”.

# 1-60. Vrednost “3” in odredba proti “dvojni vdolbini” prihrani prostor in naredi rezultat bolj berljiv. Razmislite o naslednjih dveh primerih:

bad:

   for i := 1 to 10 do
       begin
           buf [i] := 0;
           foo [i] := 0;
       end;
   if ktr = 0 then
       begin
           if not done then
               begin
                   ...
good:
   for i := 1 to 10 do
      begin
      buf [i] := 0;
      foo [i] := 0;
      end;

   if ktr = 0 then
      begin
      if not done then
         begin
         ...

Mnogi programerji Pascala so videli “dvojno zamik”, ker je profesor, odgovoren za UCSD Pascal (v začetku 70-ih), uporabil ta slog. Upoštevajte, da je bil predvsem učitelj, ne programer.

# 1-61. Primer:

if (card_count = max_card_count) and
      all_cards_accounted_for then
   begin
   ...

Namen zamenjave nadaljevalnih vrstic je, da bralcu pojasnite, da se je prejšnja vrstica nadaljevala v naslednjo vrstico. Če ni uporabljena nobena dodatna zamik, potem je težko določiti razliko med naslednjim stavkom in nadaljevanjem trenutnega stavka.

Ko imam kompleksno “in / ali”, poskušam narediti berljivo, ko delam nadaljevalne vrstice:

bad:

   if ((card_count = prior_card_count) and ((number_of_cards_left
      > cards_for_book)) then
      begin
good:

   if (      (card_count = prior_card_count)
         and (number_of_cards_left > cards_for_book) ) then
      begin

V slabem primeru opazite, kako je “začetek” zamegljen zaradi “in”, ki se začne v istem stolpcu.

# 1-62. Beseda “takrat” je sintaktični sladkor: ta se uvrsti na seznam in nima odkupne vrednosti. Ko bralec vidi “če”, on ali ona samodejno ve, da “potem” prihaja, na koncu. Vdolbina samo bi zadostovala, da bi bralcu povedali, da je bila najdena izjava “potem”. Primeri:

bad:

   if card_count = max_card_count
      then done := true
      else ...
good:

   if card_count = max_card_count then
      done := true
   else
      ...

V zgornjem slabem primeru mora bralec psihično prebrskati presežno besedo (“nato”) pred “storjeno: =”, da bi razumel vpliv “pravega” booleanskega izraza. V dobrem primeru je dovolj branje leve strani seznama.

# 1-63. konstrukcije “else if” se običajno nahajajo v eni od dveh situacij:

  • “v teku” “if / then / else”. Za ta konstrukt je “else if” na isti liniji naravna spodbuda za berljivost.
  • ugnezdeno “if / then / else”. Za ta konstrukt je “drugo” z “if” zamaknjeno na naslednji vrstici naravno.

Primer uvajanja »if / then / else«:

if token_check ('EXIT') then
      wrapup
   else if token_check ('LIST') then
      do_list
   else if token_check ('PRINT') then
      do_print
   else
      writeln ('Unknown command: ', token);

Opomba: v zgornjem slogu bom pred prvim “token_check” pogosto postavil 5 dodatnih presledkov, tako da bo ukaz QEDIT, kot je LIST “token_check”, prikazal vse tri “token_check” fraze, ki so lepo poravnane.

Primer ugnezdenega »if / then / else«:

if card_count = max_card_count then
      if done then
         ...
      else
         discard_current_card
   else
      if current_card = joker then
         try_best_wildcard
      else
         calculate_score;

Slog, ki ga priporočam, je naslednji:

if token_check ('EXIT') then
     wrapup
  else
  if token_check ('LIST') then
     do_list
  else
  ...

Zgornji slog ima drastične posledice za berljivost, če se v seznamu med vrstico “else” in naslednjo vrstico “if” pojavi neobstoječ “izmet strani”.

# 1-64. Pascal nima “izstopne” izjave. Tako C kot SPL imata neko obliko izjave »vrnitev iz tega postopka«. To je edini kraj, kjer uporabljam “goto” v Pascalu.

# 1-67. To vodilo pomeni, da urejevalnik “najde” in “seznam” ukaze, ki iščejo “postopek” in “funkcija”, ne bosta nikoli naključno našla vrstic komentarjev. (Glejte tudi # 1-45).

# 1-68. Zaradi tega je zelo enostavno najti konec vseh (ali vseh) postopkov z ukazom “najti”.

# 1-69 / 70/71. Nepravilne kode naredijo kodo bolj berljivo, prav tako, da naredijo angleščino bolj berljivo. Prazno opombo opazite po vejici v prejšnjem stavku. Primer:

bad:

   fid:=fopen(filename,3,0);
good:

   fid := fopen (filename, 3, 0);

(nazaj na kazalo)


2. Izbira kodiranja

Ta razdelek obravnava izbire, napisane pri pisanju izvršljive kode.

Smernice

# 2-1. Odločite se, ali naj vaš stil vsebuje funkcije, ki vrnejo napake, ali postopke, ki imajo statusne parametre (ali oboje), in se potem držite tega.

# 2-2. Ne uporabljajte »z« za preprosto iskanje po kazalcu. Uporabite “with”, če želite indeksirati v polje.

# 2-3. Poskusite se izogniti “ponovitvi” zank, uporabite zanke “medtem”.

# 2-4. Poskusite se izogniti uporabi “pobeg” izven področja “poskusi / izterja”.

# 2-5. Izogibajte se “nizom” v korist PAC. PAC je pakirano polje Char s spodnjo mejo 1.

# 2-6. Kadar je mogoče, uporabite razširitve Pascal / iX, razen če je prenosljivost glavni cilj.

# 2-7. Konstrukcija “try / recover” v Pascalu / iX-u je zelo uporabna za lovljenje napak: nepričakovana in namerno povzročena. (poskusite / obnovite je mehanizem za ujemanje napak, ki je nekoliko podoben ulovu / metanju v nekaterih drugih jezikih)

# 2-8. Uporabite $ type_coercion ‘predstavitev’ $. Nikoli ne uporabljajte neskladne stopnje prisile.

# 2-9. Tip parametra “anyvar” je koristen. Razmislite o uporabi, ko želite prenašati različne tipe spremenljivk na en postopek.

# 2-10. Možnost “uncheckable_anyvar” za postopek je treba uporabiti vsakič, ko so deklarirani parametri “anyvar”, razen če izrecno želite, da Pascal / iX prenese skriti parameter “dejanske velikosti”.

# 2-11. Ko uporabljate “anyvar”, se prepričajte, da se tip formalnega parametra ujema z omejitvami poravnave pričakovanih dejanskih tipov. Tj .: če je formalni parameter deklariran kot “celo število”, bo Pascal / iX predpostavil, da so vsi naslovi, ki so bili preneseni v ta parameter, večkratni 4. Uporabite “char” (ali drug tip, ki je usklajen z bajti) kot tip formalnega parametra če želite varno prenesti kakršne koli naslove.

# 2-12. Možnost postopka “default_parms” bi bilo treba obravnavati kot sredstvo, s katerim bi bile dolge sezname parametrov krajše (za navadne primere).

Komentar:

# 2-1. Včasih vrnem hiter skupni rezultat z “good_failed_type” in podrobno napako v parametru stanja. Primer:

function open_files (var status : hpe_status) : good_failed_type;
   ...
   if open_files (status) = failed then
      report_status (status);

# 2-2. Pascal ponuja stavek »z«, ki lahko v nekaterih primerih prevajalniku zagotovi namig o tem, kako optimizirati navodila, ki jih oddaja za kodo. Poleg tega lahko izjava »z« shrani nadaljnje vnašanje.

Primer nekoristnega “z” je:

var
      ptr : hpe_status_ptr_type;
   ...
   with ptr^ do
      begin
      hs_info := 0;
      hs_subsys := 0;
      end;

To je “neuporabno”, ker bi prevajalnik in optimizator verjetno naredil enako dobro opravilo za oddajanje optimalne kode, če bi rekli:

ptr^.hs_info := 0;
      ptr^.hs_subsys := 0;

Upoštevajte, da je koda vzela pet vrstic z izjavo “z” in dve vrstici brez nje.
Končno je dejstvo, da so “hs_info” in “hs_subsys” pravzaprav polja zapisa, na katero opozarja “ptr”, ko je uporabljen “s”.

Primer uporabnega »z« je:

var
      statuses : array [0..9] of hpe_status_type;
   ...
   with statuses [k] do       {optimize hs_@ fields}
      begin
      hs_info := 0;
      hs_subsys := 0;
      end;

Menim, da je ta primer “koristen”, ker bi optimizator imel več dela, ko bi poskušal sestaviti optimalno kodo za enakovredne izjave, ki niso z:

statuses [k].hs_info := 0;
   statuses [k].hs_subsys := 0;

V zgornjih primerih je skušnjava poravnati “: =” s desnim najbolj “: =” bloka izstavitvenih stavkov. Včasih sem to počel pogosto, ko sem imel štiri ali več podobnih nalog v vrsti.

Prednost je povečana berljivost, ker je očitno, da so podatki povezani (zaradi poravnanih “: =” s). Pomanjkljivost je, da preprosto ukaza QEDIT, ki je oblikovana za seznam, kjer se spremeni polje “hs_info” (npr .: LIST “hs_info: =”) ne bo uspelo. Ugotovil sem, da je zmožnost iskanja po dodelitvah zame prevladala nad koristmi, ki se nanašajo na podatke.

# 2-3. Ko pride do “zanke ponovitve”, čitalnik ne bo vedel, kakšen je pogoj za prekinitev, dokler ne preberejo veliko več vrstic programskega vira. To pomeni, da ne bo mogel preveriti pravilne nastavitve pogojev za prekinitev. Časovna zanka se izogiba temu problemu, ker je pogoj za zaključek jasno določen na vrhu zanke.

Ponavljalno zanko lahko običajno preprosto spremenite v časovno zanko:

before:

   repeat
      begin
      ...
      end
   until
      buf [inx] = 0;
after:

   done := false;
   while not done do
      begin
      ...
      done := (buf [inx] = 0);
      end;          {while not done}

# 2-4. “Ne-lokalni pobeg” stane na tisoče ciklov CPU časa za izvedbo. Na kratko, nikoli ne načrtujte uporabe tega konstrukta kot običajnega načina vračanja iz postopka. Primeri:

bad:

   procedure do_work;         {note:  no status parameter!}
      ...
      if problem then
         escape (i_failed);
      ...
good:

   procedure do_work (var status : hpe_status_type);
      label
         999;
      ...
      if problem then
         begin
         status := my_failure_status;
         goto 999;            {exit}
         end;
      ...
   999:

      end {do_work proc};

# 2-5. Nizi skrivajo ogromno količine počasne in nekoliko napačne kode, ki jo generira prevajalnik. Vezanje nizov, zlasti, lahko povzroči “puščanje pomnilnika”, kjer vaš proces zmanjka prostora kopice. PAC so bolj nerodni, vendar so veliko bolj učinkoviti. To je zmogljivost v primerjavi z estetiko.

# 2-6. Pascal / iX je zelo uporaben jezik prav zato, ker ima veliko razširitev standardnega Pascala. Če jih ne uporabljate, bi bilo bolje, da programirate v ANSI C ali C ++.

# 2-7. “Poskusi / obnoviti” ni zagotovljeno, da bi ujel kakršne koli napake, ki se pojavijo v njem. Nepričakovane napake (npr .: neveljaven indeks, slab virtualni naslov) pokličejo rutino operacijskega sistema, imenovano trap_handler, ki bo “hodila” nazaj skozi označevalnike skladov in iskala najnovejši blok “poskusi / obnovi”. Ta “sprehod” lahko ne uspe, če je vaš sklad poškodovan in “poskusi / obnovite” ne bo mogoče najti. Če se to zgodi, in če ustrezni upravljalnik pasti (npr .: XCODETRAP) ni bil vklopljen, bo vaš postopek prekinjen.

# 2-8. Prisilna prisotnost je ena najboljših razširitev v Pascal / iX. Zagotavlja nadzorovan način preglasitve Pascalovega preverjanja tipov. Direktiva $ type_coercion pove Pascalu / iXu, kakšno stopnjo prisile želite dovoliti v vašem programu. Obstaja približno pet različnih ravni. Stopnja, ki jo močno priporočam, je zastopanje. Ta raven omogoča, da se izraz enega tipa prisili (obravnava kot) drug tip, če in samo če sta ti dve vrsti popolnoma enake velikosti (v enotah bitov, ne v bajtih).

Neskladna raven pove Pascal / iX, da ne sme biti omejitev glede tipa prisile. To vodi do zanimivih napak v programih. Nekatere zrušitve sistema MPE / iX se lahko izsledijo z nepravilno uporabo te vrste prisile. Naslednji primeri prikazujejo, kako lahko nezdružljivo skrije napake.

assuming:

   var
      big_ptr     : globalanyptr;
      my_address  : integer;
      small_ptr   : localanyptr;
bad:

   $type_coercion 'noncompatible'$
   my_address := integer (big_ptr);   {will get half of data!}
   my_address := integer (small_ptr); {will get 32 bit value}
good:

   $type_coercion 'representation'$
   my_address := integer (big_ptr);   {will get syntax error}
   my_address := integer (small_ptr); {will get 32 bit value}

V slabem primeru je prisila big_ptr povzročila nastavitev my_address na zgornjih 32 bitov big_ptr (tj. Id prostora), ki tiho izgubi 32 bitov naslova. V dobrem primeru bo Pascal / iX ustvaril sintaktično napako pri poskusu, da bi 64-bitni izraz (big_ptr) prisilil v 32-bitno vrednost (celo število).

# 2-9. “anyvar” je Pascal / iX razširitev “var”. Če je formalni parameter deklariran kot “anyvar”, prevajalnik omogoča, da se vsaka spremenljivka posreduje kot dejanski parameter. Brez take funkcije in brez objektno orientiranega Pascala ne morete napisati nobenega postopka, ki bi ničelno (izbrisal) poljubno spremenljivko (glej na primer spodaj).

Po privzetku, ko je parameter deklariran kot anyvar, bo Pascal / iX v naslovu dejanskega parametra * in * skrito celo število-za-vrednost, ki beleži velikost dejanskega parametra. Naslednji primer prikazuje, kaj je podano za formalni parameter, kot so: “anyvar foo: integer” in vpliv na “sizeof (foo)” v postopku:

Dejanski parameter tipa Skrito polje velikosti sizeof (foo)
char 1 1
shortint 2 2
integer 4 4
longint 8 8
real 4 4
longreal 8 8
hpe_status (see #1-24) 4 4
packed array [1..80] of char 80 80

# 2-10. Pogosto uporabljam “anyvar”. En primer je:

procedure zero_var (anyvar foo : char);
         {Purpose: zero every byte in the parameter}
      var
         bytes_left           : integer;
         byte_ptr             : ^char;

      begin

   $push, range off$
      byte_ptr := addr (foo);
      bytes_left := sizeof (foo);  {Note: gets actual size!}

      while bytes_left > 0 do
         begin                     {zero one byte}
         byte_ptr^ := chr (0);
         bytes_left := bytes_left - 1;
         byte_ptr := addtopointer (byte_ptr, 1);
         end;
   $pop$          {range}

      end {zero_var proc};

Zapomnite si komentar na $ pop $ … kar mi omogoča, da se spomnim, katere možnosti je $ pop $ domnevno obnovil.

V programu Pascal / iX $ push $ shrani stanje večine možnosti prevajalnika in $ pop $ jih obnovi. Torej, $ push, range off $ … $ pop $ začasno izklopi možnost “range”, nato pa jo ponovno vzpostavi v staro stanje … kar je bistveno drugače kot preprosto vklop, ko je “končano”!

Seveda Pascal / iX omogoča še hitrejši način ničelne nastavitve spremenljivke, ki se dobro obnese s preverljivimi anyvar parametri. Celotno kodo zgornjega postopka (med “start” in “end”) se lahko nadomesti z:

fast_fill (addr (foo), 0, sizeof (foo));

# 2-12. Naslednji primer, postopek, ki bi ga večina uporabnikov klicala z “false” v drugem parametru, kaže uporabnost “default_parms”:

const
      print_with_cr      = 0;
      print_without_cr   = 1;

   procedure print_msg (
                  msg                  : str80;
                  cr_or_no_cr          : integer)
         option default_parms (
                  cr_or_no_cr          := print_with_cr);

      var
         cctl_val   : shortint;

      begin

      if cr_or_no_cr = print_without_cr then
         cctl_val := octal ('320')
      else
         cctl_val := 0;

      print (msg, -strlen (msg), cctl_val);
            {Note: ignoring errors from print intrinsic}

      end {print_msg};
   ...
   print_msg ('Starting...', print_without_cr);
   print_msg ('Ending');               {does a CR/LF at end}

Upoštevajte, da ne bom uporabil “default_parm” za parameter, ki je izpuščen manj kot 75% časa.

(nazaj na kazalo)


3. Težave z uspešnostjo

Dve največji težavi v programih Pascal / iX uporabljata vgrajene I / O in uporabo nizov.

Smernice:

# 3-1. Izogibajte se Pascal I / O. Namesto tega uporabite intrinzične lastnosti.

# 3-2. Izogibajte se Pascal I / O. Namesto tega uporabite intrinzične lastnosti. To je vredno dvakrat!

# 3-3. Izogibajte se nizom v kritičnih področjih delovanja.

# 3-4. Izklopite preverjanje obsega ($ range off $) samo, če ste prepričani, da se program pravilno izvaja.

# 3-5. Uporabite optimizator Pascal / iX ($ optimize na $).

Komentar:

# 3-1. Če zaprete vhodno / izhodne klice, jih lahko preprosto spremenite, tako da uporabite MPE intrinsics. To pomaga tudi pri prenosljivosti med operacijskimi sistemi in med jeziki. Primer “print_msg” v komentarju št. 2-12 je primer.

Drugi razlog za izogibanje Pascal I / O konstruktom je učinkovitost. Pascal / iX I / O rutine so izjemno neučinkovite. Ta smernica velja za večino jezikov.

# 3-3. Izrazni nizi povzročijo, da prevajalnik oddaja veliko klicev v podporne rutine. Namesto dodeljevanja posameznega delovnega področja v sklad, te rutine dodeljujejo (in razrešujejo) veliko delovnih področij na vašo kopico. To je lahko draga dejavnost in lahko vodi do izgube prostora za kopice in morebitne prekinitve procesa.

# 3-5. Če je vaš program pravilno unoptimized in ima problem optimiziran, potem so verjetno ena (ali več) neinicializirane spremenljivke. Druga najpogostejša težava je uporaba kazalcev na način, ki ga optimizator ne pričakuje (zlasti pri dostopu do lokalnih spremenljivk preko kazalcev).

(nazaj na kazalo)


4. Prenosljivost

Prenosljivost programov, napisanih v jeziku Pascal / iX, je mogoče izboljšati z več tehnikami. Ne pozabite, da večina drugih implementacij Pascala ni tako bogata kot Pascal / iX. Delphi in Turbo Pascal (na IBM PC združljivih) nudita nekatere iste funkcije kot Pascal / iX.

# 4-1. Izogibajte se tem Pascal / iX končnicam: extensible, readonly, anyvar, option, uncheckable_anyvar, default_parms, globalanyptr.

# 4-2. Izogibajte se najbolj direktivam $ (npr .: $ extnaddr $).

# 4-3. Uporabite tip prisile samo za enake velikosti. (Dober nasvet, tudi če nikoli ne nameravate vnesti svoje kode!) Večina Pascalov na osebnem računalniku ima obliko prisile. Lahko se nanašajo na “ulivanje tipa”.

# 4-4. Izogibajte se “zdrobljenim” zapisom. Celo večina jezikov C nima funkcionalnega ekvivalenta. To vključuje izogibanje “$ HP3000_16 $”.

4-5. Kadar je mogoče, vključite “čudne” konstrukte.

# 4-6. Zaprite I / O klice. To ni vprašanje prenašanja jezikov, temveč vprašanje operacijskega sistema in / ali uspešnosti.

# 4-7. Vrstice izvorne kode naj bodo kratke (72 znakov ali manj na vrstico).

# 4-8. Uporabite uporabniško definirane tipe, kot so “int16” in “int32”, namesto “shortint” ali “integer”. Opomba: to je izjemno pomembno za programerje C!

# 4-9. Zavedajte se, da so polja v zapisih lahko različno pakirana na različnih strojih.

# 4-10. Standardni Pascal ne omogoča, da kazalci kažejo na spremenljivke. (Lahko samo kažejo na kup.)

(nazaj na kazalo)


5. Povzetek

Najkrajši povzetek tega članka je verjetno: knjigo lahko presodite po naslovnici. Če program izgleda lepo, je verjetno lepo.

(nazaj na kazalo)

 

LEAVE A REPLY

Please enter your comment!
Please enter your name here