Lezione 11

I lucidi sono sempre quelli dello scorso anno. Siamo arrivati al lucido 26 incluso.

La prossima lezione sarà il 13 gennaio 2012. Buone feste a tutti.

S.

Comunicazioni di servizio

Mercoledì 21 dicembre non ci sarà il docente per la lezione di laboratorio. Potete trovarmi comunque a fare esercizi, oppure potete anticipare le feste.
A tutti voi tanti auguri!

Comunicazioni di servizio

Come preannunciato nelle scorse lezioni:

1) Domani 9 dicembre non c'è lezione.

2) Il 16 dicembre, chi di voi ha un portatile con connessione WiFi lo porti a lezione. Faremo un esperimento di valutazione della lezione in tempo reale: vi collegherete a un sito Web (forniremo noi la connettività necessaria) e lo userete, durante la lezione, per votarne alcuni aspetti (comprensibilità, velocità, ecc.). Vi daremo ulteriori dettagli.

3) Dopo il 16 dicembre ci rivedremo il 13 gennaio 2012 per l'ultima lezione e il 20 gennaio 2012 per un test. Durante il test vi verranno proposti alcuni esercizi sull'iterazione, il test durerà due ore. Se il risultato sarà positivo, ne terremo conto nel voto finale; se sarà negativo non ne terremo conto. È comunque un'ottima occasione per fare un po' di esercizi in vista della provetta di febbraio. Seguiranno ulteriori dettagli.

S.

Lezione 10

Abbiamo finito la lezione precedente e anche la 10. I lucidi sono sempre quelli dello scorso anno.

Lezione 9

Abbiamo finito i lucidi della lezione 8 e siamo arrivati al metodo per i numeri primi (escluso) su quelli della nona lezione (i lucidi sono simili a quelli dello scorso anno).

Lezione 8

Seconda lezione sugli array. I lucidi sono sempre quelli degli scorsi anni. Siamo arrivati al lucido 34.

Lezione 7

Finita la programmazione strutturata e cominciati gli array. I lucidi sono sempre quelli degli scorsi anni. E anche l'invito:

Vi rinnovo l'invito a scrivere nei commenti che cosa non avete capito, se c'è qualcosa. Lo so che sono un docente bravissimo ma ogni tanto ci sarà qualcosa che spiego male, no? :)

Lezione 6

I lucidi sono sempre quelli degli anni scorsi.

Lezione 5

I lucidi sono sempre quelli degli anni scorsi.

Domanda

Quesito posto da uno studente:
"Buongiorno, saprebbe consigliarmi un buon compilatore Java sotto Windows?"


Chi di voi studenti vuole provare a rispondere?


Luca

Accesso Moodle

Per tutti gli studenti che hanno avuto problemi nell'accesso a Moodle.
Al momento del cambio password, se non riuscite a visualizzare il pulsante per l'aggiornamento, eliminate lo stile e visualizzate la pagina senza alcuno stile (in Firefox: menu visualizza -> stile pagina -> nessuno stile). Il bottone comparirà magicamente e potrete concludere l'aggiornamento.

Luca

Lezione 4

Abbiamo finito i lucidi della 3a lezione e fatto quelli della 4a. I lucidi della 4a lezione sono sempre uguali a quelli degli anni scorsi.

Piattaforma esercitazioni

Di seguito i dati per accedere alla piattaforma con gli esercizi da svolgere e valutare.

Link: http://smdc.uniud.it/moodle2/
Username: <nome>.<cognome>
Password: <cognome>

Dove <nome> è il vostro nome e <cognome> è il vostro cognome, tutto in minuscolo. Al primo accesso ovviamente modificate la password.

Ora potete iniziare a risolvere seriamente gli esercizi. Leggete le consegne, risolvete l'esercizio e caricate la soluzione. Ricordate: con un esercizio al giorno arrivate a fine anno avendo svolto tutto.

