DApp Store | Piattaforma Web3 per eventi e giochi

Sono assolutamente d'accordo, e penso che gli strumenti LLM potrebbero essere un fattore determinante per adottare alcune delle pratiche dei migliori team/organizzazioni anche nei team più piccoli che prima potrebbero non essere stati in grado di giustificarle.

Penso che saresti pazzo ad avere diverse centinaia di ingegneri senza un linter. Se hai solo due o quattro persone, tuttavia, forse non raggiungerai mai l'energia di attivazione per questo, e avrai per lo più discussioni improduttive sullo stile di codifica. Ma aggiungi Claude Code e a) vuoi quel linter

b) impostare quel linter richiede ora cinque minuti di sforzo marginale rispetto a "Una persona scende in un classico compito di tarpit per integrarlo con tutti gli IDE/ecc."

Per la parte del mio pubblico che non lo sa: un linter è uno strumento automatizzato che può imporre standard di convenzione di codifica più rigorosi rispetto a quelli che un linguaggio potrebbe consentire. Ad esempio, puoi adottare una regola interna secondo cui determinate costruzioni legali non sono consentite

Come esempio, c'è un'espressione legale molto concisa in molte lingue chiamata operatore ternario. Gli operatori ternari sono notoriamente suscettibili di causare bug, e un team di ingegneria potrebbe decidere che, sebbene concisi, su base aggiustata per il rischio non sono una caratteristica accettabile da utilizzare.

Come esempio di una cosa che puoi regolare in modo sensato tramite un linter e di cui non vuoi dover discutere ripetutamente con Claude Code: in Rails, something_id significa una chiave esterna per la tabella something. Claude dimentica questo occasionalmente, chiamando molti altri elementi id.

Puoi, se vuoi, scrivere una regola di linter che verrà eseguita ogni volta che il codice viene modificato e segnalerà a Claude e al resto del mondo: “Hai chiamato una variabile box_id, ma _ids devono essere usati solo per riferirsi alle chiavi del database. Considera box_code o un altro nome.”

Una cosa bella delle regole del linter è che possono avere conoscenze specifiche del progetto incorporate in modo arbitrario. Un argomento ripetuto che un salaryman giapponese è stato costretto a discutere molto tempo fa, con (altri) parlanti non nativi che stavano realizzando un'applicazione web universitaria: NON DOVETE usare "subject."

Perché no? Perché le università giapponesi dividono le materie accademiche in 教科 (kyouka; una materia come "matematica") e 科目 (kamoku; una materia come "algebra lineare"), e poiché il termine subsubject è terribile da leggere nel codice, questi venivano indicati con il giapponese romanizzato per essere sempre inequivocabili.