sondaggi 2:tab o spazi

[absc]

philotette

Onestamente, nel 2025 con i monitor ultra-wide che abbiamo… stiamo davvero discutendo di tab 4 o tab 8?

Mi sono reso conto che sono regole astruse, ormai. Lo stile ha senso, l’indentazione, usa un po’ quel che ti pare come dimensione dei tab, basta essere consistenti a livello file anche con la lunghezza delle righe.

Se a me piace tab-8 e a te tab-4, secondo me possiamo usare tranquillamente quello che preferiamo anche se lavoriamo insieme. Tanto la dimensione del tab la decidi nel tuo editor del cuore!

[teflon]

Cioccolataio Svizzerese

io python l’ho imparato verso il 2000, quando ancora non era cosi’ diffuso. Avevo fatto un servizio windows che tirava giu’ email ed estraeva gli attachment.

Poi lo usavo per fare le demo per mostrare l’utilizzo di componenti COM in windows con OLE Automation con un client diverso dal Visual Basic.

Infine, per un software che girava in linux lo avevamo embeddato, e ci avevamo scritto dei componenti, in modo che i nostri installatori potessero implementare le customizzazioni richiesta dai clienti. Ricordo che era stato semplice e il codice era organizzato in maniera logica, per cui avevamo capito abbastanza rapidamente come fare. Ma forse lo avevamo trovato semplice rispetto al resto del codice che scrivevamo all’epoca

Ma sto parlando di 25 anni or sono… Non ne ho seguito gli sviluppi per un bel pezzo e ora me lo sto ritrovando dappertutto per la parte di Data Engineering e mi sa che mi tocchera’ rimettermi a usarlo. E no, io non faccio ML

Quando l’ho imparato, il linguaggio era abbastanza semplice, non so se siano stati aggiunti costrutti astrusi, oppure se la complicazione di cui parli riguarda l’enorme mole di librerie che esistono

[Aethiss]

teflon said in sondaggi 2:tab o spazi:

Per chi fa data-engineering ormai e’ quasi obbligatorio

sono molto d’accordo. mi ha piacevolmente stupito anche django (framework x python, penso lo conosci), anche se il codice dove ho dovuto mettere mano io era veramente un merdaio

pero’ ammetto che l’indentazione di python non riesco a digerirla

[amigaunicorn]

teflon bc usa il tab

int main(){if(1){printf("ciao\n");return 0;}}

ottiene

int main()
{
	if(1)
	{
		printf("ciao\n");
		return 0;
	}
}

fatto coi tab.

[albione]

teflon spazi per compatibilità, che se riapro il mio codice da un altro pc con un altro editor, senza la “mia” indentazione può darsi che nemmeno riesca più a riconoscerlo come mio

[amigaunicorn]

Aethiss said in sondaggi 2:tab o spazi:

pero’ ammetto che l’indentazione di python non riesco a digerirla

usare l’indentazione come grammatica e’ come dire che nel debug la dimensione del monitor conta.

Presto anche i font e il colore dei caratteri diverranno grammatica. Se non e’ verde, non e’ un int. E se e’ in grassetto, allora e’ una funzione.

Ormai dai farlocchi mi aspetto di tutto. Anche la regola che se il font e’ comic sans, allora 1+1 = 11.

[Aethiss]

Amiga Unicorn

Piu’ che altro, io che vengo da anni (come hai capito) di esperienze su js et simila, una delle prime cose che faccio, e faccio fare, sono tutte le regole di eslint e prettier (che comprendono anche tabs), soprattutto per il max-line.

Giusto per allineare tutto il team ed avere una parvenza di formattazione decente.
Una volta che si hanno regole “comuni”, ognuno nel suo programma di coding, si mette poi la configurazione che vuole.

Amiga Unicorn said in sondaggi 2:tab o spazi:

Presto anche i font e il colore dei caratteri diverranno grammatica. Se non e’ verde, non e’ un int. E se e’ in grassetto, allora e’ una funzione.

mi hai dato un idea per un plugin di webstorm

[amigaunicorn]

Aethiss said in sondaggi 2:tab o spazi:

Giusto per allineare tutto il team ed avere una parvenza di formattazione decente.
Una volta che si hanno regole “comuni”, ognuno nel suo programma di coding, si mette poi la configurazione che vuole.

te lo giuro, quando sento che i developers hanno un meeting per stabilire la “strategia di git”, o “la naming convention delle variabili”, o “le regole di lint” a me la mano corre alla pistola.

[Aethiss]

Amiga Unicorn said in sondaggi 2:tab o spazi:

te lo giuro, quando sento che i developers hanno un meeting per stabilire la “strategia di git”, o “la naming convention delle variabili”, o “le regole di lint” a me la mano corre alla pistola.

eh, che ti posso dire… questi siamo ad oggi. un po’ woke, lo ammetto.
L’unica riunione che (con me) che non si fa, e’ riguardo “strategia di git”. Si fa come dico io e basta

Per il resto ho visto riunioni anche su come “ottimizzare” le riunioni.

[philotette]

