sondaggi 2:tab o spazi

[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?

[absc]

Amiga Unicorn

Vero, lo stesso vale per me come systems engineer.

I programmatori vanno picchiati, altrimenti non capiscono!

[amigaunicorn]

Cioccolataio Svizzerese no, non e’ che li odio. ma devono capire cose semplici, e cioe’ che da un ‘escalation si ottiene una decisione presa dall’autorita’ cui hai scalato.