Ta for eksempel Erlang: Der er det vanlig å begynne kommentar-linjer med %%. Erlang-spekken sier man bare skal bruke én %, men fordi den som lagde Emacs-pluginen for Erlang valgte å bruke to stykker har det blitt praksis for alle. I dag skriver folk %% selv om de for eksempel bruker Vim, uten å ane hvorfor.

Når det gjelder kodekonvensjoner som antall tegn for å representere innrykk så bør det alltid være opp til den enkelte, eller det enkelte teamet om vi snakker om prosjekter/open source. Det finnes for eksempel mange som har problemer med å se innrykk på bare 2 tegn.

Dessuten må vi huske på at vi har endel mer skjermplass tilgjengelig i dag som vi kan utnytte enn man hadde for noen år siden, og at mange konvensjoner ble skapt mens man hadde 10 linjer og noen-og-70 kolonner (eller noe sånn) på en skjerm. Større innrykk er nok bare en vanesak (men mine Vim-instillinger er på 2 tegn de også).

M.t.p. “én riktig måte å gjøre ting på” mener jeg spesielt ting relatert til bruk av Tab(#2) og intenderingen i sammenheng med DEFUN / WHILE; altså &BODY. Det er kanskje _noe_ variasjon m.t.p. antall mellomrom(#3), men første argument er alltid skjøvet noe til venstre og _ikke_ rett under første argument til f.eks. DEFUN — dette slik at videre kode ikke tilslutt ender opp for langt til høyere på skjermen ettersom en nester flere ting noe som er lett (og morsomt!) å gjøre i Lisp siden mer eller mindre alt kan returnere verdier! :)

Happy hackin’!

#1: ..noe som forøvrig er uavhengig av editor. :)

#2: ..aner ikke om VIM setter in Tab av seg selv eller hva.

#3: ..men uten å undersøke så fryktelig nøye bruker all Lisp-kode jeg kommer på sånn i farta 2 mellomrom her.

Du sier at det kun er én riktig måte å indentere på i Lisp. Om du ikke kan referere til noe i Lisp-spesifikasjonen som sier noe annet vil jeg hevde at det ikke finnes noen regler for hvordan Lisp skal indenteres! Det finnes derimot praksiser, og som regel skyldes disse praksisene hvordan editoren som brukes mest (emacs) oppfører seg. Det du sier er verdifull input, men sålenge jeg bruker Vim vil jeg nok stort sett være fornøyd med hvordan den bestemmer at Lisp’en min skal se ut.

Din bruk av linjeskift er finere enn min; jeg gjorde det som jeg gjorde for å illustrere, og bryter normalt opp noe anderledes. Jeg føler derimot ikke at jeg følger noen regler, men gjør det som resulterer i mest mulig lesbar kode.

For ordens skyld: Jeg bruker “Lisp” indenteringsregler, jeg har ikke installert de Clojure-spesifike reglene/syntaksdefinisjonene. Dette er nok for eksempel årsaken til at funksjonene mine ikke har riktig indentering, siden Vim ikke skjenner til defn (men bare defun).

Jeg stusser dog litt over at Vim indenterer ‘if’ slik som du sier ‘while’ skal indenteres, og ‘while’ slik du sier ‘if’ skal indenteres. :|

http://static.nostdal.org/~lnostdal/always-here/lisp-for-dummies.png

Det kan forøvrig hende at det er vanlig med en _noe_ annerledes stil i sammenheng med Clojure, men dette skal være riktig i sammenheng med Scheme og CL ihvertfall.

Hvorvidt ting følger på en vertikal rett linje nedover slik som i eksempelet med (multiply …) eller om første argument på egen linje “trekkes inn” slik som i sammenheng med (defun …) baserer seg gjerne på bruk av &BODY. F.eks. brukes &BODY i DEFUN og i (brukerdefinerte) macroer some f.eks. WHILE o.l..

En ser at i sammenheng med IF brukes ikke &BODY derfor er argumentet på første nye linje ikke “trukket inn”, men følger på en vertikal rett linje nedover slik som i eksempelet med (multiply …).

Slike ting tar Emacs+Slime seg av automatisk; om en definerer en ny macro med eller uten bruk av &BODY vil Emacs+Slime holde styr på dette og indentere riktig alt-ettersom.

PS: Hadde egentlig tenkt å maile deg, men fant ikke noen e-postaddresse.

Emacs+Slime indenterer forøvrig CL-kode riktig; litt krongel å sette opp, men av flere årsaker enn m.t.p. dette med indentering verdt det om en først skal bruke Lisp.

Lykke til med PCL; det er en fin og morsom bok. :)

Du kan forresten gjøre det så enkelt som (define (7teen f x) ((eval f) x 17)) i det andre eksemplet ditt.