qsecofr:
MauroTec:
In buona sostanza condivido, tranne per il giudizio; bravo, più bravo ecc. Non ho capito l'ultima parte riguardo al programma di contabilità, mi sembra di capire che chi scrive un programma di contabilità sia meno "bravo" di chi scrive una ISR. Ovviamente non è così, perchè sono lavori complessi entrambe e richiedono competenze diverse.
Riguardo ai commenti sul codice, posso dire evitando di usare la parola "bravo" che se è intesa in modo corretto ci può stare.
no vabbe il bravo più bravo era inteso che hai scritto un codice "più rapido ed efficiente della moltiplicazione semplice" quindi diremo "bravo" per aver "ottimizzato il codice" con una soluzione "non scontata".... che diventa "più bravo" quando commenti quello che hai fatto perchè aggiungi all'ottimizzazione del tuo software la "leggibilità e mantenibilità"
ed il discorso del programma di contabilità era per indicare un programma molto grande ma che di solito non contiene necessità di ottimizzazione spinta del codice... in altre parole se devi fare una IRS devi andare veloce e moltiplicare per 4 è più lento dello shift; se invece devi moltiplicare per 4 un listino prezzi di 1000 record per fare un report è meglio che usi la moltiplicazione e lo shift te lo tieni nel cassetto perchè se no nessuno capisce che cacchio hai fatto ne il perchè.... e quindi nonostante il gesto tecnico non sei stato utile... un po' come essere un bravo attaccante che vuole segnare solo in rovesciata ma che non passa mai la palla
Ero quasi sicuro che il significato di bravo e più bravo che volevi lasciare intendere era quello che io considero corretto, purtroppo non siamo tutti coscienti e magari può passare il messagio che io che ho scritto una ISR sono da considerare più bravo di chi ha scritto un qualunque programma di contabilità, programma che io allo stato attuale non saprei neanche progettare, dico di più questo tipo di programmi va sviluppato in gruppo perchè è difficile trovare un solo individuo con tutte le competenze necessarie.
In gioventù ho scritto un programma di gestione veterinaria che prevedeva anche la stampa del registro bollato, di cui non sapevo nulla, è ho dovuto acquisire le dovute competenze, ora non ricordo con precisione ma c'è una procedura precisa da seguire nel caso si blocchi la stampante, si inceppi la carta ecc, mi sembra di ricordare che la pagina stampata a metà deve essere annullata e si deve riprendere la stampa dalla pagina di interruzione.
Non dimentichiamo che in ambito obbistico è richiesto uno sforzo maggiore al singolo individuo, infatti esso deve, analizzare, acquisire le competenze mancanti e poi sviluppare il codice. Mancano ancora la fase di test e debug che anche in questo caso è portata avanti da un singolo individuo, però se il codice viene rilasciato ed è interessante si può contare su un discreto numero di tester e debugger umani.
gingardu:
uwefed:
gingardu:
e poi la strada più giusta e quella di farsi da soli lo sketch su "misura"
gingardu hai letto il Sketch? Ti sfido a scriverne uno simile.
Ciao Uwe
tutto dipende......
da cosa serve lo sketch
certo che se alla fine muove dei servo per l'irrigazione temporizzata del prato non vedo perche non puoi
farti tu il programmino,
poi raramente uno sketch è bello che pronto e giusto per quello che vuoi fare, a meno che non si tratta di un progetto tutto completo e ti va bene cosi,
"alla lunga" dopo che si ha un po di pratica , e meglio scriversi le cose di sana pianta.
le cose funzionanti fatte con la propria testa sono sempre capite e modificabili/migliorabili all'istante
la penso così poi .... magari mi sbaglio non so.
Da anni c'è una ricerca incessante al fine di ottenere degli strumenti che permettano ad un programmatore di comprendere ed usare codice scritto da altri programmatori, uno degli strumenti nati con quell'intento è proprio il linguaggio C++, seguito da tutti gli altri linguaggi orientati agli oggetti, java, c#, D ecc. Già, c'è anche il D oltre al C, ma ancora non è maturo. Il problema principale è legato al codice non flessibile, guarda caso più il codice è flessibile più si riduce la performace potenziale, cioè ancora adesso un codice rigido usa meno ram ed è più rapido in esecuzione di un codice flessibile e cioè facilmente adattabile.
Il compilatore gioca un ruolo fondamentale, perchè permette allo sviluppatore di scrivere codice flessibile senza preoccuparsi delle prestazioni pure, ma questo compilatore non è ancora nato, anche se gcc fa tante cose mirabolanti.
E allora come ci si deve comportare?
Non pensare alle prestazioni, c'è sempre tempo per rimediare.
Scrivi codice auto-documentante: 128 è un mumero, buffer_zise è un parametro auto-documentante, 128 no, e rx_buffer_size documenta in dettaglio il codice.
Buona la prima, accade nell'arte: es gli scultori non hanno una seconda possibilità, perchè non deve accadere anche in programmazione?
E infatti, se il codice lavora correttamente consideralo buono e vai avanti (buono non vuol dire non migliorabile).
Non ti fissare. Più facile a dirsi che a farsi.
Testa piccole porzioni di codice: se il test è positivo il prossimo compito deve essere quello di scrivere la documatazione, se rimandi confondi codice testato con codice da testare.
E per ultimo, cerca anche di divertirti mentre sviluppi.
PS: sapere come comportarsi non vuole dire essere capaci di comportarsi come si sa, ma quanto meno ci si può lavorare su.
Ciao.