Er formattering av kode subjektivt eller objektivt?

Programmering
#1

…og hvordan vet man forskjellen?

For eksempel kan man formattere kode til å være kompakt i høyden eller motsatt. Er den kompakt kan man se mer kode på en gang, men den er kanskje vanskeligere å lese. Kanskje det noen ganger er nyttig å se mer, men andre ganger ikke.

Et annet eksempel er om man skal ha standard formattering overalt eller ikke. Vi gjenkjenner mønstre, og ser fortere hva som er feil hvis det bryter mønsteret. Men samtidig kan standard formattering gjøre kode mindre leselig i enkelte tilfeller.

Hva er dine erfaringer? Hvordan bør man tenke for å finne den beste løsningen? Finnes det en objektivt bedre formattering?

1 Like
#2

Her var det vansklig å svare uten å skrive en bok med meninger. For min del er jeg åpen for det meste så lenge vi er enige om at prioriteringen “forståelig kode > alt annet” gjelder. Eventuelle unntak må begrunnes svært godt og pakkes inn i fantastisk beskrivende funksjonsnavn.

2 Likes
#3

Jeg tror dette er litt subjektivt, noe objektivt.

Det som er interresant, er at det er veldig forskjellig formattering fra språk til språk. Det gjelder kanskje i større grad andre konvensjoner og normer enn formattering, men til en viss grad formatering også. Ta Assembly for eksempel, der er det mye mer vanlig at indentering og spacing er mer slik at ting blir blokker, feks:

bilde
bilde588×558 24.6 KB

Så jeg tror det har litt med hva som faller seg naturlig i forhold til syntaksen også.

