Newsgroup: it.comp.lang.delphi
Titolo: Delphi non è case sensitive

Non capisco perche' Borland non ha ancora inserito il case sensitive
nel codice (come c/c++/java/php).
Dover ricorrere al suggeritore tutte le volte per avere nomi capitalizzati
nello stesso modo...
Perche' Borland non ci ha mai pensato? In questo mi sembra proprio faccia
l'occhiolino al visual basic.....
es.
FatturaTestataAccontoDaPreventivo := ....
fatturatestataaccontodapreventivo := ...
hanno lo stesso effetto ma la seconda e' illeggibile.
--
Morde. 
morde[at]programmer[.]net

 capitalizzati nello stesso modo...
??? Secondo me č MOLTO meglio cosě, oltretutto il suggeritore č una cosa
*comodissima*!
--
Jax
Journeying Artificial Xenomorph

 hanno lo stesso effetto ma la seconda e' illeggibile.
Se un programmatore è talmente stupido da usare nomi di questo tipo non vedo
cosa sotto C o altri linguaggi gli impedisca di scrivere:
fatturatestataaccontodapreventivo char[30];
Nando Dessena fece una bella frase il cui succo era: "Nulla impedisce ad un
buon programmatore visual basic di scrivere dell' ottimo codice; nulla
impedisce ad un programmatore mediocre di scrivere codice pessimo usando
Delphi"
--
- Carlo -

Delphi"
E con questo, cosa vuoi dire Bertuccini? Ti pregherei di chiarire il senso
della tua citazione, perche' ritengo sia rivolta al sottoscritto, e quindi 
mi sa piu' di *offesa* che di critica.


 schrieb im Newsbeitrag
news:8s366v8fg6jcp1s7b...@4ax.com...


*comodissima*!
Non discuto sull'utilita' del suggeritore, quella e' indubbia, quanto sulla
mancanza del case sensitive alla quale ti abitui lavorando su file system unix like
e con linguaggi piu' rigorosi (almeno nella forma).
Ciao,


 forma).
Come hai giustamente detto, è solo questione di abitudine. Uno che ha sempre
lavorato su Win vedrà il case sensitive come un'incasinamento inutile, tu lo
vedi come una cosa utilissima... punti di vista :)
IMHO il case sensitive rende più rigoroso un linguaggio, ma può creare
inutili casini... io non ho nessun problema a scrivermi sNumCelle, perché
ormai sono abituato a scrivere così, non scriverò mai per sbaglio snumcelle,
perché il mio dito si posa automaticamente sullo shift :)
Però io non sono un programmatore esperto, e quindi ti chiedo di elencare
quali sono, secondo te, i vantaggi del case sensitive. Io, sinceramente, non
ne vedo e non ne sento minimamente la mancanza :)


 non mi sembra sia da programmatori tanto stupidi, ti pare?
A mio avviso il Field Editor ed il modo in cui questo definisce i nomi dei
campi č uno delle classiche "bucce di banana" su cui Delphi scivola.
Primariamente perchč genera dei nomi veramente troppo lunghi (che senso ha
generare nome tabella e nome campo quando generalmente basta solo il nome
del campo?), in secondo luogo perchč almeno potrebbe metterci un prefisso
"fld" (ormai credo che quasi chiunque faccia uso dei prefissi davanti ai
nomi di oggetti, variabili ecc.). Ogni volta che genero dei campi mi tocca
sempre rinominarli premettendo "fld" e togliendo il nome della tabella: a
volte č un lavoro piuttosto noioso e lungo. Come minimo la funzionalitą di
generazione dei nomi di campi dovrebbe essere parametrizzabile in relazione
alle proprie esigenze.
Ciao.
Gianluca.


    Via De Gasperi, 14 - 42019
    Scandiano (Reggio Emilia)

 quindi mi sa piu' di *offesa* che di critica.
Aho, aho! Non ti metterai anche tu a offenderti alla prima cosa che ti si
dice! Che è, sei stato contagiato? ;))))
A me non sembra che ti abbia detto quella cosa per offenderti!



Non mi sembra corretto che un ambiente di sviluppo ponga dei prefissi
automatici ai componenti...
Infatti, io non uso lo stesso prefisso che usi tu per i campi, e quindi
mi ritroverei nella condizione di doverli rinominare.
A parte questo, non vedo particolari problemi nel nome che Delphi
attribuisce automaticamente ai campi e, in ogni caso, questo si può
sempre modificare secondo le proprie esigenze, così come è possibile
modificare i nomi di ogni singolo componente o controllo visuale che
posizioniamo sul form.
Ciao!


A me non sembra che ti abbia detto quella cosa per offenderti!
No, e' che oggi non e' proprio giornata.... :-(
Nessun problema, Jax.
Ciao


 hanno lo stesso effetto ma la seconda e' illeggibile.
Imho, avere il case sensitive non risolve.
Io posso decidere di usare sempre il minuscolo e buonanotte.
Credo che la leggibilità del codice dipenda molto da chi programma e un po
meno dal COSA si usa x programmare, fermo restando che se i tools di
sviluppo permettono di evitare kazzate di grosso calibro, la cosa non puo
non essere apprezzata.
Infine, io non ho mai lavorato in c, quindi una domanda scema mi è
consentita....
Possibile che  l'utilità del case sensitive si riduce alla leggibilità del
codice?
Bye
A.

sottovalutati.
Mi associo. :)
Ciao


 nel codice (come c/c++/java/php).
Secondo me č molto meglio che non ci sia il case sensitive (l\'ideale sarebbe che venisse tolto anche al c, c++, ecc...), in un grosso progetto devi ricordarti non solo i nomi, ma anche come sono scritti.
Immagina cosa succede se devi modificare o correggere un programma che hai scritto molto tempo fa o che addirittura non hai scritto tu.
------------------------------------------------------------------------
Questo messaggio e' stato inviato tramite i Newsgroup di Punto
http://www.punto.it
------------------------------------------------------------------------

 mi ritroverei nella condizione di doverli rinominare.
Appunto: nella condizione di doverli rinominare ci sono io.
Non che io voglia che li rinomini tu ;-) ma basterebbe la possibilità di
parametrizzare il modo con cui Delphi genera i nomi degli oggetti, proprio
in relazione alle esigenze di scrittura del codice.
Alla fine diventa solo una questione di comodità ed ottimizzazione del
tempo. In genere quando inserisci un controllo in un form devi comunque
passare dall'Object Inspector per modificare le varie proprietà, tra cui il
nome.
Nella generazione dei campi devi *per forza* entrare nell'Object Inspector
per modificare il nome e, nella maggior parte dei casi, le altre proprietà
non devono essere modificate.
Ciao.
Gianluca.

 mi sa piu' di *offesa* che di critica.
Non era affatto rivolta a te.
Tu sottolineavi i possibili vantaggi apportati da un linguaggio che
differenzia maiuscole e minuscole, e hai detto che Delphi non seguendo
questa strada fa l'occhiolino a vb ... da cui la "citazione" riportata.
--
- Carlo -

non devono essere modificate.
Infatti!
L'unica possibile soluzione attualmente sta a livello base dati
dando al field un nome gia' breve.


Io non ho detto questo. Se vuoi quotare a tuo modo fa pure,
Il problema e' che io avevo postato del codice di un *mio* programma
(anche se quei nomi sono autogenerati dal field editor)
e tu hai commentato sopra quel codice.
Quindi, non e' tanto il darsi una calmata, quanto quello di capirsi.
E' un anno che seguo il ng, e circa 6 mesi che lo frequento postando, 
e ho letto sempre tutti i tuoi post, quindi non pensare che abbia
voluto aggredirti o che ce l'abbia con te, perche' non e' vero,
ci sono solo rimasto male per il commento a quel codice che era
stato preso da un mio sorgente.
Quindi, ti ringrazio per avere chiarito, pesonalmente considero chiuso 
l' incidente.
ciao :)


 non devono essere modificate.
Non è detto. Io uso il Field Editor per aggiungere i campi della tabella
quando devo creare campi persistenti di tipo Lookup. La creazione dei
campi Lookup si fa con l'apposita finestra di dialogo; in generale,
siccome i nomi attribuiti da Delphi mi stanno benissimo così come sono,
raramente mi capita di entrare nell'Object Inspector.
Inoltre, sono dell'opinione che ci sono troppe standardizzazioni
personali per poter introdurre una finestra di opzioni sull'attribuzione
automatica del nome che andrebbe alla fine a complicare un'interfaccia
che deve essere il più semplice e rapida possibile.


 dando al field un nome gia' breve.
Non capisco cosa abbiano di così brutto i nomi attribuiti da Delphi ai
campi persistenti. :-)


