continuazione da "imparare a programmare"

[^TiGeRShArK^]

Originariamente inviato da k0nt3

un'altro esempio è lo unit testing scrivere un test implica senza ombra di dubbio aggiungere righe di codice in più, ma dubito che un test avrebbe senso se introducesse ulteriori errori.

Scrivere un test non è funzionale all'algoritmo che risolve il problema.
E' solo uno strumento messo in mano al programmatore per controllare che l'algoritmo disegnato faccia il suo lavoro.
E' l'equivalente automatizzato del testing manuale.
O forse mi vorrai dire che fare del testing manuale implica l'aumento di righe di codice?

[Lyane]

Originariamente inviato da cdimauro

Quando si arriva in mettere in dubbio la buona fede e l'onestà intellettuale dei propri interlocutori, allora è segno che è molto meglio smettere di discutere...

Ammetto che il dubbio mi e' venuto.

[marco.r]

Originariamente inviato da PGI-Bis

Se dovessi considerare cose che non c'entrano con le premesse del discorso è chiaro che la faccenda cambierebbe.

Mi sembra che il punto di partenza sia stata la frase "expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous", sulla quale hai chiesto "Perchè è bene essere concisi? Non si sa." e alla quale e' stato risposto fondamentalmente "perche' si introducono meno bug".
Stante questo, direi che il mio discorso rientra pienamente nelle premesse. Il motivo principale per cui quest'ultima affermazione e' ragionevole sta proprio nella frase iniziale: l'eliminazione del superfluo.
Per definizione stessa, il superfluo non aggiunge nulla al codice ma toglie risorse al programmatore: tempo per scriverlo, tempo per leggerlo, tempo per modificarlo per adattarlo alle modifiche al resto del programma. Tutto tempo che viene distolto da altre attivita' piu' produttive. Di conseguenza il programmatore da un lato viene distratto dalla componente rilevante dal codice, dall'altro deve accellerare i tempi per ottenere lo stesso risultato in meno tempo. Da qui un maggior numero di errori.
Se vuoi una dimostrazione matematica non ce l'ho, sicuramente ci sono una serie di dati statistici a supporto.

Ma in questi e altri casi la lunghezza non sarebbe che la manifestazione di una condizione non ottimale di produzione del codice. Vale a dire il problema non è la lunghezza ma la lunghezza è il sintomo di un problema.

Le condizioni non ottimali di cui parli sono quelle normali nel lavoro di tutti i giorni, soprattutto tempo e concentrazione limitati. Impossibile non tenerne conto se si vuole avere un qualcosa che abbia un valore pratico.

[k0nt3]

Originariamente inviato da ^TiGeRShArK^

dipende.
Un programmatore migliore abbassa la probabilità d'errore, ma per progetti non banali il suo contributo è cmq minimo dato che la probabilità di errore è inesorabilmente destinata a crescere CHIUNQUE sia il programmatore.

in realtà non intendevo che ci sono programmatori infallibili e programmatori incapaci, ma piuttosto che ogni programmatore ha i suoi punti di forza e di debolezza. ma sono daccordo che "dipende" è appropriato.
e comunque sono daccordo che al crescere della complessità del progetto aumenta la probabilità d'errore, la mia contestazione riguardava il fatto che il numero di righe fornisse una misura (accettabile) della complessità.

l'osservazione sul testing è lecita e ci avevo pensato anche io però se ci pensi ancora meglio vedi che commettere un errore nel test porta a commettere un errore nel codice funzionale (altrimenti il test non servirebbe al suo scopo). e lo stesso vale per la programmazione by-contract

[k0nt3]

Originariamente inviato da cdimauro

Non mi pare proprio: http://www.math.unipd.it/~tullio/IS-...e_2003/P19.pdf

è interessante però che dice uno dei limiti nel contare le righe di codice è che è una metrica dipendente dal linguaggio usato. la prima cosa che ho detto io quando avete erroneamente confrontato le righe di codice java con quelle python praticamente

[^TiGeRShArK^]

Originariamente inviato da k0nt3

in realtà non intendevo che ci sono programmatori infallibili e programmatori incapaci, ma piuttosto che ogni programmatore ha i suoi punti di forza e di debolezza. ma sono daccordo che "dipende" è appropriato.
e comunque sono daccordo che al crescere della complessità del progetto aumenta la probabilità d'errore, la mia contestazione riguardava il fatto che il numero di righe fornisse una misura (accettabile) della complessità.

l'osservazione sul testing è lecita e ci avevo pensato anche io però se ci pensi ancora meglio vedi che commettere un errore nel test porta a commettere un errore nel codice funzionale (altrimenti il test non servirebbe al suo scopo). e lo stesso vale per la programmazione by-contract

Anche se sbagli il testing manuale hai lo stesso risultato
Il numero di righe dei test per me è totalmente slegato dal numero di righe di codice del progetto.
Si deve considerare solo in termini di tempo impiegato per testare, non certo per il numero di bug, dato che, potenzialmente, se i test sono fatti bene, + test ci sono e + la probabilità di commettere errori diminuisce

[fek]

snip