mboost-dp1
Microsoft Corporation
VB.Net er ellers udemærket til fx at skrive små hurtige plugins til fx outlook o.l.
Og da office også findespå andet end Windows, så skulle man mene man kunne have glæde af VB.Net til at skrive plugins til office på tværs af platforme.
Med den antagelse at office på andre platforme også kan bruge plugins.
Og da office også findespå andet end Windows, så skulle man mene man kunne have glæde af VB.Net til at skrive plugins til office på tværs af platforme.
Med den antagelse at office på andre platforme også kan bruge plugins.
Jeg udvikler kun i VB.NET og har været med siden VB4.
Jeg synes VB har virkelig mange gode kvaliteter - både syntaxmæssige men også VS's IDE i VB er rigtig tiltalende - fx kan jeg ikke undvære den tværgående linje når en metode eller funktion afsluttes.
Samtidig er jeg også stor tilhænger af at operationer som fx If eller For sluttes ned End If eller Next i forhold til at alt sluttes med en }. For mig er 30 } i træk virkelig uoverskueligt hvis jeg skal have mast noget kode ind i mellem.
Samtidig har jeg i årenes løb set at der er ting som VB kan og som C# ikke kan - og omvendt. Det har været frustrerende. Det samt Microframeworket i VB ikke har været super med deciderede bug har gjort at jeg efterhånden føler mig presset over på C# selvom jeg ikke kan li syntaxen eller IDE'et.
Det var rimelig klart fra starten af at C# ville vinde kampen - VB har kun sig selv mens C# er en udløber af C og Java i mix og appellerer til et langt bredere publikum. Mange har en dårlig opfattelse af VB og kalder sproget for et begyndersprog. Det er helt korrekt at det er nemt at gå til fordi kommandoer oftest nærmest kan læses som engelsk, men samtidig er VB lige så stærkt som de andre i .NET-pakken og det har været mit argument når folk har grint (og ja jeg har mødt mange der har grint af mig). Jeg synes det er synd at VB er ved at blive kørt ud på et sidespor. Jeg holder virkelig meget af sproget og det skaber så meget mere overblik i mit hoved end hvis det er C#-kode man serverer for mig. Jeg kan nemt læse C# men VB har nu altid været det jeg uden problemer har kunnet forstå hurtigst.
Jeg beklager Microsofts holdning.
Jeg synes VB har virkelig mange gode kvaliteter - både syntaxmæssige men også VS's IDE i VB er rigtig tiltalende - fx kan jeg ikke undvære den tværgående linje når en metode eller funktion afsluttes.
Samtidig er jeg også stor tilhænger af at operationer som fx If eller For sluttes ned End If eller Next i forhold til at alt sluttes med en }. For mig er 30 } i træk virkelig uoverskueligt hvis jeg skal have mast noget kode ind i mellem.
Samtidig har jeg i årenes løb set at der er ting som VB kan og som C# ikke kan - og omvendt. Det har været frustrerende. Det samt Microframeworket i VB ikke har været super med deciderede bug har gjort at jeg efterhånden føler mig presset over på C# selvom jeg ikke kan li syntaxen eller IDE'et.
Det var rimelig klart fra starten af at C# ville vinde kampen - VB har kun sig selv mens C# er en udløber af C og Java i mix og appellerer til et langt bredere publikum. Mange har en dårlig opfattelse af VB og kalder sproget for et begyndersprog. Det er helt korrekt at det er nemt at gå til fordi kommandoer oftest nærmest kan læses som engelsk, men samtidig er VB lige så stærkt som de andre i .NET-pakken og det har været mit argument når folk har grint (og ja jeg har mødt mange der har grint af mig). Jeg synes det er synd at VB er ved at blive kørt ud på et sidespor. Jeg holder virkelig meget af sproget og det skaber så meget mere overblik i mit hoved end hvis det er C#-kode man serverer for mig. Jeg kan nemt læse C# men VB har nu altid været det jeg uden problemer har kunnet forstå hurtigst.
Jeg beklager Microsofts holdning.
Tjaeh curly brace syntax sprog er hot for tiden. Det er hvad man kunne forvente. 3rd party supporten for VB (f.eks. resharper, stylecop og den slags ting) er allerede mangelfuld nu i forhold til C#, så det har længe peget i den her retning.
Personligt gør det mig ikke den helt store forskel om man taler med .NET gennem VB eller C#. Det er bare syntax.
Personligt gør det mig ikke den helt store forskel om man taler med .NET gennem VB eller C#. Det er bare syntax.
...kommentarsporet på blogopslaget lader da også til at gøre Microsofts argumenter pænt til skamme...
Der er nok mere politik bag beslutningen end der er egentlig fakta. Jeg føler lidt at Microsoft råber pik og så bare løber væk. Så kan vi andre stå tilbage og kaste argumenter ud i luften der nemt fungerer som modsvar. De bliver aldrig hørt eller læst af Microsoft for Microsoft er allerede fast besluttet og er faktisk ligeglad med andres holdninger. De skal bare have lukket sagen.
*suk*
Der er nok mere politik bag beslutningen end der er egentlig fakta. Jeg føler lidt at Microsoft råber pik og så bare løber væk. Så kan vi andre stå tilbage og kaste argumenter ud i luften der nemt fungerer som modsvar. De bliver aldrig hørt eller læst af Microsoft for Microsoft er allerede fast besluttet og er faktisk ligeglad med andres holdninger. De skal bare have lukket sagen.
*suk*
knasknaz (5) skrev:3rd party supporten for VB (f.eks. resharper, stylecop og den slags ting) er allerede mangelfuld nu i forhold til C#, så det har længe peget i den her retning.
Men ReSharper har aldrig kunnet tilbyde noget til VB som jeg ihvertfald har kunnet bruge. Den IDE og IntelliSense der blev shipped med VB er fantastisk.
Jo okay - ReSharper har kunnet lave For-løkker om til LINQ osv. men det er så også det eneste jeg har kunnet bruge fra ReSharper.
#4: Hvis du laver 30 } i træk, gør du det forkert. Du skal ikke have så dyb nesting. Indentering hjælper dig med at finde ud af scopet, og methoder bør ikke være længere end at du kan se dem uden at scrolle.
Tror mest af alt det er et spørgsmål om at du har brugt det andet længere. Præcis ligesom alle hader If..End If hvis du kommer fra tuborglandet.
Kom over på den mørke side. Livet er lysere, og ændringen er ikke særligt stor når man kommer fra et .NET sprog.
#7: Eftersom Microsoft implementerer de mest nyttige features fra Resharper, er det ikke helt så nyttigt nu som det var i VS2010. Men CTRL+T i R# er stadig bedre end CTRL+ i VS. Derudover er der en del refaktoreringsfeatures, der er super nice. Det er stort set bare trykke Alt+Enter, så rydder den op.
Tror mest af alt det er et spørgsmål om at du har brugt det andet længere. Præcis ligesom alle hader If..End If hvis du kommer fra tuborglandet.
Kom over på den mørke side. Livet er lysere, og ændringen er ikke særligt stor når man kommer fra et .NET sprog.
#7: Eftersom Microsoft implementerer de mest nyttige features fra Resharper, er det ikke helt så nyttigt nu som det var i VS2010. Men CTRL+T i R# er stadig bedre end CTRL+ i VS. Derudover er der en del refaktoreringsfeatures, der er super nice. Det er stort set bare trykke Alt+Enter, så rydder den op.
Hvis metoder bliver så lange skal man til at refaktorere. Mere end tre niveauer indrykning er for meget.Chucara (8) skrev:methoder bør ikke være længere end at du kan se dem uden at scrolle.
Chucara (8) skrev:Hvis du laver 30 } i træk, gør du det forkert. Du skal ikke have så dyb nesting
Nu var det også mest en overdrivelse-fremmer-forståelsen-pointe.
Chucara (8) skrev:Tror mest af alt det er et spørgsmål om at du har brugt det andet længere. Præcis ligesom alle hader If..End If hvis du kommer fra tuborglandet.
Kom over på den mørke side. Livet er lysere, og ændringen er ikke særligt stor når man kommer fra et .NET sprog.
Læser du ikke hvad jeg skriver?
Jeg skriver at jeg bedst kan li' End If, End Sub, End Function osv. Det er jo netop det der er min pointe og (bla) det der har holdt mig tilbage. Det skaber bedre overblik for mig. Det sammen med IDE'ens fantastiske linje til at brække af når en funktion/sub afsluttes. VB's IDE/IntelliSense er genial - der er så mange fede ting ved den som jeg ikke kan leve uden. Godt nok har de fjernet en væsentlig del som fx auto-case under skrivning - nu sker det først når du trykker Enter og er på næste linje (totalt retardo-nedgradering). Der er mange logikker i VB og dens IntelliSense som giver meget mere mening for mig end hos C# og du kan ikke bare overbevise mig med at 'øøøøh vi andre synes det er noget lort'.
Edit: citat-fåk-åp.
#9: Øhh ja. Det er det, jeg skriver.
#10: Læser du, hvad jeg skriver? :D Jeg skriver jo netop ikke at 'det er noget lort'. Jeg skriver, at dem, der koder C# synes VB's syntax er tåbelig og at dem, der koder VB, bedre kan lide denne end tuborgerne fra C#/Java.
Ikke at den ene nødvendigvis er bedre end den andet - blot at det er et spørgsmål om tilvænning.
PHP udviklere synes også at $ foran alle variable er en god ting. Men det ved alle vi .NET folk jo er forkert, ikke? ;)
Hvis det kan trøste dig, har de også smadret intellisense lidt for C# med seneste update. Så på det punkt, er de fair :D
#10: Læser du, hvad jeg skriver? :D Jeg skriver jo netop ikke at 'det er noget lort'. Jeg skriver, at dem, der koder C# synes VB's syntax er tåbelig og at dem, der koder VB, bedre kan lide denne end tuborgerne fra C#/Java.
Ikke at den ene nødvendigvis er bedre end den andet - blot at det er et spørgsmål om tilvænning.
PHP udviklere synes også at $ foran alle variable er en god ting. Men det ved alle vi .NET folk jo er forkert, ikke? ;)
Hvis det kan trøste dig, har de også smadret intellisense lidt for C# med seneste update. Så på det punkt, er de fair :D
Kian (4) skrev:Samtidig er jeg også stor tilhænger af at operationer som fx If eller For sluttes ned End If eller Next i forhold til at alt sluttes med en }.
Det er også min mening. Men moden i disse år er anderledes.
Kian (4) skrev:Mange har en dårlig opfattelse af VB og kalder sproget for et begyndersprog.
Så stor forskel er der heller ikke på VB.NET og C#.
Men det er vel rimeligt at antage at ved .NET fremkomsten gik det:
VB6 udviklere -> VB.NET udviklere
VC++ udviklere -> C# udviklere
Og VC++ udviklere som har siddet og rodet med COM og ATL i C++ var altså noget bedre (gennemsnitligt set) end dem som havde siddet og lavet UI i VB6.
Og VB.NET arvede vel ry fra de mindre skrappe VB.NET udviklere.
Kian (6) skrev:...kommentarsporet på blogopslaget lader da også til at gøre Microsofts argumenter pænt til skamme...
Der er nok mere politik bag beslutningen end der er egentlig fakta.
Det er vel fakta at interessen for VB.NET fra diverse *nix og open source grupper (Mono, Xamarin etc.) er meget lav.
Chucara (8) skrev:Hvis du laver 30 } i træk, gør du det forkert. Du skal ikke have så dyb nesting. Indentering hjælper dig med at finde ud af scopet,
Jeg er enig i det.
Og det er der mange andre som er.
Linus Torvalds skrev følgende om Linux Kernel coding style:
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic
movements that try to make indentations 4 (or even 2!) characters deep, and that is akin
to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of
control starts and ends. Especially when you've been looking at your screen for 20
straight hours, you'll find it a lot easier to see how the indentation works if you have
large indentations.
Now, some people will claim that having 8-character indentations makes the code move
too far to the right, and makes it hard to read on a 80-character terminal screen. The
answer to that is that if you need more than 3 levels of indentation, you're screwed
anyway, and should fix your program.
In short, 8-char indents make things easier to read, and have the added benefit of
warning you when you're nesting your functions too deep. Heed that warning.
Men men men.
Efter min mening er det bedre hvis et sprogs syntax fungerer både med god og dårlig kode stil end at den kun fungerer med god kode stil.
Øhh ja. Det er det, jeg giver dig ret i. Ikke alt der skrives på nettet skrives for at komme ind i en diskussion.Chucara (11) skrev:Øhh ja. Det er det, jeg skriver.
Men men men.arne_v (14) skrev:Men men men.
Efter min mening er det bedre hvis et sprogs syntax fungerer både med god og dårlig kode stil end at den kun fungerer med god kode stil.
Det er en fordel hvis sprogets syntax understøtter god kodestil.
(Og så glemmer Linus Torvalds åbenbart dem, som forsøger at bruge 3 character indrykning. Gys.)
Max 3 indenteringer? Det virker til at være i underkanten og vil minimum resultere i et hav af funktions kald som kan gøre tingene endnu mere uoverskuelige hvis hvert et pip skal have sin egen funktion
Jeg bruger selv 2 mellemrum som indentering
En funktion der skal løbe en 2D array igennem og du er allerede oppe på 3.
Det bliver noget tid hvis du har 3d og 4d array der skal købes igennem og du Max må have 3 indents
Jeg bruger selv 2 mellemrum som indentering
En funktion der skal løbe en 2D array igennem og du er allerede oppe på 3.
Det bliver noget tid hvis du har 3d og 4d array der skal købes igennem og du Max må have 3 indents
#16: Helt enig, som alt andet i livet, skal sund fornuft sejre over hårde regler. I C# bruger man jo 2 indents på namespace + class. Og hvis de tæller med, bliver det svært.
#14: Uanset hvor meget respekt jeg har for manden, tager han fejl :) Derudover skal vi videre fra den tankegang, at man sidder med 80x24 terminal. Udviklere sidder på 1080p eller 1440p i dag, så 80 karakterer er en pointless begrænsning.
#14: Uanset hvor meget respekt jeg har for manden, tager han fejl :) Derudover skal vi videre fra den tankegang, at man sidder med 80x24 terminal. Udviklere sidder på 1080p eller 1440p i dag, så 80 karakterer er en pointless begrænsning.
Jeg melder mig også ind i klubben over dem der godt kan lide VB.Net. Specielt det (som nævnt) med at at man bruger en 'End' på alle properties, metoder, etc, da man vil få et super hurtigt overblik
Det er da korrekt nok at man helt skal undgå at have for mange forskellige i en metode, så man ikke ender med en kæmpe metoder med 30 {}, men nu lever vi jo i en verden, hvor man ikke altid får det an ønsker. Jeg har nu mange gange overtaget andre folks kode og det er ikke altid lige kønt (hvilket folk sikkert også har sagt om min kode nogle gange hehe). Jeg har set kæmpe metoder på 2000+ linjer og et virvar af if's, for-løkker, switches og hvad der nu alt findes. I C# kan det virkeligt være et helvede at finde rundt i, med mindre personen har skrevet rigeligt af kommentarer, hvilket desværre er mere undtagelsen end reglen
Jeg kan bedst lide at arbejde i VB.Net, men til mine private projekter bruger jeg C#. Kan lige så godt vænne mig til det, da fremtiden nok byder på mere C# lignende kode end VB lignende kode
På min nuværende arbejdsplads har de desværre taget et (efter min mening) meget dårligt valg for mange år siden. De har valgt at når der skulle oprettes et nyt projekt, så kunne udvikleren selv vælge om det skulle være c# eller VB.Net, så lige nu er det ca. 50/50. For at gøre det hele lidt værrere bliver alle projekter bundet sammen på kryds og tværs, så en solution kan sagtens have 12 VB.Net projekter og 14 C# projekter blandet sammen i et stort kaos
Jeg hopper konstant mellem VB.Net og C#. At skrive en metode i VB, som kalder en metode i C#, som igen kalder en VB metode, det er virkeligt irriterende. Jeg ved ikke hvor mange gange jeg til nu har brugt VB.Net syntax i C# kode eller omvendt
Det er da korrekt nok at man helt skal undgå at have for mange forskellige i en metode, så man ikke ender med en kæmpe metoder med 30 {}, men nu lever vi jo i en verden, hvor man ikke altid får det an ønsker. Jeg har nu mange gange overtaget andre folks kode og det er ikke altid lige kønt (hvilket folk sikkert også har sagt om min kode nogle gange hehe). Jeg har set kæmpe metoder på 2000+ linjer og et virvar af if's, for-løkker, switches og hvad der nu alt findes. I C# kan det virkeligt være et helvede at finde rundt i, med mindre personen har skrevet rigeligt af kommentarer, hvilket desværre er mere undtagelsen end reglen
Jeg kan bedst lide at arbejde i VB.Net, men til mine private projekter bruger jeg C#. Kan lige så godt vænne mig til det, da fremtiden nok byder på mere C# lignende kode end VB lignende kode
På min nuværende arbejdsplads har de desværre taget et (efter min mening) meget dårligt valg for mange år siden. De har valgt at når der skulle oprettes et nyt projekt, så kunne udvikleren selv vælge om det skulle være c# eller VB.Net, så lige nu er det ca. 50/50. For at gøre det hele lidt værrere bliver alle projekter bundet sammen på kryds og tværs, så en solution kan sagtens have 12 VB.Net projekter og 14 C# projekter blandet sammen i et stort kaos
Jeg hopper konstant mellem VB.Net og C#. At skrive en metode i VB, som kalder en metode i C#, som igen kalder en VB metode, det er virkeligt irriterende. Jeg ved ikke hvor mange gange jeg til nu har brugt VB.Net syntax i C# kode eller omvendt
#18: Det kommer igen an på smag. Som C# udvikler synes jeg det er forvirrende med alle de Ends alle vegne. :)
Og damn.. mht. dit arbejde. Hos os må udvikleren selv vælge mellem SVN og Git, men frit valg mellem sprogene er bare.. ja.. damn. Og så endda i samme solution.
Og damn.. mht. dit arbejde. Hos os må udvikleren selv vælge mellem SVN og Git, men frit valg mellem sprogene er bare.. ja.. damn. Og så endda i samme solution.
Det kommer igen an på smag
Det er selvfølgelig rigtigt. Som jeg ser det så er programmering religion. Nogen kan lide det ene og nogen kan lide det andet, men uanset hvad så er det altid de andre der er forkerte hehe
En ting jeg aldrig har forstået ved nogle udviklere er deres vane med at skille {} på en IMHO ulogisk måde. Her tænker jeg på dem der gør følgende:
public void DoStuff() {
}
Hvorfor skal { helt derop at hænge? Hvad han den gjort? Hvorfor ikke hænge i samme kolonne som } ?
Jeg har til nu aldrig fundet ud af hvorfor folk gør sådan noget. Dem jeg har spurgt til nu har alle sagt "Sådan plejer jeg bare at gøre"
Off topic:
Chucara (19) skrev:Og damn.. mht. dit arbejde. Hos os må udvikleren selv vælge mellem SVN og Git, men frit valg mellem sprogene er bare.. ja.. damn. Og så endda i samme solution.
Tell me about it. Og Det er desværre nogle kæmpe projekter. Jeg er selv ny her, så jeg kan endnu ikke helt finde rundt i dem
Men hey, du kan i det mindste frit vælge mellem SVN og Git. Ved min sidste arbejdsplads blev sådan noget kodestyringssoftware ikke brugt. Alt kode skulle bare smides på netværksdrevet (vel og mærke det netværksdrev som minimum gik ned en gang i ugen) og åbnes derfra
Jeg brugte to år på at indføre SVN, men da jeg sagde op var jeg stadig den eneste udvikler (vi var to ialt) der brugte det, så min sidste opgave var at overføre alt kode fra SVN over til netværksdrevene
Jeg bruger primært disse:
public void DoStuff()
{
Stuff();
MoreStuff();
}
og
public void DoStuff() { Stuff(); }
var der noget med nogle tags til kode så formatering ikke ændres, fx antal spaces mm... ??
public void DoStuff()
{
Stuff();
MoreStuff();
}
og
public void DoStuff() { Stuff(); }
var der noget med nogle tags til kode så formatering ikke ændres, fx antal spaces mm... ??
CBM (21) skrev:var der noget med nogle tags til kode så formatering ikke ændres, fx antal spaces mm... ??
Brug [code ]-tagget.
void Main() {
DoStuff();
DoMoreStuf();
if (MustUndoStuff()) {
UndoStuff();
}
}Edit: Well, shit, indrykning smadres alligevel. What's the point, then?
CBM (16) skrev:Jeg bruger selv 2 mellemrum som indentering
Det er vist kun standard i Fortran og Delphi.
CBM (16) skrev:En funktion der skal løbe en 2D array igennem og du er allerede oppe på 3.
Det bliver noget tid hvis du har 3d og 4d array der skal købes igennem og du Max må have 3 indents
Linux kernel har nok ikke ret mange 3D eller 4D arrays.
:-)
Der er som oftest enkelte undtagelser fra den slags tommel-finger regler.
Men taler vi f.eks. om matrix udregningerne så bruger man faktisk funktioner fremfor bare at neste løkkerne.
Jævnfør f.eks. den kendte DAXPY.
Adagio (20) skrev:En ting jeg aldrig har forstået ved nogle udviklere er deres vane med at skille {} på en IMHO ulogisk måde. Her tænker jeg på dem der gør følgende:
public void DoStuff() {
}
Hvorfor skal { helt derop at hænge? Hvad han den gjort? Hvorfor ikke hænge i samme kolonne som } ?
Sådan noget angives jo i coding convention.
Java:
Standard SUN/Oracle coding convention placerer { på enden af linien.
C#:
Standard Microsoft coding convention placerer { på ny linie.
C:
K&R, Linux kernel placerer { på enden af linien *BORTSET* fra for funktioner hvor den ryger på ny linie.
GNU og en hel masse andre placerer { på ny linie.
Take your pick.
arne_v (25) skrev:
Linux kernel har nok ikke ret mange 3D eller 4D arrays.
:-)
Der er som oftest enkelte undtagelser fra den slags tommel-finger regler.
Men taler vi f.eks. om matrix udregningerne så bruger man faktisk funktioner fremfor bare at neste løkkerne.
Jævnfør f.eks. den kendte DAXPY.
tænker også det handler om hvor meget der skal ske i hvert loop.
Der skal ikke ske ret meget før jeg putter det i en funktion som jeg kalder fra en løkke...
Men hvis jeg fx skal løbe et 4d array igennem og ikke skal udføre ret meget fx initiering, så synyes jeg det er spild af tid og lidt uoverskueligt at putte fx de 2 inderste løkker i en funktion
:-)
Jeg gør det fordi det sparer en linje. På den måde kommer jeg hurtigere ned til koden (mellemrum, åben tuborg, enter isf. enter, åben tuborg, enter -- det skal siges at jeg koder med britisk tastaturlayout, så tuborgklammerne er lettere at komme til, men skriveflow ødelægges af at skulle ramme enter to gange), tuborgklammen forstyrrer ikke i læsningsflow, og afslutningen af en metode eller funktion ses langt tydeligere. Hvor jeg får lov sætter jeg ReSharper et al op til at gøre det på den måde. Men i arbejdet er der ofte andre som sætter kodestandarden op, og så klapper jeg hælene sammen.Adagio (20) skrev:En ting jeg aldrig har forstået ved nogle udviklere er deres vane med at skille {} på en IMHO ulogisk måde. Her tænker jeg på dem der gør følgende:
public void DoStuff() {
}
Hvorfor skal { helt derop at hænge? Hvad han den gjort? Hvorfor ikke hænge i samme kolonne som } ?
Jeg har til nu aldrig fundet ud af hvorfor folk gør sådan noget. Dem jeg har spurgt til nu har alle sagt "Sådan plejer jeg bare at gøre"
Men én ting, som jeg sværger til, er altid at bruge tuborgklammer. Medmindre det kan klares med en ternary operator (x=x==y?x:y).
arne_v (24) skrev:gramps2 (15) skrev:Men men men.
Det er en fordel hvis sprogets syntax understøtter god kodestil.
Men det gør END XXX / XXX END jo lige så godt som }.
Mjah, mjoh. Vi kan selvfølgelig gå ind i en lang diskussion for og imod, men jeg ser oftere dårlig kodestil i sprog, som har END keyword (f.eks. SQL, VHDL) end i sprog, som ikke har. Det kan skyldes ringere erfaring fra udviklernes side, eller dårligere IDE, men jeg ser oftere konsistent indrykning i C-style sprog end i "de andre".
#30
Jeg orker ikke at kigge hele kernel igennem, men det ser ud til, at de prøver at overholde det:
https://github.com/torvalds/linux
Enkelte steder ser jeg fire tab indrykning. Men ikke mere.
Jeg orker ikke at kigge hele kernel igennem, men det ser ud til, at de prøver at overholde det:
https://github.com/torvalds/linux
Enkelte steder ser jeg fire tab indrykning. Men ikke mere.
arne_v (12) skrev:Kian (4) skrev:Samtidig er jeg også stor tilhænger af at operationer som fx If eller For sluttes ned End If eller Next i forhold til at alt sluttes med en }.
Det er også min mening. Men moden i disse år er anderledes.
Ha! Jeg er også enig med dig! Når man alligevel skal sætte en afsluttende kodestump (modsat fx Python) kan man lige så godt skrive hvad man vil afslutte
arne_v (12) skrev:Kian (4) skrev:Mange har en dårlig opfattelse af VB og kalder sproget for et begyndersprog.
Så stor forskel er der heller ikke på VB.NET og C#.
Men det er vel rimeligt at antage at ved .NET fremkomsten gik det:
VB6 udviklere -> VB.NET udviklere
VC++ udviklere -> C# udviklere
Og VC++ udviklere som har siddet og rodet med COM og ATL i C++ var altså noget bedre (gennemsnitligt set) end dem som havde siddet og lavet UI i VB6.
Og VB.NET arvede vel ry fra de mindre skrappe VB.NET udviklere.
Altså jeg er jo præcis enig og jeg argumenterer også mod at man kalder VB for at begyndersprog forstået på den måde at det ikke kan noget. Hvis man derimod referer til at indlæringskurven er mindre stejl fordi det kan virke barnligt at man nærmest bare skriver englsk, så har jeg ingen problem. Det er kun fedt at VB.NET er let at lære og samtidig er et stærkt sprog.
arne_v (13) skrev:Kian (6) skrev:...kommentarsporet på blogopslaget lader da også til at gøre Microsofts argumenter pænt til skamme...
Der er nok mere politik bag beslutningen end der er egentlig fakta.
Det er vel fakta at interessen for VB.NET fra diverse *nix og open source grupper (Mono, Xamarin etc.) er meget lav.
Jeps... VB.NET ligner ikke meget andet som C# gør. Folk der kommer fra en Java eller C-verden har langt lettere ved at absorbere C#. VB.NET flatliner når det kommer til dialekt-mix. VB.NET har kun sig selv. Og det gør selvfølgelig at man skal komme fra VB for at blive i VB. Migrering er ikke umuligt - på føromtalte blogpost er der talrige kommentarer fra C#'ere der er konverteret til VB.NET'ere - det sker bare ikke så tit fordi Microsoft netop i de senere har haft en liiiidt lille lyst til at gøre noget seriøst ved VB-sproget. Og nu definitivt tager konsekvensen.
Chucara (11) skrev:Læser du, hvad jeg skriver? :D Jeg skriver jo netop ikke at 'det er noget lort'. Jeg skriver, at dem, der koder C# synes VB's syntax er tåbelig og at dem, der koder VB, bedre kan lide denne end tuborgerne fra C#/Java. [...]
og
Chucara (8) skrev:Kom over på den mørke side
Jeg tror det var den sidste her jeg blev lidt provokeret over. Og ja jeg ved godt at jeg er nærtagen når det kommer til programmeringssprog. Jeg har intet mod C#. Jeg læser C# fint. Men jeg er satme blevet grint af mange gange på diverse forums når jeg fortæller jeg er VB.NET'er. Jeg er automatisk i alarmberedskab når snakken falder på programmeringssprog. Undskyld.
Adagio (18) skrev:Jeg melder mig også ind i klubben over dem der godt kan lide VB.Net. Specielt det (som nævnt) med at at man bruger en 'End' på alle properties, metoder, etc, da man vil få et super hurtigt overblik
Det er da korrekt nok at man helt skal undgå at have for mange forskellige i en metode, så man ikke ender med en kæmpe metoder med 30 {}, men nu lever vi jo i en verden, hvor man ikke altid får det an ønsker. Jeg har nu mange ga[...]
Hvis du vil sige det, hvilken kodesmedsbutik arbejder du så i?
Chucara (34) skrev:Relevant TFWTF:
http://thedailywtf.com/articles/strung-out-propert...
Jeg er muligvis dum. Kan du forklare hvad det er der er hans pointe?
#35: No worries. Ved godt at VB udviklere er følsomme blomster :) (undskyld, kunne ikke dy mig). Sprog er religion. Og bemærk iøvrigt at jeg omtalte C# som den mørke side, ikke den lyse.
#37: TheDailyWTF.com er bare en samling af sjove/dumme ting, udviklere er stødt på i deres karrierer. Denne her var bare relevant, da den netop omtalte nyheden omkring VB.Net.
Der er ikke rigtigt anden pointe, end at det kode, der er i artiklen, er meget dårligt skrevet.
Hvis jeg kalder setteren på DBConnection indexeren. (Og nu skriver jeg lige C# syntax her):
x.DBConnection["a"] = "b"
Vil koden:
- fuldstændigt ignorere værdien "b"
- Lukke en evt. eksisterende forbindelse til databasen
- Åbne en ny forbindelse til "a"
Der er ingen grund til at det er en indexer.
Der er ingen grund til at det er en property.
Der er side effekts
Ingen ville ane at setteren opfører sig sådan uden at se hvad den gør
Ikke at det har noget med VB.Net at gøre. Dette kunne være skrevet i Java, C# eller mange andre sprog og være lige så grimt.
#37: TheDailyWTF.com er bare en samling af sjove/dumme ting, udviklere er stødt på i deres karrierer. Denne her var bare relevant, da den netop omtalte nyheden omkring VB.Net.
Der er ikke rigtigt anden pointe, end at det kode, der er i artiklen, er meget dårligt skrevet.
Hvis jeg kalder setteren på DBConnection indexeren. (Og nu skriver jeg lige C# syntax her):
x.DBConnection["a"] = "b"
Vil koden:
- fuldstændigt ignorere værdien "b"
- Lukke en evt. eksisterende forbindelse til databasen
- Åbne en ny forbindelse til "a"
Der er ingen grund til at det er en indexer.
Der er ingen grund til at det er en property.
Der er side effekts
Ingen ville ane at setteren opfører sig sådan uden at se hvad den gør
Ikke at det har noget med VB.Net at gøre. Dette kunne være skrevet i Java, C# eller mange andre sprog og være lige så grimt.
Chucara (38) skrev:No worries. Ved godt at VB udviklere er følsomme blomster :) (undskyld, kunne ikke dy mig).
Haha... jeg takker. Jeg forventer en interflora-buket min vej.
Chucara (38) skrev:TheDailyWTF.com er bare en samling af sjove/dumme ting, udviklere er stødt på i deres karrierer. Denne her var bare relevant, da den netop omtalte nyheden omkring VB.Net.
Jeg kender åh-så-glimrende tdwtf. Jeg fattede bare ikke mandens pointe. Det gør jeg stadig ikke. Hvis der er kode der er ligegyldigt men som han skriver så kan han bare lade være med at skrive sin kode sådan. Der er ingen der tvinger dig til at skrive dårlig kode. Jeg ville aldrig putte min dbconnection i en property. Jeg bruger Entity og er jublende ligeglad med maskinerummet (lige indtil jeg overrider noget af dens constructor-hejs og .NET bagefter autogenererer og overskriver mine rettelser).
Chucara (38) skrev:prog er religion
Jeg er efterhånden nået dertil hvor jeg ikke længere synes det er spændende at tale om religion i programmeringssammenhæng. Jeg ser vitterligt .NET Frameworket som et komplet værk som jeg helst ikke vil skille ad (meget qua det Microsoft har gang i). VB.NET er en måde at skrive kode på - C# er en anden, men i sidste ende er det (næsten) ens. Jeg vil helst ikke identificere skellet som en religion da det, især i samtiden, også fordrer at der er en krig. Jeg er af den overbevisning at alle sprogene i .NET er fantastiske og mangfoldige i sig selv. Det der skaber diversiteten og udviklingen er netop diversiteten a 'la 'hey! smart feature her - lad os få den med over her og se om vi kan udvikle noget nyt og spændende'.
gramps2 (29) skrev:men jeg ser oftere dårlig kodestil i sprog, som har END keyword (f.eks. SQL, VHDL) end i sprog, som ikke har. Det kan skyldes ringere erfaring fra udviklernes side, eller dårligere IDE, men jeg ser oftere konsistent indrykning i C-style sprog end i "de andre".
SQL og VHDL er måske også lidt atypiske programmeringssprog.
Jeg synes da generalt at Pascal, Fortran, VB.NET og Ada programmører er ret gode til at lave indrykning.
Chucara (38) skrev:
Hvis jeg kalder setteren på DBConnection indexeren. (Og nu skriver jeg lige C# syntax her):
x.DBConnection["a"] = "b"
Vil koden:
- fuldstændigt ignorere værdien "b"
- Lukke en evt. eksisterende forbindelse til databasen
- Åbne en ny forbindelse til "a"
Der er ingen grund til at det er en indexer.
Der er ingen grund til at det er en property.
Der er side effekts
Ingen ville ane at setteren opfører sig sådan uden at se hvad den gør
C# & VB.NET har valgt at man ikke kan lide en konvention omkring brug af metoder til setters men istedetfor indført en ny syntax som kun giver mening hvis man overholder en konvention.
:-)
#43
Hvis i vil more jer, så kig på Objective-C eller Swift...
F.eks. så kalder man jo ikke nødvendigvis super() som den første linje i en Swift ctor. Faktisk er det mere typisk at man kalder super() i *midten* af ctor'en.
Alle konventioner af sat ud af spillet når man skal arbejde med Apple's produkter :P
Hvis i vil more jer, så kig på Objective-C eller Swift...
F.eks. så kalder man jo ikke nødvendigvis super() som den første linje i en Swift ctor. Faktisk er det mere typisk at man kalder super() i *midten* af ctor'en.
Alle konventioner af sat ud af spillet når man skal arbejde med Apple's produkter :P
#43: Er ikke helt sikker på hvad du mener, men properties er en ting, jeg har svært ved at undvære i f.eks. Java.
C#:
public string Test { get; set; }
Java:
private string test;
public String getTest()
{
return test;
}
public void setTest()
{
this.test = test;
}
Som du siger, er det i Java en konvention, mens det i C# er fast syntax med dertilhørende compile time fejl.
At en eller anden har maltrakteret det i #38 kan man ikke rigtigt bebrejde VB.Net.
C#:
public string Test { get; set; }
Java:
private string test;
public String getTest()
{
return test;
}
public void setTest()
{
this.test = test;
}
Som du siger, er det i Java en konvention, mens det i C# er fast syntax med dertilhørende compile time fejl.
At en eller anden har maltrakteret det i #38 kan man ikke rigtigt bebrejde VB.Net.
#45
Det er langt nemmere at skrive.
Men som det maltrakterende eksemple viser, så har man reelt lavet to forskellige syntaxer for metode kald - og det virker kun fornuftigt, hvis konventionen omkring brug overholdes.
Så man har erstattet en konvention (omkring getter og setter) med en syntax (properties) som kun virker fornuftigt hvis man overholder en konvention.
Det er langt nemmere at skrive.
Men som det maltrakterende eksemple viser, så har man reelt lavet to forskellige syntaxer for metode kald - og det virker kun fornuftigt, hvis konventionen omkring brug overholdes.
Så man har erstattet en konvention (omkring getter og setter) med en syntax (properties) som kun virker fornuftigt hvis man overholder en konvention.
#46
En ægte property ville have en semantik, hvor:
* get ikke kan ændre object state og ikke kan ændre noget eksternt
* set kun kan ændre state som hentes med get, altid ændrer denne og ikke kan ændre noget eksternt
hvor overtrædelser gav en compile fejl.
Men den ville nok blive noget tricky at implementere.
En ægte property ville have en semantik, hvor:
* get ikke kan ændre object state og ikke kan ændre noget eksternt
* set kun kan ændre state som hentes med get, altid ændrer denne og ikke kan ændre noget eksternt
hvor overtrædelser gav en compile fejl.
Men den ville nok blive noget tricky at implementere.
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
- ⟨
- Nyheder
Gå til bund