campi persistenti. :-)
Di brutto niente, sono solo la somma nometabella+nomecampo, il problema e' che
in certi casi (vedi mio post iniziale) si ottengono nomi troppo lunghi che tolgono
leggibilita' al codice e danno problemi di praticita' nella dimensione dell'area
di editing (lunghezza riga editabile)
Esempio: 
TabManifestiRingraziamentoContenutoRingraziamento: TMemoField;
Questa dichiarazione e' stata generata dal field editor.
Ora, seguendo la strada di Plevani, sarebbe saggio abbreviare il field
in, ad esempio, fldTestoRing.
Questa e' un'ottima soluzione, ma ha un punto debole: se un domani ti 
tocca intervenire su questo campo e devi cercare tutti i punti dove il programma
vi fa ricorso, come puoi ricordarti che abbreviazione gli hai dato?
Ti faccio un esempio pratico: il mio programma ha circa 80 tabelle, 60 form, e conta
un totale di circa 151mila righe compilate (ultimo build).
Se tra un mese devo modificare la gestione del campo citato in esempio, per me
basta fare un grep su tutti i sorgenti per il nome del campo stesso.
Se invece lo rinominassi, dovrei poi ricordarmi in tutto il progetto che ho usato
quella forma abbreviata.
Spero di essermi spiegato bene, oggi tra il nervosismo e la sorte e' una giornata
difficile... :-)
Ciao!
P.S.
Gli esempi citati sono presi da un mio software, siate clementi nel criticarle.. :-)


Altro punto debole :
Se hai due controlli Table con lo Stesso Nome Campo?
io personalmente preferico
non fld TestoRing
ma TManTESTORING
(e per avere ciň scrivo i campi in stampatello nella table)
anche a occhio nel codice riesco a capire che trattasi di un campo :) CIAOUX

anche a occhio nel codice riesco a capire che trattasi di un campo :) CIAOUX
E' una buona tecnica :)
ciao



io ad esempio uso il TUTTO_MAIUSCOLO solo per le costanti.
;-) alla fine č solo una questione di gusti.
Ciao,
Gianluca.

 ;-) alla fine č solo una questione di gusti.
Hai ragione, per molte cose sě... ma trovo ugualmente costruttivo
discuterne, anche perchč spesso non si programma da soli ma in team, ed č
buono sapere come la pensa la maggioranza, per adeguarsi (se possibile) e
cercare di rendere la vita + facile a chi lavora con noi.
Ciao, David

