Jag blir så trött! Jag bråkar dagligen med ett par kollegor som med bestämdhet hävdar att man inte alls behöver Option Strict i VB.net. "Det blir bara en massa onödig kod", hävdar de.

Jag har inte brytt mig så mycket, men nu ska jag hjälpa till i ett projekt och drabbas av detta.

Ge mig lite BRA argument varför man SKA har Option Strict påslaget!

Typsäkerhet, du får inga implicita (omedvetna) typkastningar som VB annars gör.
Ex:
<code>
Dim s As String = "Nu skiter det sig"
Dim i As Integer

i = s
</code>
med Option Strict Off så "funkar det" tills du kör programmet.med Option Strict On så kan du inte ens kompilera, du måste isåfall andra koden till i=Integer.Parse(s) och då är du medveten om att du gör en typomvandling, och kanske tänker du på att s är en sträng och kan innehålla skräp och lägger då till en kontroll av strängen innan den omvandlas.
Så du kommer (förmodligen) att få färre buggar i koden med Option Strict On.

Ledsen Morgan, de där argumenten håller inte.

Det är ju ingen skillnad på dessa:

Option Strict = Off

Dim s As String = "Nu skiter det sig"
Dim i As Integer

i = s

Option Strict = On

Dim s As String = "Nu skiter det sig"
Dim i As Integer

i = cInt(s)

Säg att s hade varit innehållet i en textbox som man bara får skriva tal i:

s = Textbox1.Text

Då hade man fått samma problem oavsett vilket av exemplena som man använt. Alltså får man - som de hävdar - bara mer kod. I detta fallet visserligen bara "cInt(...)".

i = s

Betyder : Jag är dum i huvvet och fattar inte att det kan bli fel.

i = CInt(s)

Betyder : Jag är lite smart och fattar att det KAN bli fel här...
Det jag KANSKE gör då är att jag skiter i Option Strict och kodar min felhantering ändå. och då är jag lite smartare. Men man riskerar att missa ställen där det kan bli fel.
Det smartaste är att köra Option Strict OCH koda felhanteringen. Visst, det blir mer kod, men bra kod...
INGEN är perfekt, man missar alltid något. Detta är en hjälp att hitta felen (visa av dem)

Dessutom heter det Integer.Parse(s) - CInt ligger i VisualBasic - Namespacet och är följdaktligen OND!

/micke

Det klassiska exemplet är väl just när man använder plustecknet i stället för &-tecknet för att konkatenera strängar:
<code>
Dim s As String = "1"
Dim i As Integer = 0

MessageBox.Show(s + i)
</code>
I detta läget är det inte lätt att veta vad kodarens intentioner var. Ville han slå ihop strängarna "1" och "0" och därmed få ut "10"? Eller ville han summera talen 1 + 0 och få ut siffran 1?

Jag var tvungen att testköra exemplet för att veta vad VB skulle skriva ut, och det visade sig att det blev "1" och inte "10". Detta är ett typexempel på hur fel det kan gå utan Option Strict On.

Det blir ju även "mer kod" att skriva om man har långa beskrivande variabel- och funktionsnamn. Och gillar man inte att skriva mycket kod så skall man ju dessutom inte koda VB överhuvudtaget eftersom det är jobbigare att skriva END IF i stället för }.

Det handlar om att skriva TYDLIG, BUGGFRI och LÄTTUNDERHÅLLEN kod. Det gör man genom att visa tydligt vad man vill. På samma sätt skulle jag aldrig deklarera en variabel utan datatyp och inte heller strunta i public/private framför funktioner. Jag har inte ens lärt mig vilket som är default...jag skriver helt enkelt inte kod som förutsätter att man vet att vilken typkonvertering som kommer att ske, eller vilket scope som är default, eller vilken datatype som är default om man inte anger en typ.

Säg åt dina kollegor att sluta tracka dig och stå på dig. Det är direkt oansvarigt att skriva fulkod när man vet att andra programmerare skall underhålla skiten i framtiden...Det är lika omoraliskt som att parkera på handikapplatser, rycka vingarna av små insekter och att klubba sälar. Kort sagt förkastligt...

Puuh! Ok, jag har lugnat ner mig nu... :-)

Tala bara om var du jobbar Mathias, så ska jag undvika stället som pesten.
Att arbeta med INKOMPETENTA kollegor är det värsta jag vet.

Att inte använda option strict är att be om problem.
End of story

