Insomma io sono dell'idea che le funzioni debbano fare una sola cosa, che ne facilita il riulitizzo e la unit test coverage. Fino ad oggi mi e' andata bene. Se lei crede che siano idee negative mi spiace e faro' tesoro dei suoi testi fantasma
Insomma io sono dell'idea che le funzioni debbano fare una sola cosa, che ne facilita il riulitizzo e la unit test coverage. Fino ad oggi mi e' andata bene. Se lei crede che siano idee negative mi spiace e faro' tesoro dei suoi testi fantasma
Il problema non consiste certo in questa banalità: questa è solo una fallacia di mutatio argumenti.Originariamente inviata da cisco87
Insomma io sono dell'idea che le funzioni debbano fare una sola cosa, che ne facilita il riulitizzo e la unit test coverage. Fino ad oggi mi e' andata bene. Se lei crede che siano idee negative mi spiace e faro' tesoro dei suoi testi fantasma
I criteri per la decomposizione funzionale sono numerosi e l'approccio agile è decisamente riduttivo. Mi limito ad una sola questione elementare, a titolo di esempio: come si concilia questa vaga tensione alla "semplicità" con il criterio di information hiding di Parnas?
La vera questione è comunque ben altra, e vi abbiamo dedicato fin troppi post: copiare la stringa a rovescio per poi confrontarla con l'originale è un'idea naive tanto quanto il bubblesort, ossia un vero e proprio errore progettuale algoritmico che non va in alcun modo incoraggiato. Questo è l'errore rimarginato, un errore decisamente poco difendibile e non giustificabile. Tutto il resto citato in seguito, Fowler e compagni di merende, ha davvero ben poca attinenza: non c'è teorico serio, per quanto poco apprezzato, che possa davvero giustificare una "soluzione" del genere.
Quanto ai testi, le mie bibliografie tematiche sono ben note (e troppo spesso scopiazzate senza citarne la fonte, anche in passato sul presente forum) e c'è solamente l'imbarazzo della scelta: dal classico poker di Knuth col TAoCP al Sedgewick, al CLRS, all'Harel fino alla lunga silloge degli autori minori e specialistici per la parte algoritmica, sfido chiunque a trovare apologie di questo modo assurdo di approcciare un problema del genere.
Quanto ai testi di engineering, per restare alla genericità del mainstream ma con molto più rigore rispetto ad Agile, posso facilmente consigliare gli arciclassici Pressman, Sommerville, e a latere il Mandrioli-Ghezzi (sì, proprio il Ghezzi autore dell'articolo in parola) uniti al Myers "The art of software testing", Wiley che uso nei miei corsi come aperitivo, giusto per iniziare a familiarizzare anche con metodologie non mainstream. Poi ci sono due dozzine di testi specifici per i metodi formali e le metodologie di progetto e verifica per i sistemi critici, se interessa davvero progredire.
In conclusione: sarà davvero un "segno dei tempi" che si debbano sprecare così tanti caratteri per riaffermare che una simile "soluzione" errata è una sciocchezza da evitare? Su FIDOnet sarebbe bastato un post. Forse anche meno.
Ultima modifica di M.A.W. 1968; 02-01-2016 a 20:01
• Un plauso a Grisha Perelman, raro esempio di genuino anticonformismo umano e scientifico.
Quindi da che il web era pieno di gente che sparlava di C Martin e Fowler, adesso devo andare in libreria a prendere suddetti libri per trovare qualcosa? Io resto della mia idea, appoggio i testi da cui ho appreso quelle idee e i principi che hanno portato a svilupparle, sinceramente io dopo aver letto quel codice manco il bidello la prenderei a fare. A partire dai nomi di variabili, passando per le magic strings e un commento su un return che non ha assolutamente ragione di esistere, senza considerare che una funzione cosi' lunga e' segno di avere codice copypastato lungo tutto il programma e genera duplicazione, oltre che rompere il divide-et-impera, SRP. etc.
Comunque, come vede, delle persone possono avere differenti opinioni su un punto e generare lo stesso punto di vista l'uno sull'altro, buona serata, adesso devo passare a fare attivita' piu' produttive
Senza alimentare flame e quant'altro. Da molto meno sapiente rispetto a voi ma con un piacere ad aver letto le vostre idee con le tanti fonti, da studente approccerei sempre nel modo in-place poichè con calcoli alla mano è sicuramente quella più efficiente. Io sono dell'idea che un pò di bravura nel dare una soluzione "non banale" sia da apprezzare, un pò di ambizione personale nel poter dire: cacchio come l'ho pensato bene!
Il che ci riporta esattamente a quanto ho scritto nel primo post, che avrebbe dovuto semplicemente chiudere la questione.
Dubito francamente che il seguente codice possa definirsi "difficile da leggere" anche per uno studente, pur offrendo prestazioni asintotiche più che decenti. Ottimo esempio di come coniugare efficienza e semplicità (come è spesso il caso degli algoritmi più smart).
codice:#include <stdio.h> #include <stdlib.h> #include <string.h> #define MAX_BUFF_SIZE 255 int main() { char buff[MAX_BUFF_SIZE]; char *p; size_t len, j; char is_palindrome = 0; puts("Immettere la stringa da controllare: "); fgets(buff, MAX_BUFF_SIZE, stdin); p = strrchr(buff, '\n'); if (NULL != p) { *p = '\0'; } len = strlen(buff); if (len < 1) { /* Gestione errore */ return EXIT_ERROR; } len -= 1; for (j = 0; j <= (len >> 1); ++j) { printf("%02d) %c - %c\n", j, buff[j], buff[len -j]); is_palindrome = (buff[j] == buff[len -j]); if (!is_palindrome) { break; } } printf("\n** La stringa immessa%se' palindroma. **\n", is_palindrome ? " " : " non "); return EXIT_SUCCESS; }
Ultima modifica di M.A.W. 1968; 02-01-2016 a 19:58
• Un plauso a Grisha Perelman, raro esempio di genuino anticonformismo umano e scientifico.
Ho riprovato a riscrivere il codice utilizzando un solo ciclo. Ho ancora lo stesso problema, il programma funziona valutando solo l'ultimo indice e non l'intero array.
Questo è il codice:
codice:void confronta(int n, char pal[]) { bool v; int i=0; while (i<n) { if (pal[i]==pal[(n-1)-i]) { v=true; } else { v=false; } i++; } if (v==true) { cout << "Palindromo"; } else { cout << "No palindromo"; } } int main() { int l=6; char palindromo[]={'a','b','c','c','b','a'}; confronta(l, palindromo); return 0; }
Ok, grazie mille ho risolto
Magari mostra anche come hai risolto, a beneficio di altri lettori e per eventuali ulteriori consigli.
• Un plauso a Grisha Perelman, raro esempio di genuino anticonformismo umano e scientifico.
Ho risolto in questo modo, sono alle prime armi quindi sicuramente immagino che si possa fare di meglio:
codice:void confronta(int n, char pal[]) { bool v; int i=0; while (i<n) { if (pal[i]==pal[(n-1)-i]) { v=true; } else { v=false; break; } i++; } if (v==true) { cout << "Palindromo"; } else { cout << "No palindromo"; } } int main() { int l; cout << "Inserire la lunghezza dell'array: "; cin >> l; char palindromo[l]; cout << "Inserire i caratteri dell'array: "; for (int a=0; a<l; a++) { cin >> palindromo[a]; } confronta(l, palindromo); return 0; }
Permessi di invio
