A tutti i programmatori che...

1) ...quando scrivono metodi/funzioni/routine vomitano il codice nell'editor srotolando autentiche pergamene con codice lungo come la fame, ripetuto, ridondante, senza spezzarle in funzioni e senza un minimo di ottimizzazione

2) ...se ne fregano di quei concetti basilari della programmazione strutturata come l'isolamento ed il riutilizzo di funzioni e procedure (non parliamo poi di classi, è già troppo...), proprio per evitare codice copiaincollato dappertutto che da debuggare diventa un inferno

3) ...quando scrivono il codice lo buttano giù a muzzo, senza un minimo di formattazione ed impaginazione, compresso, con le indentazioni fatte a cazzo, con più istruzioni infilate su una sola riga che ti va metri fuori dallo schermo, e via dicendo

4) ...quando dichiarano una variabile non gli danno un nome decente, col prefisso che ne identifica il tipo e lo scope, seguito da un nome descrittivo, ma nomi tipo a, b, c, x, pTot, mRs, sStr, ecc...

5) ...si inventano giri astrusi, intricati e fuori di testa per fare delle cose semplici o che tante volte sono addirittura inutili, che a metterci dentro le mani è capace solo chi ha scritto quello schifo (se si ricorda perché l'ha scritto in quel modo...)

6) ...non scrivono un cazzo di commento che sia uno, porca di quella tr***ia, che per capire il perché di certe scelte devi aprire il cranio a quello che ha scritto il codice, ficcargli un cavo nel cervello, infilartelo su per il culo, e cercare di leggere da remoto dentro quella mente bacata che ha scritto quella merda

7) ...se programmano in Visual Basic (come nel mio caso), infarciscono il codice di GoTo e GoSub piuttosto che strutturare le routine in modo decente o spezzarle in funzioni (vedi punti 1 e 2), manco si stesse ancora programmando col Basic del Commodore 64, e che se devi capirne il funzionamento è peggio che sgarbugliare un piatto di spaghetti alla carbonara secco e scotto di 4 giorni

8) ...sempre se programmano in Visual Basic, scavalcano la gestione degli errori mettendo On Error Resume Next in cima ad ogni fottuta procedura, che se il programma si pianta dal cliente perché impazzito in un loop infinito a causa di un'eccezione non gestita, te non riesci a capire perché cazzo quella merda s'è bloccata, e ci perdi ore finché non ti porti i dati del cliente in casa e ci fai girare sopra il programma col codice aperto

9) ...quando fanno i programmi danno la precedenza al grado di figaggine dell'interfaccia grafica piuttosto che alla correttezza dell'elaborazione dei dati, e quel che è peggio nello scrivere il codice fanno un pastone unico dove gestione della GUI e del motore di elaborazione dei dati sono un tutt'uno

10) ...dulcis in fundo non scrivono una cristo di documentazione sul loro lavoro di m***a, cosicché tutti quelli che ci dovranno mettere le mani dopo di loro alla fine avranno istinti omicidi

A tutti i programmatori che nel loro lavoro fanno quanto scritto sopra: ANDATEVENE SONORAMENTE AFFANCULO!!!!

Cambiate mestiere, datevi all'ippica, ma per dio, lasciate perdere la programmazione!

Oggi per colpa di uno dei nostri programmi di merda, il mio pranzo è consistito in un kebab mangiato in fretta e furia alle 16:15 del pomeriggio, perché quella schifezza ha deciso di non funzionare alle 11:45 ed il cliente ci ha chiamato, ed io ovviamente sono dovuto star li ad impazzirci dentro fino alle 17:30 di sera.

Scusate sfogo e turpiloquio.

"Errare è umano, ma per incasinare tutto come si deve ci vuole un computer."

Molto vero, purtroppo.

Non so bene come sia con Visual Basic, ma credo che più o meno ci capiamo. Ecco cosa rischio io ogni giorno:

mima comprendo in pieno il tuo sfogo

Alle volte è già difficile metter mano a distanza di tempo a del codice scritto secondo le buone regole del buon programmatore che tu hai citato, non oso pensare come tu sia riuscito a venirne a capo se scritto in quel modo

Non ho ben capito in che versione di Visual Basic programmi, se NET oppure ancora la 6, comunque comprendere ed imparare ad usare gli oggetti o classi ti apre un mondo e ti cambia completamente il modo di programmare, non capisco come certi programmatori riescano ancora a farne a meno specialmente quando il progetto è di una certa entità.

