mboost-dp1
Version2 bekender kulør
Jo, men XAML bindings kan godt blive pænt nasty ;-)Benjamin Krogh (150) skrev:Har alle seriøse editors ikke en auto-indent funktion?
Derudover bruger jeg bare "Format Code" når jeg er færdig med en rettelse. Så tilpasses koden til max 130 char i længden (xaml), eller 100 (C#, Java, etc.), alle spaces/tabs fixes automatisk, og koden tilpasses den gældende code-convention.
<3 IDEs.
fidomuh (149) skrev:Nu har jeg lige rodet rundt i vim, og umiddelbart kan jeg ikke se problemet med "hardtabs".
Lad os sige at tabs er sat ved 4,7,10,13,16,19,21.
Las os bruge tab meget konsekvent.
\tfoobar\t=\trecord
foobar starter i position 4
= starter i position 13
record starter i position 16
\t\t\t\t\tend
end start i position 16
Perfekt.
Nu skifter vi tabs til 5,9,13,17,21,25,29
\tfoobar\t=\trecord
foobar starter i position 5
= starter i position 13
record starter i position 17
\t\t\t\t\tend
end start i position 21
Resultat: end står ikke under record som det skal.
Det grundliggende problem med det som jeg kalder "kolonner" er at der er en antagelse om at et antal tabs svarer til længden af noget tekst i den foregående kolonne og at længden af den tekst ikke ændrer sig når man ændrer betydningen af tabs.
Windcape (155) skrev:Derudover bruger jeg bare "Format Code" når jeg er færdig med en rettelse. Så tilpasses koden til max 130 char i længden (xaml), eller 100 (C#, Java, etc.), alle spaces/tabs fixes automatisk, og koden tilpasses den gældende code-convention.
Læste du:
Benjamin Krogh (150) skrev:Ud over en lidt sjov log i ens versionsstyringssystem burde det vel være rimeligt tilforladeligt. :)
?
Det er ikke bare "en lidt sjov log" - det er et mega problem at man ikke kan se hvad der reelt er ændret!
#159
Alternativet er at bruge en pretty printer på al kode, så det altid er formateret på præcis samme måde i SCM systemet.
diff -w?
Alternativet er at bruge en pretty printer på al kode, så det altid er formateret på præcis samme måde i SCM systemet.
#157
"Why bother doing it right" ?
Den tror jeg bare vi lader staa helt for sig selv :D
#arne_v
Que?
Que?
Men eh, det problem du beskriver skyldes vel mere at man bruger random tabspace og ikke fixed til 4, fx?
Saa hvis nu jeg retter min tab-space til 7-11-47-48-49-55, saa kommer det ogsaa til at se fucked ud.
Tab indention boer *altid* vaere baseret paa et fast antal chars, det er saadan det fungerer per default i vim, og enhver anden editor jeg nogensinde har brugt.
Jeg har ioevrigt lige konverteret alle mine space-tabs til \t-tabs og der var ingen problemer. Ej heller med at importere fra andre sources.
Saa jeg ser ikke det problem du proever at illustrere :)
"Why bother doing it right" ?
Den tror jeg bare vi lader staa helt for sig selv :D
#arne_v
Det grundliggende problem med det som jeg kalder "kolonner" er at der er en antagelse om at et antal tabs svarer til længden af noget tekst i den foregående kolonne
Que?
og at længden af den tekst ikke ændrer sig når man ændrer betydningen af tabs.
Que?
Men eh, det problem du beskriver skyldes vel mere at man bruger random tabspace og ikke fixed til 4, fx?
Saa hvis nu jeg retter min tab-space til 7-11-47-48-49-55, saa kommer det ogsaa til at se fucked ud.
Tab indention boer *altid* vaere baseret paa et fast antal chars, det er saadan det fungerer per default i vim, og enhver anden editor jeg nogensinde har brugt.
Jeg har ioevrigt lige konverteret alle mine space-tabs til \t-tabs og der var ingen problemer. Ej heller med at importere fra andre sources.
Saa jeg ser ikke det problem du proever at illustrere :)
#161
Jo, men så er sitiationen jo:
spaces - virker for alle
tabs - virker kun for dem som har den rigtige tab opsætning
så er spaces jo bedre end tabs.
Pointen i hele eksemplet er at det klassiske argument for tabs, nemlig at det tillader brugerne at have forskellig indrykning, ikke holder vand ved kode som er kolonne orienteret.
Jo, men så er sitiationen jo:
spaces - virker for alle
tabs - virker kun for dem som har den rigtige tab opsætning
så er spaces jo bedre end tabs.
Pointen i hele eksemplet er at det klassiske argument for tabs, nemlig at det tillader brugerne at have forskellig indrykning, ikke holder vand ved kode som er kolonne orienteret.
#163
Tjoh, det virker *daarligere* for alle, men for alle ja.
Essentielt har alle den rigtige opsaetning.
Der er ingen grund til at bruge en random() paa sine tabs...
Da tabs understoettes i 99% af alle editors og som default har et fint setup, saa er det sgu nok ganske fint for 'alle' :)
Det er da heller ikke det 'klassiske' argument?
\t er langt nemmere at navigere og holder styr paa.
Forskellig indrykning er, imo, bare underligt.
Uniform kode? Yessir :D
Jo, men så er sitiationen jo:
spaces - virker for alle
Tjoh, det virker *daarligere* for alle, men for alle ja.
tabs - virker kun for dem som har den rigtige tab opsætning
Essentielt har alle den rigtige opsaetning.
Der er ingen grund til at bruge en random() paa sine tabs...
så er spaces jo bedre end tabs.
Da tabs understoettes i 99% af alle editors og som default har et fint setup, saa er det sgu nok ganske fint for 'alle' :)
Pointen i hele eksemplet er at det klassiske argument for tabs, nemlig at det tillader brugerne at have forskellig indrykning, ikke holder vand ved kode som er kolonne orienteret.
Det er da heller ikke det 'klassiske' argument?
\t er langt nemmere at navigere og holder styr paa.
Forskellig indrykning er, imo, bare underligt.
Uniform kode? Yessir :D
#164
forestil dig et programmeringssprog der ser således ud:
Altså hvor næste linie skal komme ud fra enden af teksten fra forrige linie. Ja, prøv at kigge på hvordan man indenterer lisp. Det er et ganske udmærket eksempel hvor tabs ikke holder (medmindre tabs=1, måske). Man kunne måske indentere ovenstående med tabs, men så når du kommer over på en anden editor, ser det helt forfærdeligt ud med 8 spaces!
[url=http://www.labri.fr/perso/strandh/Teaching/MTP/Common/Strandh-Tutorial/indentation.html]se især if-sætningerne[url]
forestil dig et programmeringssprog der ser således ud:
if this
__do
____this
____that
__done
else
____do
______this
______that
____done
Altså hvor næste linie skal komme ud fra enden af teksten fra forrige linie. Ja, prøv at kigge på hvordan man indenterer lisp. Det er et ganske udmærket eksempel hvor tabs ikke holder (medmindre tabs=1, måske). Man kunne måske indentere ovenstående med tabs, men så når du kommer over på en anden editor, ser det helt forfærdeligt ud med 8 spaces!
[url=http://www.labri.fr/perso/strandh/Teaching/MTP/Common/Strandh-Tutorial/indentation.html]se især if-sætningerne[url]
Jeg får for tiden noget lisp-kode af og til. Der kan man ikke bruge tabs-only. Jeg får desværre nogle gange noget med tabs i, og det er træls at skulle ændre sine indstillinger lokalt hver gang de bruger mixed. Jeg tror det skyldes at det er standardindstillingen i emacs, desværre.
Emacs is evil! :-)
Emacs is evil! :-)
#167
Nu har jeg aldrig selv haft den tvivlsomme ære at arbejde med LISP kode... men for satan:
... hvad sker der for brugen af parenteser? De må have været på noget af det samme som Bjarne Stroustrup var da han designede C++.
Nu har jeg aldrig selv haft den tvivlsomme ære at arbejde med LISP kode... men for satan:
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
... hvad sker der for brugen af parenteser? De må have været på noget af det samme som Bjarne Stroustrup var da han designede C++.
#167 / #168
http://xkcd.com/224/
http://xkcd.com/297/
Vi(m) ftw.
http://xkcd.com/224/
http://xkcd.com/297/
Damn right!onetreehell (167) skrev:Emacs is evil! :-)
Vi(m) ftw.
Det er ikke så slemt når man lærer at læse det efter indenteringen :) (igen, det er derfor det er vigtigt at det er ordentligt indenteret!!)
fidomuh (164) skrev:
Essentielt har alle den rigtige opsaetning.
Der er ingen grund til at bruge en random() paa sine tabs...
Erfaringsmæssigt er der altid nogen med forskellige tab opsætninger, når man involverer en større gruppe af udviklere med forskellige værktøjer.
fidomuh (164) skrev:
Det er da heller ikke det 'klassiske' argument?
Jo. Det er det argument der normalt bruges.
fidomuh (164) skrev:
\t er langt nemmere at navigere og holder styr paa.
Øh. Hvis editoren er bare middelmådig god, så er det komplet transparent om der gemmes med tab eller spaces.
Windcape (166) skrev:Men hvis alle følger code-conventions, så burde der ikke være formatteringsændringer som en stor del af versionstyringsændring.
Hvis alle følger konventionen absolut perfekt, så ville #155 aldrig være nødvendig.
Men går man ned i de de tilpas små detaljer, så er der næsten altid noget.
(int)v
vs
(int) v
er en af dem som jeg selv skriver forkert (i forhold til Java konvention) stort set altid.
Altså der er jo ingen der siger du skal følge den mens du koder, jeg mente bare ingen man laver commits.arne_v (174) skrev:Hvis alle følger konventionen absolut perfekt, så ville #155 aldrig være nødvendig.
"format code" før commits er en god løsning synes jeg. Specielt fordi det fixer tabs og ekstra unødvendigt whitespace.
Vi(m) og Emacs er stilarter for editors i dag.markjensen (170) skrev:Seriøst? Det troede jeg aldrig jeg skulle se dig sige (skrive)
Jeg kunne aldrig finde på at bruge dem begge to direkte. Men koncepterne overført til moderne editors / IDEs er rigtig gode.
Windcape (175) skrev:
Altså der er jo ingen der siger du skal følge den mens du koder, jeg mente bare ingen man laver commits.
"format code" før commits er en god løsning synes jeg. Specielt fordi det fixer tabs og ekstra unødvendigt whitespace.
Hvis alle gør det så er det OK.
Men hvis der er "dissidenter", så bliver det kaos.
Et check tool der finder overtrædelser, en format og en commit med kommentar "code convention" er bedre i et ikke-super team.
#173
"The bat of confirmity hits you for +10 damage" ? :)
Well, det argument har jeg ikke set foer, men givet, saa er jeg heller ikke en 'super coder', jeg har heller ikke nogen ide om hvorfor forskellige tab indents skulle vaere andet end stupidt :)
Tjoh, det er nok bare mig der godt kan lide at se hvad der reelt staar i filen, fremfor noget der er formateret.
Her snakker jeg saa ikke om \t, men om at min editor behandler spaces som spaces og tabs som tabs.
Ligesom at line-wrapping heller ikke er noget jeg bruger, da jeg gerne vil kunne se hvor mine \n ligger.
Erfaringsmæssigt er der altid nogen med forskellige tab opsætninger, når man involverer en større gruppe af udviklere med forskellige værktøjer.
"The bat of confirmity hits you for +10 damage" ? :)
Jo. Det er det argument der normalt bruges.
Well, det argument har jeg ikke set foer, men givet, saa er jeg heller ikke en 'super coder', jeg har heller ikke nogen ide om hvorfor forskellige tab indents skulle vaere andet end stupidt :)
Øh. Hvis editoren er bare middelmådig god, så er det komplet transparent om der gemmes med tab eller spaces.
Tjoh, det er nok bare mig der godt kan lide at se hvad der reelt staar i filen, fremfor noget der er formateret.
Her snakker jeg saa ikke om \t, men om at min editor behandler spaces som spaces og tabs som tabs.
Ligesom at line-wrapping heller ikke er noget jeg bruger, da jeg gerne vil kunne se hvor mine \n ligger.
fidomuh (178) skrev:
Tjoh, det er nok bare mig der godt kan lide at se hvad der reelt staar i filen, fremfor noget der er formateret.
Her snakker jeg saa ikke om \t, men om at min editor behandler spaces som spaces og tabs som tabs.
Ligesom at line-wrapping heller ikke er noget jeg bruger, da jeg gerne vil kunne se hvor mine \n ligger.
Står der
:set listi din .vimrc fil? :D
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund