mboost-dp1

Pixabay

Større .NET support til Visual Basic

- Via The Register - , indsendt af arne_v

Så er der godt nyt for alle der stadig udvikler i Visual Basic – selvom det kan være en stakket frist

Med version 5 af .NET kommer der ligeledes større understøttelse for Visual Basic i .NET.

Det betyder i praksis at en række programmer, der stadig kun fungerer i VB og ikke VB.net, vil kunne kompileres og køres under .NET 5 – hvor Visual Basic programmer ellers måtte konverteres til et andet sprog.

Microsoft anbefaler dog at man overvejer at konvertere til andet sprog, f.eks. C#, da Visual Basic er lidt af en gammel svend og Microsoft ikke vil udvikle sproget yderligere.

Dog melder Microsoft også ud, at man ikke kan eller skal forvente, at der fortsat vil være samme niveau af Visual Basic understøttelse i fremtidige .NET versioner.

Microsofts oversigt over Visual Basic support i .NET 5 kan læses her hvor de mange nye understøttede funktioner / class libraries beskrives.





Gå til bund
Gravatar #1 - demolition
19. mar. 2020 06:49
Jeg kan ikke helt få denne nyhed til at give mening.. VB .NET har eksisteret siden 2002 hvor det allerførste .NET Framework blev lanceret. Linket til kilden henviser ikke til noget relevant.
Gravatar #2 - _tweak
19. mar. 2020 07:05
#1 nyhed opdateret med lidt klarhed :)
Gravatar #3 - demolition
19. mar. 2020 10:41
Linket nederst i nyheden giver lidt klarhed - nyheden er at VB nu understøtter .NET Core og ikke kun .NET Framework. Forskellen er at .NET Core er open source og officielt understøttet på flere operativsystemer og ikke kun Windows. .NET Framework og .NET Core smelter desuden sammen i denne version så derfor var de nødt til at få VB fuldt understøttet i Core for at man fortsat skulle kunne bruge sine eksisterende VB programmer.
Gravatar #4 - arne_v
19. mar. 2020 15:09
#2

Jeg synes stadig ikke at formuleringen er god.

VB classic med sidste version VB6 fra 1998 er helt forældet og der er ingen planer om at undesrtøtte den.

VB.NET blev introduceret i 2002 og er ikke kompatibel med VB6 - sådan lidt groft sagt er VB.NET bare C# med en VB lignende syntax.

I de senere år (efter at VB6 er gledet helt ud af folks verden) er man begyndt bare at tale om VB når man mener VB.NET.

C# og VB.NET har været de to store (og i teorien ligestillede) sprog i .NET 1.z, 2.x, 3.x og 4.x.

.NET 5.x er baseret på .NET Core 3.x - ikke på .NET 4.x. Og i .NET Core verdenen er C# klart den store.

Og der har tilsyneladende været lidt tvivl om VB.NET (eller VB hvis man forkorter) supported i .NET 5.x.

Men nu har MS udvidet den fra udover libraries og console apps også at understøtte desktop apps og web apps.

Ikke så overraskende efter min mening.

1) Der er stadig mange VB.NET brugere
2) Der findes en Roslyn compiler til VB.NET
3) VB.NET kan bruge de samme framework libraries som C#

Ved at gøre dette kan MS undgå en million eller to udviklere som permanent hænger på .NET 4.x ved en investering i at udvikle nogle få VS wizards for VB.NET. Det må være åretes nemmest business case.

Gravatar #5 - Kian
20. mar. 2020 08:32
Øøøh hvad?
Har I helt tabt sutten og overset pointen? Der skrives at man ikke længere har tænkt sig at udvikle VB.NET. Det er et dødsstød det her. Nok vil man supportere sproget men featuremæssigt lukker man i.

Og jeg mener, som jeg også skrev den 16. marts som kommentar på bloggen, at Microsofts forkælede bastard, C#, kommer til at løbe med sejren uden andre argumenter end 'fordi'. Jeg er så træt af Microsofts holdning til VB. Det er fint nok at folk griner af mig osv - det er okay. Og selvom jeg har prøvet at migrere flere gange til C# og egentlig skriver C# ganske fint mv så vil min hjerne altså helst skrive VB.NET.
Det irriterer det mig at Microsoft vil bestemme hvilket sprog jeg skal vælge. Grænseløst!

