Quante righe di codice al massimo, in media per ogni unit?

[Lorenzo]

Perdonate se sembra sciocca la domanda,ma per quanto riguarda i progetti che siano in Pascal o in altri linguaggi,in questo caso Pascal,di media quante righe di codice al massimo sono UMANAMENTE accettabili per ogni units, 600,1000,2000?

E' che mi sento come suggestionato dal dubbio di diventare disordinato quando mi capita di scrivere classi con più di cinquanta elementi,tra variabili,oggetti vari e metodi.

Per fortuna che in questi casi,il nostro "migliore amico" è sempre l'ispettore del codice sia in Delphi che in Lazarus.
Amico che ci permette di orientarci tra i vari elementi di una classe,all'interno dell'implementazione dei metodi e addirittura rinominarli assieme ai loro riferimenti.

[nomorelogic]

questo è un po' un dilemma di molti programmatori

C'è chi preferisce una unica unit per tutta una libreria, perché così chi la usa deve mettere in uses una sola unit.
C'è chi fa una unit per classe, più gestibile, ma escono una sfilza di unit.

Io uso un approccio un po' misto col quale mi trovo bene:
- faccio una unit per i tipi (record, costanti, oggetti, ecc...) di un certo "argomento"
- poi una unit che comprende tutte le classi che naturalmente servono a coprire lo stesso "argomento"

Non è sicuramente un approccio universale, tuttavia mi ci trovo bene e lo adotto spesso.

Edit:
il numero di righe è un parametro al quale non faccio mai attenzione
preferisco che le unit siano coerenti col significato che gli attribuisco

[bonmario]

Anche io ragiono per argomento e non bado al numero di righe.

[DragoRosso]

Ciao,
io ragione in modalità ancora più mista:

- una unit con tutte le dichiarazioni globali e tutte le classi, record e quant'altro di supporto generico (tipo RTL). Questa unit viene duplicata per ogni progetto e adattata.
- ogni ulteriore unit contiene classi, record privati, ed altro ad uso specifico. Ogni unit è indipendente come funzionalità e generalmente non richiama altre classi se non tramite la unit tipo RTL;
- una unit orchestatrice, cioè mantiene il monitor di tutto (ed ha accesso a tutto) per verificare tempi, leak ed altro. In tale unit vengono verificati anche semafori, crtical section ed altro relativi alla sincronizzaione tra Thread (normalmente una mia applicazione crea ed usa da 20 ai 50 Thread).
- una unit relativa al database, dove LI e solo LI vengono gestite le chiamate da e per il DB. L'accesso dal DB non è normalmente consentito da nessuna altra unit in tutta l'applicazione.
- il programma composto da unit / form che usano poi tutto il resto per svolgere il compito dell'applicazione.

La lunghezza di ogni unit non è importante, l'importante è che ogni unit sia sufficientemente autonoma per il suo scopo.
Ho unit da oltre 20000 righe tra codice e definzioni.