Jovisst.
Men med Option Strict ON på den första så blir det kompileringsfel och det uppmärksammar iallafall utvecklaren på att det behövs en typomvandling, och förhoppningsvis så lägger han/hon också till kod som kontrollerar att man kan göra omvandlingen innan man försöker göra den.
Men som sagt, det går ju inte att hindra någon från att göra korkade/fel saker i koden så länge man följer syntaxen.

Ifall man vill ha ett leksaks-språk så ska man naturligtvis inte ha Option Strict påslaget.

Ifall man däremot vill att VB.NET ska bete sig som ett riktigt kompilerat språk, och utnyttja kompilatorns finesser för att skriva bättre kod, då ska man ha Option Strict och Option Explicit påslagna.

De riktigt hårda grabbarna ställer även in så att alla varningar behandlas som fel. :)

Option Strict är en kompileringsflagga. Hjälpen den ger är helt enkelt att den redan vid kompileringstilfället talar om när en typkonvertering behövs. Det innebär att man förhoppningsvis inte får för många runtime cast fel.

Det här är det enda den är till för. Information vid kompilering.

> Dessutom heter det Integer.Parse(s) - CInt ligger i VisualBasic

Jaha, och hur mycket mer kod blir inte DET! :)

Mathias,

Skillnaden är att du har lite olika beteende med att använda de olika converterings möjligheterna så som Integer.Parse och Convert.ToInt32 .. detta kan du inte mappa till CInt och känner man inte till de underliggande skillnaderna så kan man heller inte kontrollera beteende i koden.

>> Dessutom heter det Integer.Parse(s) - CInt ligger i VisualBasic

>Jaha, och hur mycket mer kod blir inte DET! :)


Det var inte mer kod som var syftet här. Det var att Namespacet VisualBasic är OND som var det viktiga. MEN det är ju ett känt faktum att VB-programmerare över lag är lata och slöa, vill inte skriva kod och bryr sig inte om hur det funkar - bara det finns en wizard som löser det med minsta möjliga skrivinsats.

En bra programmerare återanvänder mycket kod.
En dålig programmerare skriver lite kod många gånger.

/micke (VB-programmerare)

>> Dessutom heter det Integer.Parse(s) - CInt ligger i VisualBasic
>
> Jaha, och hur mycket mer kod blir inte DET! :)

Det blir faktiskt mindre kod. Eftersom CInt använder Integer.Parse så blir det mindre kod som körs om man anropar Integer.Parse direkt.

Ju mer man vet om vad som egentligen händer med den kod man skriver, desto effektivare kod kan man skriva.

Om man till exempel vet hur inkapsling (boxing) fungerar, så vet man varför den här koden:

name = "Lag " & i.ToString()

är effektivare än den här:

name = "Lag " & i

(där i är en Integer.)

Du har ju helt rätt Göran - Men all kod som genereras automatiskt är (enligt Mattias kollegor) bra kod. Det är skrivandet som skall minimeras.

Tangentbordsskräck?

/micke

För det första så är inte automatgenererad kod autoamtiskt av ondo, oavsett om det sker i VB.NET, C# eller något annat språk. Om man undviker det av den anledningen så går man miste om väldigt många bra saker med med största sannolikhet kostar man sin arbetsgivare och/eller kund väldigt mycket pengar eftersom man är naiv och föredrar att skriva allt för hand. Men nog om det, tillbaka till <b>CInt</b>

CInt mappar inte alls till <b>Integer.Parse</b> som det sagts. VB.NET kompilatorn mappar om det till en metod vid namnet <b>FromString</b> som är en statisk (<b>Shared</b>) metod i klassen <b>IntegerType</b> och återfinns i namnrymden Microsoft.VisualBasic.CompilerServices

Tar vi oss sedan en titt på implementationen av FromString så ser vi följande

[VB.NET]

Public Shared Function FromString(ByVal Value As String) As Integer
      Dim num1 As Integer
      If (Value Is Nothing) Then
            Return 0
      End If
      Try 
            Dim num2 As Long
            If StringType.IsHexOrOctValue(Value, num2) Then
                  Return CType(num2,Integer)
            End If
            num1 = CType(Math.Round(DoubleType.Parse(Value)),Integer)
      Catch exception1 As  FormatException
            Throw New InvalidCastException(Utils.GetResourceString("InvalidCast_FromStringTo", Strings.Left(Value, 32), "Integer"), exception1)
      End Try
      Return num1