Gravatar #6 - Kian
20. mar. 2020 08:36
Øøøh hvad?
Har I helt tabt sutten og overset pointen? Der skrives at man ikke længere har tænkt sig at udvikle VB.NET. Det er et dødsstød det her. Nok vil man supportere sproget men featuremæssigt lukker man i.

Og jeg mener, som jeg også skrev den 16. marts som kommentar på bloggen, at Microsofts forkælede bastard, C#, kommer til at løbe med sejren uden andre argumenter end 'fordi'. Jeg er så træt af Microsofts holdning til VB. Det er fint nok at folk griner af mig osv - det er okay. Og selvom jeg har prøvet at migrere flere gange til C# og egentlig skriver C# ganske fint mv så vil min hjerne altså helst skrive VB.NET.
Det irriterer det mig at Microsoft vil bestemme hvilket sprog jeg skal vælge. Grænseløst!

Og nej! Argumentet om at VB.NET er en gammel svend er fuldstændig ligegyldigt. Det er helt op til forfatteren af sproget at udvikle det. Argumentet om at det er en gammel svend læner sig kun op ad forfatterens evne til at udvikle sproget. Inddirekte siger Microsoft at de mener de selv er for dumme til at opdatere så nu bør folk migrere. Det er håbløs argumentation. VB.NET har samme base som C#. Baseline er identisk - der ligger blot lidt syntax oven på på samme måde som C# også bare ligger lidt syntax oven på. Sprogene kan præcis det samme og har samme udviklinspotentiale. Microsoft forplumrer vandende igen til fordel for deres forkælede møgunge, C#.

Det er satme som et ringe familieforhold det her hvor forældrene ikke vil vedkende sig deres eget barn efterhånden. Håbløst!
Gravatar #7 - CBM
20. mar. 2020 09:48
VB.NET er nemt at bruge, meget nemmere end c#

Men i sidste ende er begge sprog noget lort
Gravatar #8 - Claus Jørgensen
20. mar. 2020 11:04
#7

Ikke hvis du skal programmere rigtig software. Men kan godt se at en scriptkiddie sysadmin ikke kan forstå advanceret programmeringsprog :)
Gravatar #9 - CBM
20. mar. 2020 11:09
#8 bare fordi du er MS fanboy :-)
Gravatar #10 - arne_v
20. mar. 2020 11:36
#7 og #8

Er der nogen reel forskel på VB.NET og C# udover forskellig syntax?

Det er jo ret nemt at konvertere begge veje.

Hvis jeg skal lave et VB.NET eksempel, så skriver jeg det i C# og klikker konverter til VB.NET og voila.

MS snakkede på et tidspunkt om at lave VS så man frit kunne vælge "editerings sprog" - selvom kode reelt var C# kode og gemt som sådan på disk så kunne man se de og redigere den som VB.NET og omvendt. Jeg mener ikke at det blev til noget. Men bare det at ideen har været fremme indikerer at den reelle forskel er meget lille.
Gravatar #11 - Chucara
20. mar. 2020 21:50
#10: Der er en forskel. De er begge CLR sprog, men hvor C# har fået et væld af nye features, har VB.NET været ladt lidt i stikken.

Og ja - i princippet er det syntaks, men det vil jeg også argumentere for er en pænt stor del af et programmeringssprog :D

Personligt kan jeg ikke forstå at man som udvikler vælger at starte et nyt VB.NET projekt i dag, og det tænker jeg også er Microsoft's holdning. Dog er den en del legacykode, som man ikke ønsker at omskrive helt, og her kaster MS så et par lunser efter de udmagrede løver.

Der er ingen tvivl om at C# er Microsoft's hjertebarn og at VB (sammen med WinForms, WCF og WWF) lige så stille og roligt flytter 'ud på gården'.

Nyhedsteksten er forvirrende, men handler om at man på .NET Core (som bliver til .NET 5 og er fremtiden for .NET) kun havde understøttelse for konsolapplikationer og class libraries. Man kunne f.eks. ikke lave et webløsning i ASP.NET Core. Det kan man kun i C# og F#. Dermed havde man ikke en reel opgraderingsplan for en ASP.NET VB applikation mens en ASP.NET applikation kunne opgraderes til Core forholdsvist enkelt i C#.

Fra mit synspunkt har VB været døende de sidste 10+ år og jeg begriber ikke helt at man ikke allerede har porteret koden til C#. Men hvis man byggede 2000s-style monolither, er det nok ikke bare så enkelt at komme videre.