Luca

Lezione 3

I lucidi sono sempre gli stessi degli anni scorsi. Siamo arrivati al lucido 12 incluso.

P.S.1. Mercoledì prossimo c'è lezione di lab. Mi raccomando...
P.S.2. Per l'installazione di Java, gli anni scorsi sono stati messi link e documenti sul blog. E anche Google aiuta. Come dicevo a lezione, installare = scaricare, scompattare, copiare, e altro. Leggere le istruzioni!!

Prima lezione di laboratorio

Ieri si è tenuta la prima lezione di laboratorio, che ha visto partecipare ben 5 studenti.
In generale, se avete problemi discutiamone insieme e cerchiamo di spostare le ore di laboratorio. Se voi non mi dite nulla, io faccio lezione. Ricordate che avete poco meno di 80 ore di laboratorio, ma solo la metà vedrà presenti i docenti: le nostre ore sono centellinate per cui evitate di sprecarle, altrimenti peggio per voi.
In generale la lezione con docente è il mercoledì, mentre giovedì la lezione prevede esercitazioni autonome.
Mercoledì prossimo darò tutte le indicazioni relative al laboratorio, per cui voglio vedervi TUTTI.
Le attività, come spiegherò, si potranno svolgere ovunque, per cui, soprattutto per chi lavora, non è necessaria la presenza fisica in laboratorio. Ovviamente è l'unico momento in cui avete a disposizione i docenti, per cui approfittatene.
Quest'anno, salvo casi particolari che valuterò di volta in volta, non risponderò a mail con richieste di soluzioni di esercizi: se avete problemi venite in laboratorio e ne parliamo a voce.

Gli esercizi saranno molti, il corso richiede impegno e il mondo è difficile: rimboccatevi le maniche e che la forza sia con voi.

Luca

Lezione 2

Oggi c'è stata la seconda lezione. Abbiamo finito i lucidi della scorsa volta e siamo arrivati al lucido 23 della seconda lezione. I lucidi sono gli stessi dello scorso anno.

S.

Lezione 1

Venerdì 30 settembre 2011 è incominciato il corso per l'A.A. 2011/12. Quest'anno le lezioni si terranno su due semestri.

Ecco qui i lucidi della prima lezione:



Siamo arrivati al lucido 22.

Per farsi una risata

Vezi mai multe din Funny pe 220.ro

Risultati dello scritto del 18/2

I risultati del compito scritto del 24/1 18/2 verranno comunicati domani mattina all'orale.

(Update: ho corretto la data...)
S.

Compito scritto del 24/1/2011

Qui.

S.

Compito scritto del 18/2/2011

Qui.
S.

Progetto per l'appello del 18,24/2/2011

Premessa

Leggete *bene* *tutte* le istruzioni! In particolare i paragrafi modalità e raccomandazioni.

 

Introduzione

Un adventure è un gioco a tappe in cui bisogna scegliere le opzioni giuste ad ogni tappa per riuscire a trovare il percorso vincente. Tipicamente le tappe vengono mostrate una alla volta, in formato testo o grafico.

 

Descrizione del lavoro

Si richiede di implementare un programma che, tramite un'interfaccia grafica, consenta all'utente di "giocare" un semplice adventure, descritto in un file di testo formattato opportunamente. Il programma deve:

1. Consentire la scelta del nome del file di testo da cui leggere le varie tappe da linea di comando (parametro del main).
2. Gestire opportunamente il caso in cui il file specificato dall'utente non esista (visualizzando un messaggio opportuno).
3. Avere un'interfaccia utente grafica per gestire la comunicazione con l'utente.
4. Visualizzare il contenuto della tappa corrente in un'area di testo.
5. Consentire all'utente di scegliere la tappa successiva tramite un insieme opportuno di pulsanti. Deve esserci un pulsante per ogni opzione possibile (ossia per ogni tappa immediatamente raggiungibile dalla tappa corrente) e ogni pulsante deve avere come etichetta il numero della tappa successiva corrispondente. La GUI è quindi dinamica e cambia a seconda della tappa in cui ci si trova.
6. Mettere a disposizione dell'utente un'area di testo in cui "segnarsi" alcune scelte effettuate per mezzo di caratteri.