Sempre in generale, solo la unit simil RTL viene usata nella sezione interface delle altre (comrpese le unit / form dell'applicazione). Tutte le altre unit se necessario verranno richiamate nella sezione implementation.

[Lorenzo]

In linea di massima sono d'accordo con tutti gli interventi.
Trovo che sarebbe un fattore limitante mantenersi sotto una determinata di soglia a livello di righe di codice.
Anche usare una Unit per ogni argomento ha il suo fine orientativo.
Vi ringrazio per i vostri interventi.

- una unit relativa al database, dove LI e solo LI vengono gestite le chiamate da e per il DB. L'accesso dal DB non è normalmente consentito da nessuna altra unit in tutta l'applicazione.
- il programma composto da unit / form che usano poi tutto il resto per svolgere il compito dell'applicazione.

Riguardo questa parte aprirei un altro post dedicato al data module.
La trovo parecchio interessante dal punto di vista della sicurezza dell'applicazione dove il  nostro software ha anche il dovere di non fungere mai da veicolo per attacchi al DBMS.

[DragoRosso]

Cosa diversa, a differenza della lunghezza di una unit, è il numero di proprietà / procedure / funzioni / campi presenti in una classe o record.

Generalmente tendo a spezzare classi / record in ulteriori record base, proprio per non avere una lunghezza infinita di "singolarità" da gestire ... che poi nella maggior parte delle volte ciò torna produttivo perchè sono parti che vengono riusate anche in altri ambiti.

Un record con molti campi tendenzialmente è possibile "spezzarlo" in ultreiori record che poi lo comporranno.
Poi faccio uso abbondante (direi smodato) di record avanzati, ossia record che definiscono anche funzioni / procedure pubbliche per la gestione degli elementi (che generalmente sono privati).

Facendo coì mi torna molto facile adattarli ed espanderli, mantenendo piena compatibilità (elemento più che fondamentale per me) con il passato.
E ogni record ha la sua "finalization" e "initialization" sempre, i campi interni vengono sempre messi a default (che non è detto sia quello corrispondente al tipo del campo).

[Lorenzo]

Tendenzialmente se ho una form,per le funzioni specifiche che hanno ha che fare con la macchina,uso i metodi privati,per richiamarli,i metodi pubblici che spesso mi fungono da controllers.
@DragoRosso
L'impiego dei record in Pascal può risultare geniale perchè trattandosi di una monoistanza(un solo oggetto) farebbero anche risparmiare memoria ed è anche un modo di incapsulare i metodi senza dichiararli all'interno di una classe come statici o metodi di classe.
Credo che i loro vantaggi abbiano ispirato gli sviluppatori di Golang con le Struct.

Tornando alla lunghezza delle righe,in Delphi oso di più perchè l'ispettore di codice pare un pelino più efficace e rapido.
Senza togliere nulla a quello di Lazarus che già fa molto bene il suo lavoro.

[DragoRosso]

Tornando alla lunghezza delle righe,in Delphi oso di più perchè l'ispettore di codice pare un pelino più efficace e rapido.
Senza togliere nulla a quello di Lazarus che già fa molto bene il suo lavoro.

Bhè, l'ho espresso più volte, Lazarus /FPC e Delphi sono due prodotti affini ma profondamente differenti. Con risorse e strutture (supporto ed economiche) completamente differenti e non paragonabili (anche solo per il fatto che Delphi sia a pagamento, a parte la CE).

In genere, ma forse sono di parte (anzi sicuramente), l'assistenza di Delphi nella produzione di codice è sicuramente un gradino superiore a quella di Lazarus. Se non altro per la dotazione standard di componenti, per la faciltà di una loro aggiunta e per gli ausili disponibili durante l'editing (come un server LSP, o il codeinsight o l'errorinsight o le vecchie IOTA).

Il "live binding", lo "style manager", il supporto integrato al "touch" e alle "gesture", la tastiera virtuale nativa sono strumenti a cui difficilmente riuscirei a fare a meno.

Lazarus / FPC hanno dalla loro il fatto che sono altamente modulabili con un sacco di "switch" che consentono di personalizzare sia la funzionalità del codice scritto che del codice compilato.

[Lorenzo]

@DragoRosso
E' proprio per gli strumenti da te citati,utilizzo Delphi CE per prototipare un progetto concepito per FCP/Lazarus.
C'è FireDAC mi dà molti meno grattacapi di Zeos.

Sono più che d'accordo: le soluzioni commerciali sono e saranno sempre più rifinite rispetto alla controparte open source.
A parte diverse meravigliose eccezioni in cui il software open source eguaglia(se non addirittura supera) in qualità il software commerciale.
Prima di fare un colloquio per una software house oramai mi informo prima per capire se usano tecnologie open source,perchè voglio capire se per sviluppare usano anche tecnologie open source o solo quest'ultime.
Perchè nel caso sviluppassero con solo materiale open source(perdonate il pregiudizio),secondo me o si tratta quasi sempre di una startup.

[DragoRosso]

Perchè nel caso sviluppassero con solo materiale open source(perdonate il pregiudizio),secondo me o si tratta quasi sempre di una startup.

Tieni presente che Lazarus / FPC viene usato da diversi membri del forum in produzione (per prodotti commerciali).

[Lorenzo]

Su Lazarus/FPC non ho dubbi sulla qualità,lo sto facendo anch'io.
Perchè per un singolo,le licenze Embarcadero possono essere un bel salasso.

Parlo in generale,visto che mi occupo principalmente di software in C++ e C# e riguardo a molte librerie Open Source,ci troviamo dinanzi a prodotti spesso scarsamente documentati o poco rifiniti.

[DragoRosso]

Su Lazarus/FPC non ho dubbi sulla qualità,lo sto facendo anch'io.
Perchè per un singolo,le licenze Embarcadero possono essere un bel salasso.
Parlo in generale,visto che mi occupo principalmente di software in C++ e C# e riguardo a molte librerie Open Source,ci troviamo dinanzi a prodotti spesso scarsamente documentati o poco rifiniti.

Bhè in quei linguaggi (in particolare sul C++) è probabile che la profusione di energie vada sul codice più che sulla documentazione. Inoltre sono linguaggi "popolari" quindi si trovano anche "librerie" sviluppate dalla IA o con ampie porzioni di copia / incolla.

[Lorenzo]

Bhè in quei linguaggi (in particolare sul C++) è probabile che la profusione di energie vada sul codice più che sulla documentazione. Inoltre sono linguaggi "popolari" quindi si trovano anche "librerie" sviluppate dalla IA o con ampie porzioni di copia / incolla.

Hai nominato i due principali mali,la IA ed i copia & incolla,entrambe sembrano condividere le stesse probabilità di fallacità.
Sulle fallacità IA,tiro un sospiro di sollievo: c'è ancora speranza per noi umani.