Men jeg er meget stor fan af hvad der sker med .NET i tiden. Der er gang i udviklen, det kan afvikles på *nix, er open source osv. Basalt set alt hvad Java kunne have været, hvis Oracle ikke havde fucket det op.

</rant>
Gravatar #12 - arne_v
21. mar. 2020 01:44
Chucara (11) skrev:
#10: Der er en forskel. De er begge CLR sprog, men hvor C# har fået et væld af nye features, har VB.NET været ladt lidt i stikken.

Og ja - i princippet er det syntaks, men det vil jeg også argumentere for er en pænt stor del af et programmeringssprog :D


Sprogene har meget forskellig syntax.

Men så længe der er ækvivalens i funktionalitet, så synes jeg ikke det er så vigtigt.

Og for det meste synes jeg at VB.NET kan følge nogenlunde med.

Der er visse ting man kan i C# som man ikke kan i VB.NET f.eks. unsafe blok, men det er efter min bedste overbevisning sjældent man har brug for det - og hvis man har så er det nok C++ og ikke VB.NET der er alternativet til C#.

Og så er der visse ting som er lidt elegantere i C# end i VB.NET og som bruges. Men forskellen er ikke større end at man kan leve med det, hvis man kan lide VB.NET.

Chucara (11) skrev:

Personligt kan jeg ikke forstå at man som udvikler vælger at starte et nyt VB.NET projekt i dag, og det tænker jeg også er Microsoft's holdning. Dog er den en del legacykode, som man ikke ønsker at omskrive helt, og her kaster MS så et par lunser efter de udmagrede løver.


Der er generelt stor træghed i den slags.

Der er eksisterende VB.NET kode og omkostningen ved at teste applikationen efter omskrivning plus risikoen for at der skulle snige sig fejl igennem er ikke ubetydeligt.

Der er folk med mere VB.NET erfaring end C# erfaring.

Chucara (11) skrev:

Fra mit synspunkt har VB været døende de sidste 10+ år og jeg begriber ikke helt at man ikke allerede har porteret koden til C#. Men hvis man byggede 2000s-style monolither, er det nok ikke bare så enkelt at komme videre.


Det betyder ikke så meget om det er monolit eller ej. Man kan godt skifte dele af en monolit fra VB.NET til C#.

Men det koster. Og når der skal prioriteres mellem at omskrive fra VB.NET til C# eller at tilføje ny funktionalitet, så ...

Gravatar #13 - arne_v
21. mar. 2020 01:50
Chucara (11) skrev:

Men jeg er meget stor fan af hvad der sker med .NET i tiden. Der er gang i udviklen, det kan afvikles på *nix, er open source osv. Basalt set alt hvad Java kunne have været, hvis Oracle ikke havde fucket det op.



Hmmm.

Så hvis ikke Oracle havde købt SUN (med visse Java rettigheder), så havde Java kørt på *nix og været open source?

:-)

Java har kørt på Unix og Linux siden 1996.

Java har været tilgængelig som open source siden 2007.



Gravatar #14 - Chucara
22. mar. 2020 00:13
#12:

Det, jeg mente med syntaks er, at begge sprog er Turing komplette - så du kan selvfølgelig lave det samme i begge sprog. Men der er virkelig mange nye features i C# som ikke har en ækvivalent i VB.NET, og også .NET Core-relaterede teknologier har været sløv med understøttelse.

Som du også kan læse her:

https://devblogs.microsoft.com/vbteam/digging-deep...

Er det ret tydeligt, at VB ikke har ret meget prioritet hos MS siden 2017 (nok også lidt før).

Mht. monolither, så mener jeg at det er alt andet lige noget lettere at skifte en microservice ud end at flytte dele af et sammenfiltret system ud - især hvis dele af systemet skal bygges på nye teknologier. Jeg gruer for de stakler der stadig sidder med SOAP eller WCF services i dag. Og af gode grunde var der ingen, der lavede Microservices i 00'erne. Personligt ville jeg ikke være bekymret for at skifte teknologi på nogle af vores microservices mens det er et flerårsprojekt at opbryde vores sidste monolith og skifte fra Delphi til C#.

Jeg ved udemærket godt hvad Java er - jeg har kodet i det i variende grad siden 2002 :) Jeg synes bare ikke det har været en forbedring at Oracle tog over. Hele balladen omkring Apache Harmony, deres paid security updates på ældre versioner, og generelt virker det (for mig) bare til at udviklingen går langt hurtigere mange andre steder end hos Java.