Maaaaaaah....siete delle pippe, non usate il metodo giustoooo!

Date un occhiata al tutorial che ho postato nell'altro thread, insegnano come programmare un sistema operativo in soli 10 minuti, Con un metodo facilissimo e infallibile, e ho imparato anche io!

Funziona, provare per credere!

Si ho visto, stasera come detto di la mi vado a guardare il video, da quello che hai scritto sono sicuro che diventerò un baboon coder migliore

A suon di bestemmie ed improperi rivolti verso il mio capo, che ha scritto il codice, e che attualmente è in vacanza in Thailandia. Spero che quello che avrà avuto nelle orecchie non sia stato un fischio, ma una delle sirene del Titanic

Che tra l'altro siamo stati in 2 a perderci tutta la giornata su quello schifo, nemmeno io da solo



Io attualmente sviluppo sia in .NET (VB.NET e C#, con preferenza per quest'ultimo) sia in Visual Basic 6, in passato ho lavorato anche su altri linguaggi ed ambienti di sviluppo. I programmi però attualmente sono fatti in VB6 ed è con uno di questi che ho avuto il problema. Nel frattempo si stanno sviluppando le versioni nuove, fatte in .NET.

Il problema è che oltre a non essere sviluppati secondo le buone regole di scrittura del codice, sono pure fatti alla bell'e meglio ed in modo approssimativo, per la serie "funziona ma non so perché" (finché non arriva il momento in cui al programma gli girano le palle e decide di non andare più).

Una volta ho chiesto al mio capo perché non dividesse un po' le routine in subroutine e funzioni, in modo da semplificarle e magari renderle riutilizzabili. La sua risposta è stata "eh ma perché così vedo tutto quanto a schermo in una procedura sola ed è più semplice". Avrei voluto sparargli

Non è proprio modo di lavorare

W l'assembler

LD A, (HL)
INC HL
JP NZ, next

Non so quasi niente di Assembler, ma dimmi se ho capito giusto:



Carichi (LD = Load, presumo) il valore numerico contenuto in A all'indirizzo HL (dentro HL c'è un indirizzo di memoria)



Incrementi di 1 la locazione di memoria HL (INC = Increment, presumo), in sostanza stai sommando 1 al numero che c'era originariamente in A.



"Jumpi" (JP = Jump, presumo, e non parlo del pezzo di Van Halen ) da qualche parte, presumo all'istruzione precedente per continuare ad aumentare il valore contenuto in HL.

In sostanza hai fatto un contatore che conta all'infinito (perlomeno finché non crasha il programma perché la locazione di memoria non è più in grado di contenere il valore). Giusto?

Pure io e come te prediligo C#, attualmente lo trovo il migliore per programmare in windows


Ah e questo è pure capo andiamo bene!


In un certo senso ora capisco la cosa, della serie io lo faccio poi tanto se dopo c'è qualcosa che non va mando gli altri a metterci le mani.

No bom diciamo che se serve il suo aiuto ce lo da. Non è cattivo il mio capo, anzi è una brava persona, il problema però è che se nel momento in cui serve il suo aiuto è irreperibile (come ieri, dato che appunto è in Thailandia in vacanza) noi perdiamo un sacco di tempo a decifrare il suo lavoro perché è fatto malissimo e non è documentato, il cliente è fermo, ed ovviamente quelli che si devono sorbire le cristonate di quest'ultimo siamo noi.

Inoltre, in particolar modo negli ultimi tempi, è parecchio per aria e si fa vedere molto poco in ufficio, lavora più che altro da casa (è lui che sta sviluppando il nuovo applicativo in VB.NET), però anche questo non va bene, perché non partecipa più alle attività giornaliere della ditta e quelle ormai pochissime volte che si fa vedere viene solo una mezz'oretta alla sera per farci vedere i progressi del nuovo software, o per fare l'aperitivo. Mi stanno bene gli aperitivi ed i progressi del nuovo programma, però non venire in ufficio solo per quelli.

Sembra che non dia più la giusta importanza alle cose, e questa è un'impressione che abbiamo un po' tutti in ditta, incluso il mio secondo capo (il suo socio), cosa che tra l'altro mi ha confermato lui stesso. E per me, come programmatore, lavorare in queste condizioni è parecchio frustrante.

