Difference between revisions of "Basic Pascal Tutorial/Chapter 1/Program Structure/it"

From Lazarus wiki
Jump to navigationJump to search
(Created page with "{{Program Structure}} {{TYNavigator|Hello, World|Identifiers}} Fondamenti 1A - Struttura del programma (author: Tao Yue, state: changed) La struttura fondamentale di un prog...")
 
Line 36: Line 36:
 
produrrà un errore poiché il compilatore assocerà  il primo '<tt>(*</tt>' con il primo '<tt>*)</tt>', ignorando il secondo '<tt>(*</tt>' che si trova all'interno del primo insieme di marcatori di commento. Il secondo '<tt>*)</tt>' resterà privo del corrispondente '<tt>(*</tt>'. Questo problema con l'inizio e la fine dei marcatori di commento è una delle ragioni per cui molti linguaggi utilizzano sistemi di commento "line-based."
 
produrrà un errore poiché il compilatore assocerà  il primo '<tt>(*</tt>' con il primo '<tt>*)</tt>', ignorando il secondo '<tt>(*</tt>' che si trova all'interno del primo insieme di marcatori di commento. Il secondo '<tt>*)</tt>' resterà privo del corrispondente '<tt>(*</tt>'. Questo problema con l'inizio e la fine dei marcatori di commento è una delle ragioni per cui molti linguaggi utilizzano sistemi di commento "line-based."
  
Free Pascal also supports // as a line-based comment. When two slashes appear, other than in a quoted string or a free-form comment, the rest of the line is ignored.
+
Free Pascal offre anche supporto per i commenti su linea singola //. Quando compaiono due segni di "slash", il resto della linea è ignorato, tranne nel caso di una stringa tra apici o all'interno di un commento del tipo "free-form."
  
Turbo Pascal and most other modern compilers support free-form brace comments, such as <tt>{Comment}</tt>. The opening brace signifies the beginning of a block of comments, and the ending brace signifies the end of a block of comments. Brace comments are also used for compiler directives.
+
Turbo Pascal e la maggior parte degli altri compilatori moderni supporta commenti "free-form" tra parentesi graffe, come <tt>{Comment}</tt>.
 +
La parentesi graffa aperta indica l'inizio di un blocco di commenti, mentre quella chiusa ne indica la fine. Questo tipo di commenti è utilizzato anche per le direttive del compilatore.
  
Commenting makes your code easier to understand. If you write your code without comments, you may come back to it weeks, months, or years later without a guide to why you coded the program that way. In particular, you may want to document the major design of your program and insert comments in your code when you deviate from that design for a good reason.
+
I commenti rendono il codice più semplice da comprendere. Scrivendo codice senza inserire commenti, si rischia di tornare ad esaminarlo settimane, mesi o anche anni dopo, privi di una guida che spieghi perché si sia scritto il programma in quel modo. In particolare, sarà utile documentare il design generale del programma, ed inserire commenti nel codice quando ci si discosta da quel design per una buona ragione.
 +
 
 +
Inoltre, i commenti sono spesso impiegati per rendere temporaneamente "inattive" porzioni problematiche di codice, senza doverle cancellare. Ricordate la precedente restrizione riguardo l'annidamento di codice? Accade che le parentesi graffe <tt>{}</tt> abbiano precedenza ripetto alla notazione parentesi-star <tt>(* *)</tt>. Non verrà riscontrato alcun errore in un caso come questo:
  
In addition, comments are often used to take problematic code out of action without deleting it. Remember the earlier restriction on nesting comments? It just so happens that braces <tt>{}</tt> take precedence over parentheses-stars <tt>(* *)</tt>. You will not get an error if you do this:
 
 
<syntaxhighlight>
 
<syntaxhighlight>
 
{ (* Comment *) }
 
{ (* Comment *) }
 
</syntaxhighlight>
 
</syntaxhighlight>
  
Whitespace (spaces, tabs, and end-of-lines) are ignored by the Pascal compiler unless they are inside a literal string. However, to make your program readable by human beings, you should indent your statements and put separate statements on separate lines. Indentation is often an expression of individuality by programmers, but collaborative projects usually select one common style to allow everyone to work from the same page.
+
Gli spazi bianchi (spazi, tabulazioni, e termine delle linee) sono ignorati dal compilatore Pascal, tranne nel caso in cui siano all'interno di un letterale stringa. In ogni caso, per rendere i vostri programmi leggibili dagli esseri umani, dovreste indentare i vostri enunciati e disporre enunciati diversi su linee distinte. L'indentazione rappresenta spesso un'espressione di individualità da parte dei programmatori, ma per progetti collettivi viene solitamente selezionato uno stile comune per permettere ad ognuno di lavorare in modo consistente.
  
 
{{TYNavigator|Hello, World|Identifiers}}
 
{{TYNavigator|Hello, World|Identifiers}}

Revision as of 12:24, 13 July 2016

български (bg) Deutsch (de) English (en) español (es) français (fr) italiano (it) 日本語 (ja) 한국어 (ko) русский (ru) 中文(中国大陆)‎ (zh_CN)

 ◄   ▲   ► 

Fondamenti 1A - Struttura del programma (author: Tao Yue, state: changed)

La struttura fondamentale di un programma Pascal è:

PROGRAM ProgramName (FileList);

CONST
  (* Constant declarations *)

TYPE
  (* Type declarations *)

VAR
  (* Variable declarations *)

(* Subprogram definitions *)

BEGIN
  (* Executable statements *)
END.

L'enunciato PROGRAM è opzionale in Free Pascal.

Gli elementi di un programma devono essere nell'ordine corretto, sebbene alcuni possano essere omessi se non necessari. Ecco un programma che non fa alcunché, ma include tutti gli elementi necessari:

program DoNothing;
begin
end.

I commenti sono porzioni di codice che non viene compilato né eseguito. Free Pascal supporta due tipi di commenti, "free-form" e "line-based". I commenti "free-form" possono cominciare con (* e terminare con *), oppure, più comunemente, iniziare con { e terminare con }. Non è possibile annidare commenti:

        (* (* *) *)

produrrà un errore poiché il compilatore assocerà il primo '(*' con il primo '*)', ignorando il secondo '(*' che si trova all'interno del primo insieme di marcatori di commento. Il secondo '*)' resterà privo del corrispondente '(*'. Questo problema con l'inizio e la fine dei marcatori di commento è una delle ragioni per cui molti linguaggi utilizzano sistemi di commento "line-based."

Free Pascal offre anche supporto per i commenti su linea singola //. Quando compaiono due segni di "slash", il resto della linea è ignorato, tranne nel caso di una stringa tra apici o all'interno di un commento del tipo "free-form."

Turbo Pascal e la maggior parte degli altri compilatori moderni supporta commenti "free-form" tra parentesi graffe, come {Comment}. La parentesi graffa aperta indica l'inizio di un blocco di commenti, mentre quella chiusa ne indica la fine. Questo tipo di commenti è utilizzato anche per le direttive del compilatore.

I commenti rendono il codice più semplice da comprendere. Scrivendo codice senza inserire commenti, si rischia di tornare ad esaminarlo settimane, mesi o anche anni dopo, privi di una guida che spieghi perché si sia scritto il programma in quel modo. In particolare, sarà utile documentare il design generale del programma, ed inserire commenti nel codice quando ci si discosta da quel design per una buona ragione.

Inoltre, i commenti sono spesso impiegati per rendere temporaneamente "inattive" porzioni problematiche di codice, senza doverle cancellare. Ricordate la precedente restrizione riguardo l'annidamento di codice? Accade che le parentesi graffe {} abbiano precedenza ripetto alla notazione parentesi-star (* *). Non verrà riscontrato alcun errore in un caso come questo:

{ (* Comment *) }

Gli spazi bianchi (spazi, tabulazioni, e termine delle linee) sono ignorati dal compilatore Pascal, tranne nel caso in cui siano all'interno di un letterale stringa. In ogni caso, per rendere i vostri programmi leggibili dagli esseri umani, dovreste indentare i vostri enunciati e disporre enunciati diversi su linee distinte. L'indentazione rappresenta spesso un'espressione di individualità da parte dei programmatori, ma per progetti collettivi viene solitamente selezionato uno stile comune per permettere ad ognuno di lavorare in modo consistente.

 ◄   ▲   ►