Til deres forsvar havde Sun droppet hele Java Security teamet lige inden Oracle overtog, så Oracle spyttede dengang nogle penge i kassen for at få det op at køre igen.
Gravatar #15 - arne_v
22. mar. 2020 00:38
Chucara (14) skrev:
#12:

Det, jeg mente med syntaks er, at begge sprog er Turing komplette - så du kan selvfølgelig lave det samme i begge sprog. Men der er virkelig mange nye features i C# som ikke har en ækvivalent i VB.NET, og også .NET Core-relaterede teknologier har været sløv med understøttelse.


Så længe noget typisk business kode ikke resulterer i nævneværdigt flere LOC i VB.NET end i C#, så betyder det ikke så meget.

Chucara (14) skrev:

Mht. monolither, så mener jeg at det er alt andet lige noget lettere at skifte en microservice ud end at flytte dele af et sammenfiltret system ud - især hvis dele af systemet skal bygges på nye teknologier. Jeg gruer for de stakler der stadig sidder med SOAP eller WCF services i dag. Og af gode grunde var der ingen, der lavede Microservices i 00'erne. Personligt ville jeg ikke være bekymret for at skifte teknologi på nogle af vores microservices mens det er et flerårsprojekt at opbryde vores sidste monolith og skifte fra Delphi til C#.¨


Jeg kan slet ikke følge dig.

C# er et managed sprog og Delphi er et unmanaged sprog, så det er ikke praktisk muligt at konvertere gradvist.

C# og VB.NET genererer samme kode, så uanset om det er en monolit eller en micro-service kan man konvertere i små bidder.
Gravatar #16 - Claus Jørgensen
22. mar. 2020 12:12
arne_v (15) skrev:
Så længe noget typisk business kode ikke resulterer i nævneværdigt flere LOC i VB.NET end i C#, så betyder det ikke så meget.
Mit argument for valg af sprog/teknologi har ofte mere at gøre med om vi kan hyre folk der har erfaring med det eller ej.

Det er nok noget næmmere at hyre en erfaren C# udvikler end en VB.NET udvikler.
Gravatar #17 - arne_v
22. mar. 2020 20:22
Claus Jørgensen (16) skrev:
arne_v (15) skrev:
Så længe noget typisk business kode ikke resulterer i nævneværdigt flere LOC i VB.NET end i C#, så betyder det ikke så meget.
Mit argument for valg af sprog/teknologi har ofte mere at gøre med om vi kan hyre folk der har erfaring med det eller ej.


Ja. Under en vis grænse værdi for LOC/FP så er skill set til rådighed mere vigtigt.

Claus Jørgensen (16) skrev:

Det er nok noget næmmere at hyre en erfaren C# udvikler end en VB.NET udvikler.


Der er formentligt ikke mange nyuddannede som har lært VB.NET.

Men der er nok rigtigt mange VB6 folk som valgte at skifte til VB.NET fremfor C# for at få en "bekendt følelse".
Gravatar #18 - arne_v
22. mar. 2020 23:18
arne_v (17) skrev:

Men der er nok rigtigt mange VB6 folk som valgte at skifte til VB.NET fremfor C# for at få en "bekendt følelse".


... VB6 folk og ASP/VBS folk ...
Gravatar #19 - arne_v
25. mar. 2020 13:29
#apropos

Jeg har lige hjulpet en med at konvertere noget kode fra C# til VB.NET:

https://www.computerworld.dk/eksperten/spm/1032660