Un esempio di interfaccia del programma è riportato nella figura seguente. L'area di testo non editabile in alto a sinistra mostra il testo della tappa corrente. L'area di testo sulla destra serve all'utente per "segnarsi" le scelte effettuate. Il pannello in basso contiene tanti pulsanti (2) quante sono le tappe successive possibili (la 11 e la 10).

Ovviamente, questa è solo una delle molte possibili implementazioni, che viene fornita solo per esempio, e che quindi siete liberissimi di modificare.
Il formato del file contenente le tappe è il seguente:

• Una prima riga contenente un numero intero uguale al numero di tappe totali.
• Per ogni tappa:
  • Una prima riga contenente il numero identificativo della tappa (1 per la prima, 2 per la seconda, ecc.)
  • Una seconda riga contenente un numero intero (chiamiamolo N) che indica quante delle righe successive contengono il testo da visualizzare per quella tappa.
  • N righe contenenti il testo da visualizzare per quella tappa.
  • Una riga contenente un numero intero (chiamiamolo M) che indica quante opzioni sono possibili per quella tappa.
  • M righe contenenti ognuna un intero che indica la tappa successiva a seconda dell'opzione scelta.

Nel file le tappe sono ordinate (il file comincia con la prima tappa, poi c'è la seconda, ecc.). Il programma deve funzionare con qualsiasi file che rispetti le convenzioni suddette. A titolo di esempio, vi forniamo un "adventure" per larealizzazione del progetto di programmazione. Notate la tappa numero 9, corrispondente alla figura precedente:

9
3
Ormai non c'e' piu' tempo per trovare qualcun altro che non sia gia' in un gruppo.
Se decidi di fare da solo, segna 1 e vai al 11.
Se decidi di cercare qualche altro gruppo a cui manca un componente e aggregarti a loro, vai al 10.
2
11
10

Siete ovviamente liberi di divertirvi e sperimentare altri file...

 

Suggerimenti

• Rappresentate in un'opportuna struttura dati in memoria tutte le tappe (quindi leggerete il file un'unica volta all'inizio dell'esecuzione del programma...).
• Potreste aver bisogno di una classe Tappa, definita da voi, per rappresentare una singola tappa...
• Vi servirà il metodo Integer.parseInt(String) per convertire una stringa in un intero (ad esempio, la stringa "5" nell'int 5)
• I pulsanti in basso andranno cancellati e ricreati ad ogni tappa. Per farlo, vi possono essere utili i metodi:
  • public void remove(Component comp) di java.awt.Container (ereditato da Frame...);
  • public void validate() di java.awt.Container (ereditato da Frame...); e
  • public void repaint(long tm) di java.awt.Component (ereditato da Frame...).
  Guardate la documentazione delle API corrispondente.

 

Modalità

Il livello di complessità del programma prodotto può essere deciso liberamente dagli studenti; ovviamente, progetti più articolati e complessi otterranno una valutazione migliore di progetti più semplici, ma si consiglia di fare "poco e bene" piuttosto che "tanto e male": progetti semplici possono comunque ottenere il massimo punteggio, purché ben fatti. La durata prevista del lavoro, considerando un gruppo di 3 persone che lavorano a tempo pieno, è di una settimana al massimo.
Il progetto va realizzato in gruppi di 3 persone (a meno di accordi particolari con il docente, possibili solo in casi di reale e comprovata necessità), e tutti i componenti di un gruppo devono conoscere tutti i dettagli del progetto, come se l'avessero realizzato da soli.
Va preparata una breve relazione, preferibilmente (ma non necessariamente) in XHTML + CSS, sul lavoro effettuato. La relazione deve contenere:

1. Una breve analisi del problema ed una descrizione intuitiva della vostra soluzione (meno di 2 pagine!).
2. Le eventuali semplificazioni apportate rispetto alla versione completa richiesta (poche righe). Le semplificazioni vanno adeguatamente motivate. Ovviamente, le semplificazioni porteranno a valutazioni inferiori, e in alcuni casi (quando le semplificazioni sono eccessive) a progetti insufficienti.
3. Eventuali aggiunte (cose in più non richieste; ad esempio uso di componenti dell'AWT non spiegati a lezione, uso delle Swing, aggiunta di funzionalità non richieste, aggiunta di menu, ecc. ecc.). Prima di aggiungere qualsiasi cosa, pensate a fare bene quello che è richiesto.
4. Le motivazioni di tutte le scelte effettuate (ad esempio, perché avete apportato una semplificazione, perché avete deciso di usare certi componenti grafici e non altri, perché avete fatto certe scelte di progetto piuttosto che altre, e così via).
5. Il listato completo del programma, con commenti (in javadoc, ma non solo), scritto in font non proporzionale (come questo: la "i" e la "m" occupano la stessa larghezza) e opportunamente incolonnato ("indentato").
6. Una "prova di esecuzione" (di circa 3 pagine) che illustri il funzionamento del programma: una spiegazione con testo e figure del modo in cui il programma funziona (aspetto dell'interfaccia utente, esempio di esecuzione adeguatamente spiegato, ecc.)

Di solito il progetto va consegnato inderogabilmente entro l'inizio della prova scritta dell'appello, ma anche per questo appello facciamo un'eccezione: la scadenza per la consegna è il martedì 22 febbraio 2011 ore 09:00. La consegna va effettuata sia in forma cartacea (1 copia, depositatela nella "Drop-box" sulla porta dello studio di Mizzaro), sia via posta elettronica (2 copie, una per docente, indirizzi: coppola@uniud.it e mizzaro@dimi.uniud.it). Si richiede un unico messaggio (inviato dal proprio indirizzo email ufficiale. Messaggi da fiorellino88@gmail.com o simili non verranno presi in considerazione):

• con oggetto "Progetto per Programmazione [TWM]",
• contenente nel corpo i nomi dei componenti del progetto e,
• in allegato ("attach"), in un unico file compresso (ad es. zippato), la relazione, il codice sorgente (i file ".java") e il bytecode (i ".class").

Riceverete una notifica dell'avvenuta riscezione dell'email.
NOTA Questo progetto è valido per chi intende sostenere l'esame nell'appello del 18, 24 febbraio 2011, e va quindi consegnato entro la scadenza. Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

 

Raccomandazioni

Alla valutazione del progetto concorrono vari aspetti (rilevanza delle semplificazioni apportate, qualità della relazione, ecc.), ma è di prioritaria importanza la qualità del programma prodotto, soprattutto per quanto concerne le caratteristiche di leggibilità, modificabilità... Esempi di criteri per ottenere una valutazione positiva:

• Il programma funziona?
• Resiste agli errori di interazione con l'utente?
• Si riescono ad apportare piccole modifiche nel comportamento senza riscrivere molto codice?
• L'interfaccia utente grafica è ridimensionabile? (ossia: non avete usato setResizable(false))? E quindi la si può usare su schermi di varie dimensioni?
• Avete usato i layout manager?
• Il codice è scritto correttamente, e avete seguito i principi della programmazione strutturata, dell'occultamento delle informazioni e dell'object oriented?
• Il codice è commentato? Ci sono abbastanza commenti? Non ci sono troppi commenti? I commenti non sono scontati? I tre tipi di commenti disponibili in Java sono stati usati in modo corretto?
• Avete rispettato le convenzioni sui nomi degli identificatori in Java?
• La relazione è chiara?
• Le variabili d'istanza e di classe non possono essere ridefinite come variabili locali?
• ecc. ecc.

Altre raccomandazioni:

• Non dichiarate una variabile se poi la usate una sola volta. Potete sicuramente scrivere un programma analogo senza quella variabile.
• Non copiare scriteriatamente il codice trovato su Internet: chiunque può scrivere su Internet e non è detto che sappia cosa sta facendo.
• Evitate al massimo setPreferredSize. Piuttosto pensate ad un layout che funzioni con qualsiasi dimensione sensata.
• Evitate commenti del tipo x = 2; //assegno 2 a x: qualunque programmatore sa cosa vuol dire x=2;!!
• Non usate static solo perché il compilatore dà errore. Usatelo solo se serve veramente.
• Limitate al massimo l'uso delle variabili d'istanza e di classe, preferite le variabili locali ai metodi.
• Non usate public solo perché il compilatore dà errore. Usatelo solo se serve veramente.

Per eventuali dubbi rivolgersi ai docenti, o durante l'orario di ricevimento o per posta elettronica. Ma solo dopo aver letto *bene* *tutte* le istruzioni! In particolare i paragrafi modalità e raccomandazioni.

Voto di laboratorio

Il voto di laboratorio viene calcolato con la stessa procedura dello scorso anno.

Consideriamo 4 parametri, ognuno dei quali può avere un voto compreso tra -2 e 2 a seconda dell'attività svolta. La media armonica dei quattro parametri moltiplicata per due dà il voto finale del laboratorio, che sarà compreso quindi tra -4 e 4.

Di seguito i 4 parametri con il voto:

1) Numero di esercizi semplici risolti:

INTERVALLO : PUNTI

162 - 137 : 2

136 - 109 : 1

108 - 81 : 0

80 - 41 : -1

40 - 0 : -2

2) Numero di esercizi valutazione risolti:

INTERVALLO : PUNTI

24 - 21 : 2

20 - 16 : 1

15 - 11 : 0

10 - 6 : -1

5 - 0 : -2

3) Voto risolutore:

INTERVALLO : PUNTI

1,00 - 0,81 : 2

0,80 - 0,61 : 1

0,60 - 0,41 : 0

0,40 - 0,21 : -1

0,20 - 0 : -2

4) Voto valutatore: vedi voto risolutore

Voto risolutore e voto valutatore verranno calcolati alla chiusura delle attività laboratorio secondo l'approccio spiegato in laboratorio. Le attività si chiudono il 24 gennaio. Questo vuol dire che in tale data verrà calcolato il vostro voto di laboratorio; avete comunque la possibilità di continuare ad esercitarvi su Moodle.

Moodle

I vincoli per il caricamento degli esercizi valutazione su moodle sono stati rilassati.

Luca

Progetto per l'appello del 24,31/1/2011

Leggete bene tutte le istruzioni! In particolare i paragrafi modalità e raccomandazioni.

Descrizione del lavoro

Si richiede di implementare un programma che, tramite un'interfaccia grafica, consenta all'utente di comprare biglietti ferroviari.

Il programma deve caricare da file di testo, passato come parametro sulla riga di comando, un insieme di orari di treni. Il file degli orari è strutturato come segue:

numero orari
orario partenza1
città di partenza1
orario arrivo1
città di arrivo1
costo biglietto1
orario partenza2
città di partenza2
orario arrivo2
città di arrivo2
costo biglietto2
...

