Større .NET support til Visual Basic

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

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.

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.

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.

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.

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#.¨

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.

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.

Claus Jørgensen (16) skrev:

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

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".

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.

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.

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.

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

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.

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.

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

if test then
tabsize = 0
man skal bruge spaces
end if 

Test
Test2

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.

#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.

arne_v (33) skrev:

#32

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

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.