:-)
Gravatar #20 - Kian
27. mar. 2020 21:30
fjernet af mig selv pga lorte-redigerings-funktion. Note til self: brug ikke uBlock Origin hvis du vil redigere i dit indlæg.
Gravatar #21 - Kian
27. mar. 2020 21:31
Når alt støvet har lagt sig og folk har fået stampet deres personlige holdninger til VB.NET af så kan vi begynde at snakke. Jeg er vant til at folk (og især C#'ere) i bund og grund ikke har mange andre argumenter i ærmet end deres 'fordi jeg synes'. Det virker oftest meget tamt når de først starter med at grine af mig. Min holdning til C#-programmører og syntaxen i C# er også totalt ligegyldig og jeg ytre den sjældent.


Jeg medgiver at VB.NET har tabt pusten. Men det er ikke VB.NET's skyld! Det er Microsoft der favorisere deres forkælede møgunge og samtidig sylter og lægger VB.NET i graven. VB.NET er fra udgangspunktet præcist lige så godt stillet som C# og vil derfor kunne bringes til at kunne præcis det samme som C# - både featuremæssigt men også framework-teknologisk.

Jeg er ked af at VB.NET har fået et så ringe eksistensgrundlag. Det skærer mig i hjertet at se hvordan Microsoft behandler et sprog som for fx mig er så nemt at anvende. Min hjerne tænker i VB.NET og for mig er det C# der forstyrrer og hindrer mig i at kode smukt, godt og hurtigt.

Jeg er ikke ignorant og jeg ser skriften på væggen. Men det er godt nok trist.
Gravatar #22 - Kian
27. mar. 2020 21:32
der går seriøst noget galt for Newz.dk med redigering af ens egne kommentar. Den er virkelig elendig den funktionalitet.
Gravatar #23 - arne_v
28. mar. 2020 12:04
#21

C# er langt bedre end VB.NET på snobbe-skalaen.

:-)

Men det er ikke kun MS og .NET - trended er meget "curly bracket" sprog helt generelt.

Eneste markante undtagelse synes at være Python.
Gravatar #24 - Kian
28. mar. 2020 12:27
#23
Jeg er meget enig. Men jeg har også lært at man skal passe på med at kalde snobberne for snobber for så kigger de bare endnu mere olmt på en.
Jeg ville fortrække hvis C#'ere gad at lade være med at kigge på sproget men istedet kiggede på hvad der blev udrettet. Jeg er skide ligeglad med sprog og jeg programmerer gerne C# - fx i mine Umbraco-løsninger. Oftest med VB.NET APIControllere og C# Razor i selve løsningen. For mig er sproget det som min hjerne vælger - og intet andet. Det betyder ikke at andre hjerner er dumme hvis de ikke gør det samme, men det er oftest den vibe jeg får fra C#'ere.
Jeg sad i en ny konstellation i en nørd-klub her i Aarhus som jeg er begyndt at komme i. Folk grinte da de fandt ud af at jeg programmerede i VB.NET (selvfølgelig på den flinke måde). Det er fair - jeg er vant til folk der griner, men jeg synes bare det er så ukonstruktivt som det næsten kan blive.


Min hjerne har det meget svært med curl-sprog. Det er nok bare mig men mit problem generelt er at hvis jeg er nede i en blok hvor jeg ikke kan se starten af curlen og der så kommer enden på curlen så aner jeg ikke hvad det er der slutter. Er det en for-løkke? er det en if-konstruktion? eller noget helt andet. Det generer min hjerne voldsomt og ved netop VB.NET har jeg End If, Next, End Sub, End Function, End Namespace osv. Det giver min hjerne så meget ro at jeg kan overskue blokke inde i blokke - selv nede i koden hvor jeg ikke kan se den enkelte bloks start; jeg ved hvad der findes oppe i koden for jeg kan se dens slut-blok i VB.NET-koden.

Og ja! jeg ved godt at folk siger man ikke skal lave lange blokke. But guess what! det sker!


Udover selve curl-delen har jeg massere andre problemer med C#-syntaxen. Men igen - det er som smagen på din ispind - nogle kan ikke li chokoladeis og andre fortrækker jordbæris. Jeg er rimelig ligeglad med hvad andre fortrækker og jeg ville ønske at folk gad være ligeglad med min favoritsmag og istedet zoomede ud og istedet forholdte sig til kontekst.

Gravatar #25 - Kian
28. mar. 2020 12:41
#24
Og iøvrigt vil jeg lige tilføje at det går begge veje om sproget er godt eller skidt. De små variationer der er fra C# til VB.NET er ikke altid noget der stiller VB.NET dårligere.
Fx fandt jeg i sidste uge ud af at en liste kan manipuleres i C# mens man ititerer igennem den. Det tillader VB.NET ikke - der bliver man nødt til at gøre det i en Do hvis man vil ændre i listen mens den gennemløbes.
Jeg synes ikke det er særligt smukt at C# tillader at ændre i listen under gennemløb. VB.NET låser listen ved gennemløb hvilket giver meget mere mening.
Gravatar #26 - arne_v
28. mar. 2020 15:13
Kian (25) skrev:
#24
Fx fandt jeg i sidste uge ud af at en liste kan manipuleres i C# mens man ititerer igennem den. Det tillader VB.NET ikke - der bliver man nødt til at gøre det i en Do hvis man vil ændre i listen mens den gennemløbes.
Jeg synes ikke det er særligt smukt at C# tillader at ændre i listen under gennemløb. VB.NET låser listen ved gennemløb hvilket giver meget mere mening.