End Function

Vad händer här då. Det första som görs är en kontroll av null (Nothing) värde varpå man retunerar noll. Detta är samma beteende som metoden <b>Convert.ToInt32</b> har. Nästa sak som sker är en kontroll om det inskickade värdet är hexadecimalt eller en octet. Nästa bit är den intressanta.

Först konverteras värdet till en double, varpå man rundar av för att sedan typkonvertera tillbaka till ett heltal. Kontentan är, enligt mig, inte att själva importen eller utnyttjandet av Microsoft.VisualBasic assemblyn som är så farligt - tvärt om så finns det många gobitar i den. Nä, problemet med CInt är att den gång en del omvägar för att lista ut vad man som programmerare vill göra vilket blir en prestanda post vid upprepad användning.

Användande av Integer.Parse och Convert.ToInt32 ger bättre kontroll till en effektivare implemnatation. Sen vill jag påpeka att den största "faran" med Microsoft.VisualBasic är ett den har många saker som ovan som gör att programmerare (speciellt eftersom t.ex CInt markerar som ett keyword i VB.NET editorn) inte känner till den underliggande implementationen och kan avgöra hur det fungerar, samt att eftersom CInt finns varför skulle man använda Integer.Parse eller Convert.ToInt32? Man uppmuntras inte att utforska ramverket när för mycket kaplas in i idiotsäkra wrappers.

Allt är inte av ondo för känner man till hur sakerna i Microsoft.VisualBasic fungerar så kan (och ibland bör) man använda sig av dessa för att minimera utvecklingstiderna, samt att det inte alltid är så avgörande om det tar några millisekunder längre då det kanske inte är en applikation som kräver väldigt god prestanda - och nej jag säger inte att genom att använda CInt och company så får man alltid applikationer med lägreprestanda, vanligtvis finns det andra mer intensiva moment i en applikation som man tjänar på att optimera än att plocka bort lite CInt och andra wrappade uppgifter.

Där ser man... mycket värre än jag befarade...

Göran,

Vill bara påpeka en sak angående en av de saker du skrev i ett tidigare inlägg

<b>Ju mer man vet om vad som egentligen händer med den kod man skriver, desto effektivare kod kan man skriva.</b>

Skulle vilja påstå att detta inte är sant. Om du inte har någon som helst aning hur det du anropar är implementerat, samt har lite kolla på den MSIL som genereras så är det även svårt att snacka om effektivare kod. Givetvis kan man också profilera koden och få ut lite mätvärden för att påvisa att något är effektivare.

Mindre kod betyder inte alltid effektivare kod. Ta bara en så enkel sak som sammanslagningen av strängar som har betydligt bättre prestanda om man går via en <b>StringBuilder</b> än att bara slå samman dem.

För att kunna diskutera effektivitet så måste man även ange vad man mäter. Är det prestanda, dvs. tiden det tar att exekvera, eller är det utnyttjtandet av resurser mm. Inte helt trivialt när det inte är i ett sammanhang (japp, är medveten om att det på tal om CInt här).

> Vill bara påpeka en sak angående en av de saker du skrev i ett tidigare inlägg
>
> <b>Ju mer man vet om vad som egentligen händer med den kod man skriver, desto effektivare
> kod kan man skriva.</b>
>
> Skulle vilja påstå att detta inte är sant. Om du inte har någon som helst aning hur det du anropar är
> implementerat, samt har lite kolla på den MSIL som genereras så är det även svårt att snacka om
> effektivare kod.

Jag förstår inte ditt resonemang. Skulle det vara helt ovesäntligt med kunskap om vad som händer när koden körs för att skriva effektivare kod?

Jag måste säga att jag inte riktigt förstår din meningsbyggnad heller. Kan du formulera om det där?

> Givetvis kan man också profilera koden och få ut lite mätvärden för att påvisa att något är effektivare.

Bygger ditt resonemang på att mitt påstående är falskt därför att det inte är den enda metod som finns för att avgöra ifall koden är effektiv eller inte?

> Mindre kod betyder inte alltid effektivare kod.

Det har jag heller aldrig sagt. Tvärtom så visade jag i mitt inlägg ett exempel på raka motsatsen.

Göran,

Jag ber ödmjukast om ursäkt. Klockan var "mycket" (vilket vi också kan se på skriftspråket, hehe) och jag läste helt enkelt fel på meningen som jag så snyggt själv citerade :-D