nel codice (come c/c++/java/php).
Perché si rifa ai principi del Pascal, che è case-insensitive e,
secondo me, va bene così.
E` sempre una questione di convenzioni adottate dal programmatore.
Personalmente, uso delle convenzioni tali che non mi portano a sentire
la mancanza di un ambiente "case-sensitive" (per quanto programmi
molto anche in C/C++).  
In Delphi esplicito sempre le maiuscole/minuscole quando serve (i.e.,
scrivo "tblFatture", anziché "tblfatture", oppure
"CalcolaGiorniDiProva", anziché "calcolagiornidiprova", ecc...).
Cerco, poi, per quanto possibile, di seguire il coding-style indicato
da Borland.
D'altronde, la natura case-sensitive di un linguaggio non è sempre un
punto di forza. 
Il codice seguente:
/* C/C++ */
int Dose = 10;
int dose = 20;
...compila senza problemi ed è un errore logico _assolutamente grave_.
-- 
Andrea Laforgia
"640kb of memory should be enough for anyone." -- Bill Gates.

"fld" 
Non lo reputo corretto, il nome, se vuoi, lo cambi tu esplicitamente.
E poi, a me non piace "fld" ;-)


io ho riportato tanto di esempio in codice C [...]
Che, per intenderci, non era codice C ;-)


che hai scritto molto tempo fa o che addirittura non hai scritto tu.
Se è questo il punto, la natura case-sensitive o meno del linguaggio è
l'ultimo dei problemi ! fidati ! ;-)


basta solo il nome del campo?), 
Questa, più che una scelta progettuale, è una necessità: si possono
avere campi con lo stesso nome per più tabelle e, visto che i campi
persistenti sono oggetti veri e propri, è necessario che abbiano un
nome distinto (per cui viene aggiunto, come prefisso, il nome della
tabella).


per modificare il nome
Perché *per forza* ? personalmente non lo vedo come un obbligo.


basta fare un grep su tutti i sorgenti per il nome del campo stesso.
...e per fortuna che esiste GExperts ;-)


tbSociSoc_Ana_Codice > fldSocAnaCodice
Sembrerà strano, ma io preferisco di gran lunga la prima forma: si
comprende, a colpo d'occhio, qual è la tabella e qual è il campo.


raramente mi capita di entrare nell'Object Inspector.
Idem per me.  Io uso il Field Editor per i lookup e i campi calcolati,
anche se non capisco perché Borland non abbia implementato i campi
persistenti come "proprietŕ" degli oggetti dataset e non come oggetti
separati, questo avrebbe consentito di avere un property editor per i
singoli campi e non essere costretti ad usare la dialog box la prima
volta e l'object inspector tutte le volte seguenti ;-)
Inoltre, credo che non ci sarebbe dovuto essere bisogno di esplicitare
l'uso dei "campi persistenti" (il termine "persistente", tra l'altro,
mi sembra piuttosto fuorviante).  Il sistema dovrebbe caricare, in
memoria, la struttura dei campi, all'atto dell'apertura della tabella.
Purtroppo sono molto stanco e, probabilmente, mi sfugge qualche
dettaglio che renderebbe tutto inapplicabile, ma mi sembra che non
sarebbe male, in via di principio ;-)


 TabManifestiRingraziamentoContenutoRingraziamento: TMemoField;
Questo problema non mi tange: io uso sempre e solo la notazione
Tabella.FieldByName('NOME').As.......
:-)
A parte questo, cosa dovrebbe fare Delphi per abbreviare il tuo nome di
campo?
Per identificarlo univocamente serve *almeno* il nome della tabella e il
nome del campo...e Delphi *non* aggiunge altro, quindi mi sembra che la
dichiarazione tanto contestata di Delphi sia in realtà la più breve che
si possa ottenere.
Ciao!


 Tabella.FieldByName('NOME').As.......
In genere anche io faccio lo stesso.
L'unico svantaggio è che questo tipo di espressione viene risolta a runtime.
Ovvero, se il nome passato a FieldByName non esiste hai una eccezione.
Imho, fare un controllo sui nomi dei campi quando si usa una sintassi
risolta a runtime fa parte dei normali passi da seguire durante la scrittura
del codice.
Usando i campi persistenti eviti questo problema in quanto assegni delle
variabili di memoria e se il compilatore non le trova, si blocca e segnala
che l'identificatore non esiste.
Per contro, mi sembra di ricordare che su d5 i campi persistenti danno
problemi sulla lettura del loro valore qualora l'utente non esce dal
controllo associato al campo.
Bye
A.

 sarebbe male, in via di principio ;-)
Sebbene io ne faccia uso in poche occasioni, credo che i campi
persistenti godano anche di altre utili funzionalità. Ad esempio, poter
definire a livello centralizzato il formato da utilizzare per i
decimali, nonchè la larghezza tipica del contenuto del campo (comoda
quando si associano DBGrid alla tabella, così la colonna assume subito
una larghezza consona gestita in modo centralizzato)...
Poi, c'è la possibilità di definire anche eventi di lettura e scrittura
dei valori del campo, che in molte occasioni mi sono tornati utili per
effettuare ingegnerizzazioni dell'ultimo minuto.
Ad ogni modo, suppongo che la "persistenza" sia necessaria per poter
immagazzinare le proprietà dei campi a livello di applicazione,
altrimenti non vedo altri modi...
Certo, si potrebbero modificare direttamente all'interno del DataSet e
salvarli nel DFM come proprietà, ma poi si dovrebbe anche andare a
verificare se alcuni campi sono stati rimossi o modificati nel tipo o
nelle caratteristiche, e forse a livello *automatico* non sarebbe
possibile.
Mi spiego: quando elimino un campo dalla tabella fisica a cui fa
riferimento un campo persistente generato dinamicamente all'interno del
DataSet e di cui ho modificato le proprietà, queste vanno mantenute
oppure no? Il campo viene eliminato automaticamente perdendo le mie
impostazioni?
Ho riflettuto anche io sulla scelta di non rendere i TField parte
integrante del TDataSet (ad esempio, come proprietà di tipo
TCollection).
So che in una TCollection tutti gli elementi contenuti appartengono allo
stesso identico tipo, di classe discendente da TCollectionItem, mentre
nel caso dei campi persistenti ciascun campo è di tipo diverso
(TStringField, TBlobField...), selezionato in base al tipo di campo che
si sta trattando, discendenti comunque da una classe comune. Pertando,
la Collection non era una soluzione valida e quindi la più immediata
probabilmente era quella di discendere la classe generica TField (o
TCustomField??) da TComponent, rendendola così "salvabile" nel DFM, e
successivamente creare le classi discendenti specifiche per ogni tipo di
campo esistente.
Ovvio che aggiungere i campi a mano e impostarne le proprietà sarebbe
stato un po' una scocciatura, quindi è stato creato il Field Editor per
consentire al programmatore di importare in un sol colpo i campi di una
tabella con le proprietà impostate ai valori di default e modificabili
opportunamente.
Si tratta comunque di opinioni personali che mi sono fatto riflettendo
sulla problematica...solo Borland può dire se ci ho preso... :-)


 controllo associato al campo.
Non saprei...


...e per fortuna che esiste GExperts ;-)
Infatti, le ho installate e lo uso assai... :-)
Ciao


 Tabella.FieldByName('NOME').As.......
Anche io sono solito a qs tipo di approccio... ma ci sono casi in cui devi
utilizzare dei campi persistenti :
nello specifico io sto sviluppando un'applicazione che utilizza il Midware
di F.Piette e le tabelle servono come mascheramento dei dati presenti nei
buffer... per cui DEVO per forza specificare il Field Layout e creare i
campi persistenti.
Ciaoux

la scrittura di codice case sensitive rende il codice più leggibile.
Infatti, ma non è questione di linguaggio, bensì di stile di
programmazione:
// Delphi
function GeneraNumeroCasuale: Integer;
begin
 ...
end;
// C++
int generanumerocasuale()
{
    ...


 la scrittura di codice case sensitive rende il codice più leggibile.
???
Se intendi che scrivere
procedure VaiAPrendereIlLatte(DaChi: String);
è più leggibile di
procedure vaiaprendereillatte(dachi: string);
sono d'accordo, però questo non c'entra con lo scrivere con un linguaggio
case in/sensitive; io in Delphi scrivo sempre maiuscole e minuscole, perché
sono *quelle* che rendono più leggibile il codice, così come potrei scrivere
tutto in minuscolo (o peggio in maiuscolo) in un linguaggio case sensitive,
e sarebbe abbastanza schifoso da leggere.
Però non è che il case sensitive in sé renda il codice più leggibile, anzi!
Per qualsiasi persona che legge un sorgente, e in generale per qualsiasi
persona, Data e data sono la stessa cosa; nei linguaggi case sensitive
invece no, e questo potrebbe essere causa di problemi.
--
Jax
Journeying Artificial Xenomorph

Però non è che il case sensitive in sé renda il codice più leggibile
L'unico vantaggio di un linguaggio case-sensitive, IMO, è quello di
_costringerti_ a usare il "case" dei caratteri, identico a quella
della definizione della variabile: se dichiaro PiPpO, devo usare PiPpO
dappertutto.  Questo è molto utile, ma tutto dipende dallo stile di
scrittura del codice del programmatore.  Secondo me sarebbe bene che,
in ogni software house, vi fossero delle "coding rules" che accomunano
il codice di tutti.  


codice?
Non saprei i vantaggi oggettivi posso dire l'unico che ho mai avuto io
:D
In mathlab (roba di analisi numerica) che e' appunto case sensitive,
posso usare la convenzione matematica per le trasformate che vuole in
minuscolo la funzione nel spazio originario e in maiuscolo in quello
trasformato.
che so
f(t)
F(f)
ma e' un caso particolare dovuto al fatto che in tali ambiti si ha la
terribile abitudine di usare una sola lettera per indicare le varie
"funzioni", infatti vedi nei libri di analisi i prof che sforano nelle
lettere greche per dimostrare un teorema (ma qui tutto cio e' OT).
Per quanto riguarda delphi per me case insensitive va benissimo anche
perche' poi ripulisco sempre tutto con il code beautifier del progetto
jedi :D
De
-- 
.     _  _______  ļ,ø*°`°*ø,ļ_ļ,ø*°`°*ø,ļ_ļ,ø*°`°*ø,ļ_ļ,ø*°`°*ø,ļ_
  /| // /__  __/  Kirys <My e-mail is a working antispam e-mail>
 / |/ \   / /     Kirys Tech 2000: 
http://www.kt2k.com
/__|\__\ /_/ 2000 ļ,ø*°`°*ø,ļ_ļ,ø*°`°*ø,ļ_ļ,ø*°`°*ø,ļ_ļ,ø*°`°*ø,ļ_