Du får ikke en:

System.InvalidOperationException: Collection was modified; enumeration operation may not execute.

??


Gravatar #27 - larsp
29. mar. 2020 09:56
Kian... Jeg fik Basic ind med sutteflasken på en C64. Som lille purk kodede jeg gw-basic, og som jeg voksede op blev det til quick-basic, VB 2.0, 3.0 ... 6.0. Ifølge Djikstra skulle sådan en som mig, og dig formoder jeg :), have være blevet skadet for livet og aldrig i stand til at lære at programmere fornuftigt.

Men jeg skiftede til C og curly bracket sprog i jagten på bedre performance. Senere til Python og andre højniveau sprog i jagten på højere abstraktionsniveau. Fordi det var den vej vinden blæste.

Min pointe er såmend bare at det er muligt at lære nye syntakser, og som udvikler bør man distancere sig selv fra selve syntaksen og være åben over for at lære nye sprog og paradigmer. Det er sundt at udvide horisonten. Ellers ender man som en hippie der stadig har page hår og hornbriller her i 20'erne. Det er ikke et godt look.

For tiden er min udfordring at lære GIT for alvor. Som mercurial / hg person der er vandt til at bruge TortoiseHG workbench gennem adskillige år H***DER jeg git af et ondt hjerte. Og når jeg ser erfarne Git brugere hamre løst på tastaturet i minutter for at lave operationer jeg kan klare med et par museklik i TortoiseHg, bliver jeg inderst inde bekræftet i at jeg har ret...

.. Men, for ikke at blive kastet af toget, er jeg alligevel igang med at lære det. Det sgu bare den vej vinden blæser må jeg erkende.

Angående curly bracket sprog og at man ikke kan se hvad } specifikt slutter af, vil jeg give dig ret. Men med disciplin i indentation level (taget for givet) og en god IDE der highligher matchende { } når man navigerer rundt med piletasterne, er det et ikke problem synes jeg. Og hvis der er noget kode der er så indviklet at man mister overblikket bør man overveje at dele det mere op alligevel.
Gravatar #28 - arne_v
29. mar. 2020 11:55
larsp (27) skrev:

Angående curly bracket sprog og at man ikke kan se hvad } specifikt slutter af, vil jeg give dig ret. Men med disciplin i indentation level (taget for givet) og en god IDE der highligher matchende { } når man navigerer rundt med piletasterne, er det et ikke problem synes jeg. Og hvis der er noget kode der er så indviklet at man mister overblikket bør man overveje at dele det mere op alligevel.


Citat fra Linux kernel coding style guide:


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.


Gravatar #29 - larsp
29. mar. 2020 12:29
#28 min foretrukne indentation style er 4 spaces. Never tab. Allman style brackets. Der er den curly bracket style der er lettest at overskue IMO. Har aldrig kunne fordrage K&R style.
The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program

Stive finne.
Gravatar #30 - arne_v
29. mar. 2020 14:03
larsp (29) skrev:


The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program

Stive finne.


Hård nyser.

Og jeg er heller ikke helt enig i reglerne.

Men de helt overordnede pointer er gode nok:
* stor indrykning gør det nemmere at se blokkene
* er indrykning for stort et problem så er det på tide at splitte koden op i nogle funktioner

Hvilket jeg også læste i det du skrev:

[quote=larsp (27)
Og hvis der er noget kode der er så indviklet at man mister overblikket bør man overveje at dele det mere op alligevel.
[/quote]

hvilket var grunden til citatet.
Gravatar #31 - arne_v
29. mar. 2020 14:15
larsp (29) skrev:

#28 min foretrukne indentation style er 4 spaces. Never tab. Allman style brackets. Der er den curly bracket style der er lettest at overskue IMO. Har aldrig kunne fordrage K&R style.


Det er jo religion.

Men jeg fortrækker:
* spaces fremfor tabs fordi ikke all editorer har tabs sat ens
* placering af { } efter hvad jeg anser som mest almindelig for det pågældende sprog (for C/C++ og C# er det Allman)

For 25 år siden brugte jeg mest 3 indrykning men idag er jeg overvejende skiftet til 4 indrykning fordi det er standard i mange editorer.

Sprog hvor position betyder noget må selvfølgelig behandles anderledes.
Gravatar #32 - Claus Jørgensen
30. mar. 2020 11:18
80 character limit giver heller ingen mening mere. Det var til dengang hvor folk havde utrolig små skærme.

I rigtig meget kode i dag starter man jo med et level indent bare til classes (eller 2, med namespaces). Så har du brugt de første 8 (eller 16) characters bare på indention.

120 characters er helt fint og læsbart.
Gravatar #33 - arne_v
30. mar. 2020 11:40
#32

Rigtige terminaler (VT220/VT320) var 24 x 80 eller i wide mode 24 x 132.
Gravatar #34 - Kian
30. mar. 2020 11:52
#26
Det er ikke min kode men jeg har oversat dele af https://github.com/melenaos/FileSystemSafeWatcher til VB.NET.
I C# er det i filen FileSystemSafeWatcher.cs på linje 404 og 411 hvor for-løkken starter og itererer to _events.Count
Men inde i samme for-løkke fjernes også items fra løkken - fx linje 416.

Koden virker fint i C#, men i VB.NET kan du ikke fjerne items fra listen. Så derfor har jeg omskrevet den del med en Do (Do While i < _events.Count og Do While j < _events.Count)
Gravatar #35 - arne_v
30. mar. 2020 12:56
#34

Den C# kode bruger en for loop - ikke en foreach loop.

En foreach loop vil smide en exception hvis man gør det samme.
Gravatar #36 - arne_v
30. mar. 2020 13:55
#35

De her to stykker kode opfører sig helt ens:


using System;
using System.Collections.Generic;

namespace E
{
public class Program
{
public static void Main(string[] args)
{
List<int> lst = new List<int> { 1, 2, 3, 4 };
Console.WriteLine(lst.Count);
for(int i = 0; i < lst.Count; i++)
{
if(lst[i] == 1) {
lst.Remove(lst[i]);
}
}
Console.WriteLine(lst.Count);
try
{
foreach(int v in lst)
{
if(v == 2)
{
lst.Remove(v);
}
}
}
catch (InvalidOperationException ex)
{
Console.WriteLine("Ooops");
}
Console.ReadKey();
}
}
}



Imports System
Imports System.Collections.Generic

Namespace E
Public Class Program
Public Shared Sub Main(args As String())
Dim lst As New List(Of Integer)() From { 1, 2, 3, 4 }
Console.WriteLine(lst.Count)
Dim i As Integer = 0
While i < lst.Count
If lst(i) = 1 Then
lst.Remove(lst(i))
End If
i = i + 1
End While
Console.WriteLine(lst.Count)
Try
For Each v As Integer In lst
If v = 2 Then
lst.Remove(v)
End If
Next
Catch ex As InvalidOperationException
Console.WriteLine("Ooops")
End Try
Console.ReadKey()
End Sub
End Class
End Namespace

Gravatar #37 - arne_v
30. mar. 2020 14:01
#36

Men jeg kan godt komme med et gæt på hvad der har givet fejl i VB.NET men ikke i C#.

Jeg har oversat:

for(int i = 0; i < lst.Count; i++)
{
...
}

til:

Dim i As Integer = 0
While i < lst.Count
...
i = i + 1
End While

I 98 ud af 100 tilfælde ville man have oversat til:

For i As Integer = 0 To lst.Count - 1
...
Next

Men det kan man ikke her. Dette er et af de tilfælde hvor en C/C++/C#/Java for loop altså er anderledes end en Basic/Fortran/Pascal For loop.
Gravatar #38 - dub
30. mar. 2020 19:39
#36 en ting er sikkert, kode skal en eller anden form af indent hvis skal kunne læses nogenlunde ;-)
if test then
tabsize = 0
man skal bruge spaces
end if

Yeah code tag virker. Det ville være lækkert hvis man fik en oversigt over hvilken tags man kunne bruge.
Gravatar #39 - arne_v
30. mar. 2020 19:50
#38

Koden er skam fint indrykket.

Men newz.dk viser den ikke indrykket. Heller ikke med code markup.

Gravatar #40 - dub
30. mar. 2020 19:51
#39 Det regnede jeg med

Hmm det virkede ikke

Test
Test2

Code tag bliver kun monospace men er ligeglad med whitespace. newz.dk fix det, damnit!
Gravatar #41 - Kian
31. mar. 2020 07:20
#37
Du har helt sikkert ret. Det har du iøvrigt alle dage haft lige siden start 00'erne på eksperten.dk :)

Anyways. Jeg skal simpelthen ha en VS for at læse den kode der - manglende indent er ulæseligt + at jeg er på arbejde nu :)
Gravatar #42 - arne_v
31. mar. 2020 17:09
arne_v (37) skrev:

Dette er et af de tilfælde hvor en C/C++/C#/Java for loop altså er anderledes end en Basic/Fortran/Pascal For loop.


Og for dem som vil se forskellen:


#include <stdio.h>

int getme3()
{
printf("getme3 called\n");
return 3;
}

int main()
{
int i;
for(i = 0; i < getme3(); i++)
{
printf("%d\n", i + 1);
}
return 0;
}



using System;

namespace Loop
{
public class Program
{
public static int GetMe3()
{
Console.WriteLine("GetMe3 called");
return 3;
}
public static void Main(string[] args)
{
for(int i = 0; i < GetMe3(); i++)
{
Console.WriteLine(i + 1);
}
}
}
}



public class Loop {
public static int getMe3() {
System.out.println("getMe3 called");
return 3;
}
public static void main(String[] args) {
for(int i = 0; i < getMe3(); i++) {
System.out.println(i + 1);
}
}
}



Imports System

Namespace MyLoop
Public Class Program
Public Shared Function GetMe3() As Integer
Console.WriteLine("GetMe3 called")
Return 3
End Function
Public Shared Sub Main(args As String())
For i As Integer = 1 To GetMe3()
Console.WriteLine(i)
Next
Console.ReadKey()
End Sub
End Class
End Namespace



program loop
integer*4 i
integer*4 getme3
do 100 i=1,getme3()
write(*,*) i
100 continue
end
c
integer*4 function getme3()
write(*,*) 'getme3 called'
getme3 = 3
end



program loop;

function getme3 : integer;

begin
writeln('getme3 called');
getme3 := 3;
end;

var
i : integer;

begin
for i := 1 to getme3 do begin
writeln(i);
end;
end.


(jeg regner med at folk selv kan identificere sprogene)
Gravatar #43 - Claus Jørgensen
1. apr. 2020 07:47
arne_v (33) skrev:
#32

Rigtige terminaler (VT220/VT320) var 24 x 80 eller i wide mode 24 x 132.

Ja, men det er jo noget pjat i 2020.
Gravatar #44 - arne_v
1. apr. 2020 14:51
#43

Ja. Verden har udviklet sig siden.

Pointen var at de 80 (og 132) bredde var en hardware ting dengang.

Det er også værd at bemærke at mange af de gængse sprog dengang ikke kunne udnytte flere kolonner.

Traditionel Fortran format:

1-5 labels
6 continuation tegn
7-72 kode
73-80 kommentar til brug for linienumre
Gravatar #45 - arne_v
2. apr. 2020 00:46
arne_v (31) skrev:

For 25 år siden brugte jeg mest 3 indrykning men idag er jeg overvejende skiftet til 4 indrykning fordi det er standard i mange editorer.

Sprog hvor position betyder noget må selvfølgelig behandles anderledes.


Dengang brugte jeg:

!
! FORTRAN tabulator stops.
!
procedure eve_fortran_tabs
eve_set_tabs("at 7 9 11 13 15 17 19 21 23 25 27 29 31 73");
message("Tabs set to FORTRAN.");
endprocedure;
!
! PASCAL tabulator stops (step 3).
!
procedure eve_pascal_tabs_3
eve_set_tabs("at 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46");
message("Tabs set to PASCAL (indent 3).");
endprocedure;
!
! MACRO tabulator stops.
!
procedure eve_macro_tabs
eve_set_tabs("at 9 17 41");
message("Tabs set to MACRO.");
endprocedure;
!
! TPU tabulator stops.
!
procedure eve_tpu_tabs
eve_set_tabs("at 5 9 13 17 21 25 29 33 37 41 45 49 53");
message("Tabs set to TPU.");
endprocedure;
!
! DCL tabulator stops.
!
procedure eve_dcl_tabs
eve_set_tabs("at 3 6 9 12 15 18");
message("Tabs set to DCL.");
endprocedure;
!
! Standard tabulator stops.
!
procedure eve_standard_tabs
eve_set_tabs("at 9 17 25 33 41 49 57 65 73");
message("Tabs set to default.");
endprocedure;

Gå til top

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.

Opret Bruger Login