Senza contare il fatto che quando il mio capo fa i programmi, la prima cosa a cui bada è l'aspetto visuale della GUI, per la quale scrive vagonate di codice complicato, incasinato e spesso ridondante, che poi mescola alla gestione dei dati (per esempio ci sono punti del programma dove, per capire prima di un salvataggio di un record se un dato immesso dall'utente è corretto, il codice si basa sullo stato dell'icona messa a fianco della relativa casella di immissione, icona che viene visualizzata o nascosta in base alla correttezza del valore immesso e quest'ultimo controllo viene fatto in un altro punto del codice, robe di questo genere...).

Anch'io bado alla GUI quando faccio i programmi ed anzi sono parecchio pignolo, però al contempo cerco di mantenere le cose semplici ed ordinate, primo perché i nostri programmi sono gestionali e non videogiochi (quindi non serve una GUI stellare piena di colori, icone e chi più ne ha più ne metta, come quelle che fa lui), secondo per non cristonare quando bisogna far manutenzione.

Non volevo dire quello, ci mancherebbe.

Visto che lui è il capo e considerando che la programmazione non è il suo forte allora forse farebbe meglio a occuparsi più della parte organizzativa dell'azienda.


Infatti... Di solito la parte GUI la lascio per ultima, prima deve essere a posto tutto il resto e quello che ci sta dietro poi alla fine mi dedico anche alla parte grafica dell'interfaccia.

Solo per curiosità, quali database utilizzate per i vostri gestionali?

Ops, mima, non volevo farti scervellare, ho scritto a caso le prime istruzioni dello Z80 che ricordavo, la sequenza non ha tanto senso.
LD A, (HL) carica nell'accumulatore il byte puntato dall'indice contenuto nel registro a 16bit HL
INC.... ovvio
JP NZ salta se il flag Z non è settato, cioè se il risultato, e cioè HL, non è zero

ma lascia perdere, da quanto scrivi ne hai già avuto abbastanza....

Non ho capito una fava insomma

Mima ritenta, sarai più fortunato

Magari dopo aver visto il video dell'altro thread ci capirò qualcosa in più

Purtroppo mi riconosco nella situazione. In più, ci aggiungerei anche gli spazi di indentazione diversi da editor a editor, per cui se da me è perfetto e uso ad esempio Vim, l'altro che usa Emacs lo vede tutto sballato.


Il massimo l'ho trovato visionando uno script PHP qualche settimana fa: $U per lo username e $P per la password. Non sarebbe neanche tanto grave se fossero le uniche due variabili nello script. Peccato però che di variabili ce ne fossero almeno una ventina.


Comunque, allacciandomi al discorso sull'interfaccia grafica, odio abbastanza la realizzazione delle GUI. Di solito i programmi li sviluppo con interfaccia testuale e solo successivamente applico l'interfaccia grafica.

pensa Mima, ne capisco talmente tanto di programmazione che credevo ce l'avessi di nuovo coi complottisti

Nono, niente strali contro i complottisti, qui si parla di cose molto più terra terra.

Riesumo il thread.

Dicevo, a tutti i programmatori che chiamano le variabili con nomi alla cazzo e scavalcano la gestione degli errori... oggi scorrendo quell'orribile marasma di costrutti messi più o meno a caso, che vorrebbe essere il codice di quei mostri tentacolari orribili che dovrebbero passare per i nostri programmi, in cima ad una procedura lunga come la fame mi ritrovo la seguente perla:

On Error Resume Next

Dim x As Long
Dim v() As String
Dim p As PropertyGridItem
Dim l As PropertyGridItem
Dim s As String
Dim g As String
Dim b As Boolean
Dim s1 As String
Dim b1 As Byte
Dim rs As Recordset
Dim c As CFileFinder

Poi ditemi se uno non si deve incazzare

Ed il peggio è che la dentro di "perle" del genere ne è pieno... e non sono nemmeno il peggiore dei mali

dipende dalla complessità del programma e dal linguaggio usato ma fondamentale, dal tempo che si ha a disposizione per concludere il progetto.
Ovvio che se si ha tempo a non finire la documentazione è d'obbligo.
Nella mia esperienza vi sono porzioni di codice che difficilmente si riesce a rendere chiare anche documentando come ad esempio, scrivere un automa che riconosce un linguaggio è non banale, meglio partire dall'espressione regolare ed usare un generatore; imprelementare un albero RB è non banale.
Ci sono strutture dati così complesse che è meglio prenderle per quelle che sono altrimenti si perde una miriade di tempo.