Aethiss
Senza offesa eh, ma stupidate del genere per me sono idiozie tirate su da gente che non sa programmare per darsi un senso.
Ho visto progetti partire bene, dove poi è arrivato il genio 42xDev che ha imposto il checkstyle di google perché così “il codice viene scritto più manutenibile e meno buggato”.
In realtà la codebase è entrata in una spirale di immerdamento (tipo, una funzione non deve avere più di 4 argomenti -> refactora tutte le funzioni per usare una nuova classe contenitore che non è che una mappa riempita a runtime -> serve davvero che dica quanto una merdata del genere rende incomprensibile il codice?) e non ne è più uscita. Un sacco di spuntine verdi, e del codice assolutamente incomprensibile per chiunque non fosse il genio. Genio che peraltro metteva dei vettori di dimensione finita e conosciuta, e ordinati! in una lista che scorreva per cercare un elemento, perché hey, gli stream!

Sarà che ho il dente avvelenato, ma credo che il codice prima di tutto debba muovere bit e applicare funzioni. Ha senso non scrivere tutto sulla stessa riga e poche altre convenzioni, ma oltre diventa crearsi un problema per poter essere quelli che trovano la soluzione.

[Aethiss]

philotette said in sondaggi 2:tab o spazi:

in una lista che scorreva per cercare un elemento, perché hey, gli stream!

forse semplicemente qualcuno doveva dirgli che in fondo non era un genio.
per il resto, non e’ che mi trovi in disaccordo poi tanto.

comunque io parlavo di semplici regole di “style” comuni, tutto qua’

[teflon]

philotette sento un certo “clean code” ( Uncle BOB) vibe nella regola che hai descritto… Del libro me ne avevano parlato bene, poi quando sono arrivato a “i metodi devono avere un solo argomento, se ne servono di piu’ bisogna usare i membri delle classi” mi sono caduti i coglioni. *sbam* *sbam* *rolllll*

Da freelancer cerco di uniformarmi allo stile usato nella codebase in cui devo mettere le mani e bon

[absc]

teflon

Sono problemi creati da accademici e “consulenti”.

Gente strapagata che non ha mai messo davvero in produzione nulla.

Qualcuno li chiamava “architecture astronauts”, ma d’altronde, poi hai gente come quella che descrivo in un articolo.

Questa è gente che è solo interessata a masturbarsi con la tecnologia, quando la tecnologia dovrebbe essere solo un mezzo per risolvere problemi veri.

Ho sempre odiato tutte queste “raccomandazioni”, o “best practice” (ma chi ha deciso che sono best Porca Madonna?):

[teflon]

Aethiss said in sondaggi 2:tab o spazi:

teflon said in sondaggi 2:tab o spazi:

Per chi fa data-engineering ormai e’ quasi obbligatorio

sono molto d’accordo. mi ha piacevolmente stupito anche django (framework x python, penso lo conosci), anche se il codice dove ho dovuto mettere mano io era veramente un merdaio

pero’ ammetto che l’indentazione di python non riesco a digerirla

django so cosa e’, ma non l’ho mai guardato. Finora sono riuscito a evitare di fare robe per il web

[Aethiss]

Cioccolataio Svizzerese said in sondaggi 2:tab o spazi:

quella che descrivo in un articolo .

Bello & interessante.

[amigaunicorn]

Cioccolataio Svizzerese

vero, ma non concordo col tuo articolo quando parli di “non-functional specification”. Per esempio, se io ti dico come loggare perche’ voglio settare l’allarmistica, e’ una NFR (Non functional Requirement) e si, e’ una best practice loggare il problema e non quanto accade alla tua classe: se mi dici che non hai spazio in un device, dimmi quale device, e cosi’ via.

Non le vedo cosi’ terribili, onestamente. A meno che nel tuo caso sotto NFR non ti abbiano messo “fammi un pompino”. in quel caso, ok.

[absc]

Amiga Unicorn

Piú che la cosa in sè, quello che vado a contestare (e magari non era chiaro), è che sta gente si spippetta reinventando cose che esistono da eoni, spacciandole come
nuove.

Per il resto, io sono assolutamente a favore di specificare per bene cosa vogliamo ottenere e con me sfondi una porta aperta. Tant’è che sono l’unico cane a cercare di documentare dei requirements.

Ma che non mi vengano a raccontare che loro hanno prodotto queste “innovazioni” nel loro scrauso “forum”.

DO-178 non esiste da oggi.

[amigaunicorn]

Cioccolataio Svizzerese uhm… mah, non penso di aver inventato gli NFR, penso di averli imparati. E se vado come consulente a fare l’architetto di un nuovo sistema, spesso specifico anche il formato dei logs. Un formato in json per linee, che mi sono inventato, per rendere la vita facile a kibana.

[absc]

Amiga Unicorn

Su cose come logging ed allarmistica concordo assolutamente con te. Gente ci ha sbattuto il muso per 50 anni e cose come MISRA sono nate dall’esperienza.

Ma… gli spazi o i nomi delle variabili? Possiamo davvero parlare di “best practice”?

[amigaunicorn]

Cioccolataio Svizzerese said in sondaggi 2:tab o spazi:

Ma… gli spazi o i nomi delle variabili? Possiamo davvero parlare di “best practice”?

il problema e’ che come system architect a me di come programmano non frega niente. me ne frega di come loggano, perche’ dai logs si tirano fuori KPI e allarmi. Questo si’.

Certo, a volte vengono da me a chiedere lumi su queste cose, e la risposta che io do e’ “no, non partecipero’ al meeting, se devo essere coinvolto, te lo scrivo sul LLD , Low Level Design, e tu poi lo fai”. Se scali, poi ottieni una decisione, no?