Når jeg var data science lead og mitt team for det meste skrev Python, brukte vi https://peps.python.org/pep-0008/ som utgangspunkt til en felles standard. Jeg oppdaget nylig https://guide.clojure.style/ som ser ganske fin ut.

Men så er det mye som ikke er ren syntaks også, mer semantiske ting. Særlig i Clojure.

Første tredjedelen av den Clojuregreia er lintermat 🙂

Jepp. Alt som kan gjøres automatisk bør gjøres automatisk IMO.

Kanskje man burde hatt en chatgtp linter?

En sånn som forsto mer av koden

Det er ikke noe dum idè @U04V5VAUN. Har hatt samme tanke selv, gi et eksempel på guidelines som instruksjon, også ha en modell går igjennnom fil for fil.

Skulle gjerne hatt en som drop in replacement for oppgradering script også. At man istedenfor å skrive et script som oppdaterte syntax som er forandret fra v2 til v3 i et js lib, for eksempel bare ga litt eksempler på hva som skal byttes, og hvordan, også kunne verktøyet gått igjennom hele kodebasen og gjort forandringen. Det er generelt muligheter for bedre "gardening" av store kodebaser nå i 2024 med automatisering.

Yeah! Jeg har også fundert på det samme, enten en real-time ChatGPT linter som kjører i bakgrunnen og gir feedback i editoren, eller en "offline" ChatGPT linter som kjører "offline" via build systemet og foreslår endringer på en annen måte.

(støtter at man bruker lintere for det lintere kan gi, altså)

et annet mulig tiltak er å innføre mer parprogramering og mer ensemble-programmering for å få snakket om hvordan man skal kode.

Jeg liker at bilen har bakspeil, sidespeil og andre instrumenter som forteller meg hva som skjer inne i bilen og rundt meg, i tillegg til skrikende pasasjerer når jeg sovner og glir over i motsatt kjørebane.

Fint med lintere, men jeg kjenner at jeg er lykkelig av å ha organisert meg ut av behovet for å ha masse skriftlig regelverk for hvordan koden skal se ut.

Helt enig med @U3X7174KS: bruk samarbeid til å samkjøre folks stil via osmose.

Sier han som står på scena og forkynner hvordan man skal kode frontend 🙂

Haha!

Ett problem med regler och processer är att de oftast överlever problemen de är avsedda att lösa.

Jeg er ikke imot å nedfelle noen gode praksiser. Men jeg ville ikke valgt foredrag som formidlingsform til folk på teamet mitt 😅

Jepp. Et annet er at folk blir passive og mister eierskap dersom det er for mye av det: “Jammen, du sa jo at vi aldri skulle skrive anonyme funksjoner”

@U07FCNURX Tøysete kommentar om @U9MKYDN4Q’s JZ foredrag fra i fjor 🙂

Greit nok at den er tøysete, men jeg skjønte ikke sammenhengen 😅