Un file d'orari di esempio può essere:

3
10
Udine
12
Venezia
8
04
Bologna
05
Firenze
4
22
Cosenza
08
Torino
56

Il programma, dopo aver caricato gli orari in una oppurtuna struttura dati, deve mostrare un'interfaccia grafica con una lista (java.awt.List), una choice (java.awt.Choice) e un'area di testo (java.awt.TextArea). La lista deve mostrare gli orari caricati, uno per riga. La choice deve permettere di ordinare, in ordine crescente, gli orari nella lista secondo quattro criteri:

1. per orario di partenza
2. per orario di arrivo
3. per città di partenza
4. per città di arrivo

Ogni volta che si cambia scelta nella choice gli orari devono essere riordinati secondo il criterio selezionato.
Ogni volta che si clicca su un elemento della lista, si acquista il biglietto corrispondente e nella textarea viene mostrato il messaggio

Hai acquistato il biglietto per il treno da ... a .... Partirai alle ... e arriverai alle .... Ti è costato ... euro.
Fino ad ora hai speso ... euro.

(Attenzione! Questo non è il modo giusto di progettare interfacce!! Serve solo per semplificarvi la vita... Il corso di Interazione Uomo Macchina dovrebbe chiarirvi le idee...)

Suggerimenti

• Rappresentate in un'opportuna struttura dati in memoria tutti gli orari (quindi leggerete il file un'unica volta all'inizio dell'esecuzione del programma...).
• Potreste aver bisogno di una classe Orario, definita da voi, per rappresentare un singolo orario...
• Vi serviranno i metodi Integer.parseInt(String) per convertire una stringa in un intero (ad esempio, la stringa "5" nell'int 5) e Double.parseDouble(String) per convertire una stringa in un double
• Può esservi utile usare le Collection con i relativi metodi per l'ordinamento e i Reader con i relativi metodi per leggere da file di testo...

Modalità

Il livello di complessità del programma prodotto può essere deciso liberamente dagli studenti; ovviamente, progetti più articolati e complessi otterranno una valutazione migliore di progetti più semplici, ma si consiglia di fare "poco e bene" piuttosto che "tanto e male": progetti semplici possono comunque ottenere il massimo punteggio, purché ben fatti. La durata prevista del lavoro, considerando un gruppo di 3 persone che lavorano a tempo pieno, è di una settimana al massimo.
Il progetto va realizzato in gruppi di 3 persone (a meno di accordi particolari con il docente, possibili solo in casi di reale e comprovata necessità), e tutti i componenti di un gruppo devono conoscere tutti i dettagli del progetto, come se l'avessero realizzato da soli.
Va preparata una breve relazione, preferibilmente (ma non necessariamente) in XHTML + CSS, sul lavoro effettuato. La relazione deve contenere:

1. Una breve analisi del problema ed una descrizione intuitiva della vostra soluzione (meno di 2 pagine!).
2. Le eventuali semplificazioni apportate rispetto alla versione completa richiesta (poche righe). Le semplificazioni vanno adeguatamente motivate. Ovviamente, le semplificazioni porteranno a valutazioni inferiori, e in alcuni casi (quando le semplificazioni sono eccessive) a progetti insufficienti.
3. Eventuali aggiunte (cose in più non richieste; ad esempio uso di componenti dell'AWT non spiegati a lezione, uso delle Swing, aggiunta di funzionalità non richieste, aggiunta di menu, ecc. ecc.). Prima di aggiungere qualsiasi cosa, pensate a fare bene quello che è richiesto.
4. Le motivazioni di tutte le scelte effettuate (ad esempio, perché avete apportato una semplificazione, perché avete deciso di usare certi componenti grafici e non altri, perché avete fatto certe scelte di progetto piuttosto che altre, e così via).
5. Il listato completo del programma, con commenti (in javadoc, ma non solo), scritto in font non proporzionale (come questo: la "i" e la "m" occupano la stessa larghezza) e opportunamente incolonnato ("indentato").
6. Una "prova di esecuzione" (di circa 3 pagine) che illustri il funzionamento del programma: una spiegazione con testo e figure del modo in cui il programma funziona (aspetto dell'interfaccia utente, esempio di esecuzione adeguatamente spiegato, ecc.)

Di solito il progetto va consegnato inderogabilmente entro l'inizio della prova scritta dell'appello, ma per questo primo appello facciamo un'eccezione: la scadenza per la consegna è il venerdì 28 gennaio 2001 ore 09:00. La consegna va effettuata sia in forma cartacea (1 copia, depositatela nella "Drop-box" sulla porta dello studio di Mizzaro), sia via posta elettronica (2 copie, una per docente, indirizzi: coppola@uniud.it e mizzaro@dimi.uniud.it). Si richiede un unico messaggio (inviato dal proprio indirizzo email ufficiale. Messaggi da fiorellino88@gmail.com o simili non verranno presi in considerazione):

• con oggetto "Progetto per Programmazione [TWM]",
• contenente nel corpo i nomi dei componenti del progetto e,
• in allegato ("attach"), in un unico file compresso (ad es. zippato), la relazione, il codice sorgente (i file ".java") e il bytecode (i ".class").

Il progetto in forma cartacea può essere consegnato a mano subito prima del compito scritto oppure può essere consegnato nei giorni precedenti lo scritto direttamente a uno dei docenti o nella casella della posta del dipartimento di matematica e informatica.
NOTA Questo progetto è valido per chi intende sostenere l'esame nell'appello del 24, 31 gennaio 2011, e va quindi consegnato entro la scadenza. Non si accetteranno ritardi per nessun motivo. Per gli appelli successivi saranno predisposti altri progetti.

Raccomandazioni

Alla valutazione del progetto concorrono vari aspetti (rilevanza delle semplificazioni apportate, qualità della relazione, ecc.), ma è di prioritaria importanza la qualità del programma prodotto, soprattutto per quanto concerne le caratteristiche di leggibilità, modificabilità... Esempi di criteri per ottenere una valutazione positiva:

• Il programma funziona?
• Resiste agli errori di interazione con l'utente?
• Si riescono ad apportare piccole modifiche nel comportamento senza riscrivere molto codice?
• L'interfaccia utente grafica è ridimensionabile? (ossia: non avete usato setResizable(false))? E quindi la si può usare su schermi di varie dimensioni?
• Avete usato i layout manager?
• Il codice è scritto correttamente, e avete seguito i principi della programmazione strutturata, dell'occultamento delle informazioni e dell'object oriented?
• Il codice è commentato? Ci sono abbastanza commenti? Non ci sono troppi commenti? I commenti non sono scontati? I tre tipi di commenti disponibili in Java sono stati usati in modo corretto?
• Avete rispettato le convenzioni sui nomi degli identificatori in Java?
• La relazione è chiara?
• Le variabili d'istanza e di classe non possono essere ridefinite come variabili locali?
• ecc. ecc.

Altre raccomandazioni:

• Non dichiarate una variabile se poi la usate una sola volta. Potete sicuramente scrivere un programma analogo senza quella variabile.
• Non copiare scriteriatamente il codice trovato su Internet: chiunque può scrivere su Internet e non è detto che sappia cosa sta facendo.
• Evitate al massimo setPreferredSize. Piuttosto pensate ad un layout che funzioni con qualsiasi dimensione sensata.
• Evitate commenti del tipo x = 2; //assegno 2 a x: qualunque programmatore sa cosa vuol dire x=2;!!
• Non usate static solo perché il compilatore dà errore. Usatelo solo se serve veramente.
• Limitate al massimo l'uso delle variabili d'istanza e di classe, preferite le variabili locali ai metodi.
• Non usate public solo perché il compilatore dà errore. Usatelo solo se serve veramente.

Per eventuali dubbi rivolgersi ai docenti, o durante l'orario di ricevimento o per posta elettronica.

News dal lab

Venerdì [12:30, 14:15] esercitazioni in laboratorio.

Vi aspetto

Luca

Esami scritti dello scorso anno

Ecco qui 4 esempi dagli appelli dello scorso anno, così potete esercitarvi: 1, 2, 3, 4.

S.