Det som blir subjektivt er jo om man ønsker { på ny linje eller ikke, om man indenterer med 2 eller 4 spaces (evt tab) osv. Men dette er jo ting som må støttes av syntax’en i språket. Noen språk er jo avhengig av indentering for parsing, og i noen språk kan man ikke ha linjeskift willy-nilly heller. Så det subjektive “rommet” i formmateringen er det som syntaxen tillater, mens det objektive er det som komplementerer syntaxen, kanskje? Her er det noe overlapp også, og det er vel der diskusjonene ofte blir? :stuck_out_tongue:

2 Likes
#4

Det tror jeg er en veldig god innstilling generelt. Forbausende nok er det ikke alle som er enig. Noen er mer opptatt av at å skrive koden skal være smertefri for dem. Personlig synes jeg det er et ikke-tema siden man alltid kan gå over å rydde etter at man har skrevet koden, men det er altså subjektivt.

Ja, godt poeng. Det danner seg en viss standard for et språk over tid. Jeg tror dette har litt med mønstergjenkjenning å gjøre som jeg nevnte, bare på et mye høyere nivå. Det er også som du sier syntax som bestemmer hvilket spillerom man har i valg av formattering, og det vil jo påvirke en del det og.

Her er du inne på en viktig ting synes jeg. Det er noe stort sett alle gjør i alle språk. Det å bruke formattering til å skille konsepter fra hverandre. Vi bruker feks indentering for å skille innsiden av en funksjon fra utsiden:

function(a){
if(a === 'foo'){
console.log('it's foo')
}else{
console.log('it's not foo')
}
}

Er det bare subjektivt at denne formatteringen er dårligere? Jeg tror ikke det. Det har med måten hjernen vår prosesserer informasjon på. Den gjør det i bolker. Hvis alt ligger på samme “nivå” i koden må man også lese alt som om det var på samme nivå. Hvis man skiller ting fra hverandre visuelt vil man kunne hoppe fra konsept til konsept uten å lese detaljene.

Noen flere eksempler:

tlf: 123 45 678
serienr: xxxx-xxxx-xxxx-xxxx
kidnr: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Her er det ikke konsepter som skilles engang, men helt tilfeldig valgte biter av tall eller tekst. Tror vi alle kan være enige om at det er en pain in the ass å lese kidnr, mens tlf og serienr er litt lettere. Det samme fenomenet er like gyldig i kode:

if(foo === 2 && /^\d+\w[a-d]*$/.test(bar) && baz[0]*4 !== 'faz' && ...)

På et eller annet tidspunkt begynner hjernen å slite med å skille ting fra hverandre. Korttidshukommelse er også et tema her tror jeg. Spørsmålet er kanskje når det blir for mye, og det er subjektivt. Det objektive hadde vært å målt dette på hele befolkningen av programmerere, og funnet ut hvor minst 90% av programmerere synes det var lett å lese (eller noe sånt).

Når det kommer til standardisering av formattering har jeg tenkt litt mer på det, og jeg tror det bunner ut i det jeg vil kalle rot. Hvis alt ser likt ut bruker ikke hjernen noe ekstra tid på å finne ut hvorfor noe ser annerledes ut. Det samme gjelder rot i form av unødvendige kommentarer, kommentert ut kode, osv. Vi bruker bittelitt tid og energi på alle disse tingene. Jeg lurer faktisk på om det er bedre med et komplett kaos enn bare litt rot her og der. Hvis det er kaos gir man kanskje bare opp :stuck_out_tongue:

Men debattene handler vel som oftest ikke om de åpenbare tinga som er nevnt her. Det er jo tabs og { som folk vil drepe for. Tabs tror jeg er et rent teknisk problem, så den er ikke så interessant imo. Curly braces har derimot noe med hvordan koden bolkes, samt størrelsen på koden, så her lurer jeg på om det kan være noe mer. Det samme gjelder bruk av whitespace i expressions, og mellom parenteser osv. Jeg tror nok at hvis det finnes noe objektivt bedre for hjernen her, så kan det ikke være store forskjellen. Men det er ikke dermed sagt at det ikke kan ha en påvirkning over tid, særlig i kombinasjon med andre problemer. Kanskje du blir litt mindre sliten i hodet hvis det er på den ene måten fremfor den andre.

Skulle gjerne likt å sett et studie av ulike kodebaser, og en spørreundersøkelse til de som jobber med kodebasen. Er det noen korrelasjon mellom bugs, glade/frustrerte utviklere, standard formattering, rot, hvor curly braces puttes, etc. Må google litt nå… :stuck_out_tongue:

1 Like
#5

Ja det er veldig godt poeng, det er jo helt individuelt hvor store “bolker” med kode man klarer å ha oversikt på om gangen. Et godt generelt tips man får overalt er jo nettop og skille ut mindre funksjoner, typisk “ikke mer enn 10 linjer kode pr funksjon”, det er vel kanskje en underbevist erfaring som er gjort om at folk ikke klarer å holde oversikt over mer enn 10 linjer om gangen. Nå er vi litt over i andre temaer innen vedlikeholbarhet av kode, men det smitter jo litt over i hvordan man formatterer også.
Personlig så synder jeg noenganger med veldig kompliserte boolean sjekker, som er veldig enkelt å skrive og lett for meg å holde oversikt over der og da, men som biter meg litt i rævva neste uke som jeg skal jobbe videre på det (heldighvis redder unit-tester meg her, som gjør at jeg kan refaktorere mens testene kjører for å forsikre meg om at ting fortsatt funker som forventet) :stuck_out_tongue:

En ting jeg har hørt en plass, som jeg ikke aner om er riktig, men som kanksje er en forklaring på forskjellige preferanser; mennesker tenker ofte på 1 av 3 måter: med mønster, språk eller visualisering, det sies at matematikere og musikere tenker mer i mønster, mens forfattere for eksempel tenker i språk. også har man de som har “fotografisk” hukommelse som oftere tenker visuelt.
Vet ikke helt hvordan det passer inn med utvikling, men jeg har sett på andre kollegaer at noen sliter med å oppdage detaljene i ting, for eksempel legger de ikke merke til at det er et mellomrom for mye her og der, eller ukonsistente linjeskift osv. Kanksje de er mer språklige? Selv føler jeg at jeg tenker mye i mønster, og jeg får litt spæder av sånne inkonsistente ting.

#6

Interessant, kanskje det er en kobling her. Når vi splitter ting ut i en funksjon får vi også muligheten til å skille det ut visuelt. Noen mener at kode som det bare er én instans av ikke burde skilles ut i en egen funksjon (WET, write everything twice/thrice). Har aldri vært spesielt fan av denne (og motparten DRY). En bedre tommelfingerregel er at det som skilles ut må ligge på ett, og bare ett, abstraksjonsnivå, og bare utgjøre “én ting” i dette nivået. Hvis funksjonen bare kalles opp én gang vil man fortsatt ha oppnådd noe fordi man har visuelt skilt ut denne tingen, og hjernen kan lese den som om den er én ting i kontekst av abstraksjonsnivået man ligger på. Altså: Det hele kommer tilbake til at vi bruker formattering til å visuelt skille ting fra hverandre, og funksjoner har en naturlig formattering som støtter opp under dette.

Prøvde å google denne, og kom bare til artikler som snakket om hvordan autister tenker :stuck_out_tongue: Men det er kanskje hold i det for andre også. I så fall er jeg også på mønstertenking tror jeg.

Jeg begynte å kikke etter studier på dette med formattering, men har ikke kommet spesielt langt foreløpig. Kom over denne artikkelen:

En liten oppsummering:

  • Felles eksisterende forståelse av språk, domene, teknikker, biblioteker, etc, er viktig for forståelse av kode (Litt artig å tenke på javascript. Der er det nesten ingen felles forståelse av biblioteker, og man har knapt et standard bibliotek)
  • Det tar mer tid å lese mer kode, selv når koden er lengre fordi den er forenklet (for-loops vs list comprehension etc). Han nevner at i en annen studie fant de ikke noen forskjell i forståelse av kode som tok mer tid å lese. Det tok bare mer tid.
    Ifølge forfatteren er dette et tegn på at kortere kode (målt i tokens, ikke whitespace) er bedre, men resultatet kan ikke generaliseres.

Ikke direkte relatert til formattering av kode, men kanskje noen hint i retning av at høy informasjonstetthet gjør at man bruker kortere tid på å lese koden. Skal poste her ettersom jeg får lest flere studier som kanskje er mer relevant.

1 Like
#7

Da snakker vi altså at bårde variablenavnet xs og carEngines teller 1? Lurer på om det kan dras noen paralleller til vanlig språk her. Når jeg skriver så jobber jeg ofte med å fatte meg i korthet. Altså ved å være mer presis kan jeg få frem de samme nøyansene med færre ord. For eksempel ved bruk av domene spesifike ord, som bærer en spesiell mening i et gitt domene. Det stiller da selvsagt noen krav til den som skal lese det jeg skriver mtp. at vi deler felles foretåsele av disse ordene. Og her kan man kanskje prøve å lure inn litt objektivitet:
1. doubleValueList = singleValueList.map(x => x*x)
2. doubleValueList = []
for (number in singleList){
doubleValueList.push(number*number) //Får ikke til indent her^^
}
Det går kanskje ann å si at number 1 er objektivt bedre enn number 2, gitt at den som leser koden forstår hvordan map funksjonen fungerer. Så kan man alltids stille spørsmål ved hva det må være lov å forvente. Når det er sagt er ofte det aller viktigste for meg at variablene har beskrivende navn. Vet jeg tilstanden på veien inn og får en god beskrivelse av tildstanden på veien ut er mye gjort.

#8

Jepp!

Nettopp! De kaller det for “common ground” i litteraturen høres det ut som.

Ja, det var basically konklusjonen til studien. Hva det er lov å forvente er et veldig interessant tema i seg selv. Det virker som ekstremt mange mener at man knapt skal forvente noe som helst, og at man bør skrive kode med så få antakelser om common grounds som mulig. Bra tema for en annen topic det der.

Helt enig, men i artikkelen kunne han faktisk ikke konkludere med at det hadde noe å si (det han kaller grounding hints), men han sier også at det var en svakhet i studien. Det var bare 12 deltakere og noen små kodesnutter, så man må vel ta det med en klype salt.

1 Like
#9

Ganske interessant gjennomgang her: https://optimal-codestyle.github.io/

1 Like