Co mě na C# opravdu štve a proč mám rád VB.NET?

Tomáš Herceg       27. 4. 2008       C#, VB.NET       7720 zobrazení

K sepsání tohoto článku mě vedlo z velké části to, že za poslední 2 měsíce jsem ve VB.NET nenapsal ani řádku a píšu všechno v C#. Dělám na projektu s několika lidmi, a tento projekt je v C#. Musím říct, že jsem si na C# zvyknul a platformu .NET bych v současnosti nevyměnil za nic na světě. Existuje ale několik málo věcí, které mě na jazyce C# štvou a díky kterým se u programování vztekám. Ve VB.NET jsem tyhle problémy prostě neměl, nemůžu si pomoct.

Neduh číslo 1 - o svých chybách chci vědět hned

Tohle je poměrně známá věc a zhruba před 2 lety jsem na blogu vývojářů VB.NET četl na toto téma pěkný článek. Když píšete ve VB.NET, uděláte na řádku nějakou chybu a pak zmáčknete ENTER, ihned na vás vyskočí hláška, pokud je na řádku nějaká chyba (a to jakákoliv chyba, ne jen chybějící závorka nebo středník, které jsou v C#). Je pravda, že ve VB6 vyskočil opravdu MessageBox, což bylo dost otravné a byla to první věc, kterou jsem po nainstalování vypínal v nastavení. Ve VB.NET se jenom dole v podokně Error List objeví řádek, že máte něco špatně. Na tohle si člověk zvykne hodně rychle a je to mimořádně pohodlné. Chybu můžete opravit hned, jak nastane, a neuděláte ji na deseti dalších místech.

V C# se vám všechny chyby objeví až ve chvíli, kdy zmáčknete Ctrl-Shift-B, tedy Build, případně F5. Je pravda, že když na řádku použijete proměnnou, kterou chcete v zápětí o tři řádky výše nadeklarovat (někdo holt píše kód odzadu :-), hází na vás VB.NET hned chybové hlášky, kdežto C# vás nechá být. Ale pak se vám stane, že čekáte, že vám nějaká funkce, kterou jste psali před měsícem, vrací pole objektů Segment, ale ona ve skutečnosti vrací List<Segment>. Nu což, kompilátor nic neřekne, takže si napíšete několik delegátů a spoustu funkcí, které chtějí pole, a pak na vás v nestřeženém okamžiku vybafne 30 chyb. Pro ty, kteří by mi poradili, abych na výsledek funkce jednoduše zavolal ToArray, čímž bych z Listu udělal pole, musím připomenout, že o metodě ToArray vím a nepoužil jsem ji, protože vnitřně kopíruje celé pole, což se mi zrovna nehodí.

A navíc pak ještě zapomenete projekt buildnout a hned ho check-innete na Team Foundation Server i s chybami a ráno vám všichni nadávají, že jim to nejde zkompilovat. Já vím, dá se TFS nastavit tak, aby tohle nepovolil, ale my to nastavené zrovna nemáme. Ve VB.NET se tohle stát nemůže, o svých chybách vím prostě hned.

Neduh číslo 2 - přetypováváme jako o život

Ve svém projektu mám strukturu Vector3D, která má jednoduše 3 public proměnné typu float - X, Y a Z. Property jsem v tomto konkrétním případě nedělal (ony tam vlastně původně byly a pak jsem je dal pryč). No, jak spočítat délku toho vektoru? Přes Pythagorovu větu, že? No nic, tak napíšeme readonly vlastnost Length, která vrátí délku:

return Math.Sqrt(X * X + Y * Y + Z * Z); 

No tohle samozřejmě nejde, že? Protože Math.Sqrt vrací double. Jenže já potřebuji float, když máte vektorů stovky tisíc, tak na každém bajtu paměti mi záleží a tak velkou přesnost zase nepotřebuji. Musím přetypovávat, protože se mi převodem double na float ztrácí přesnost. Já to ale přece vím a tak to taky chci, už jsem říkal, že float mi stačí.

A takových situací jsou tisíce, pak je ve výrazu víc přetypování než matematických operací. Anebo máte funkci, která jako parametry bere inty, ale vy zrovna máte všechno ostatní ve floatech. Zase musíte přetypovávat.

Nebo vydělím dvě čísla a pořád se divím, jaktože je výsledek nula? No jistě, ony to byly inty, a tím pádem bylo dělení celočíselné, přestože výsledek přiřazuji do proměnné typu Double. Ale hledejte to, kde se to stalo.

Ve VB.NET přetypováváte jenom když je to opravdu potřeba. Pokud mám komponentu poděděnou od třídy Control, tak samozřejmě přetypováváme vždy na ten typ komponenty, pokud chceme pracovat s její specifickou vlastností. Ale proč má být téměř v každém matematickém výrazu přetypovávání? A na celočíselné dělení má VB.NET speiální operátor zpětné lomítko. To je podle mě ideální řešení, nadměrné přetěžování operátorů nemám moc rád.

Neduh číslo 3 - zlaté With bloky

Takto vypadající bloky kódu mě opravdu iritují:

this.WindowContainer.formViewRectangleEditor.textBox1.Text = "ahoj";
this.WindowContainer.formViewRectangleEditor.textBox1.Width = 330;
this.WindowContainer.formViewRectangleEditor.textBox1.Height = 50;
this.WindowContainer.formViewRectangleEditor.textBox1.ForeColor = Color.SkyBlue;

Občas potřebujete nějakému zanořenému objektu nastavit víc vlastností. Takhle to vypisovat je šílené. Tak dobře, můžete udělat tohle:

 TextBox textBox1 = this.WindowContainer.formViewRectangleEditor.textBox1;            
textBox1.Text =
"ahoj";
textBox1.Width =
330;
textBox1.Height =
50;
textBox1.ForeColor = Color.SkyBlue;

No ale to jde za předpokladu, že TextBox je třída. A co když je to strkutura? No to se pak ale moc divíte, že všechno správně nastavíte, ale když na konec ještě změny v proměnné nepřiřadíte zpátky, původní struktura zůstane nezměněná, prostě jste si jenom upravili nějakou proměnnou.

VB.NET má pro tohle speciální syntaktický konstrukt - With blok:

 With Me.WindowContainer.formViewRectangleEditor.TextBox1
     .Text =
"ahoj"
     .Width =
330
     .Height =
50
     .ForeColor = Color.SkyBlue
End With

Podle mě je to přehlednější a rozhodně lepší než první příklad s neustálým opisováním. A funguje i na struktury.

Možná si říkáte, že už zase vymýšlím kraviny, tak nemám struktury používat, vždyť přece máme třídy, které toho umí daleko víc. Mám k tomu ale své důvody, někdy prostě struktura stačí, nehledě na to, že jsou rychlejší. Někdy prostě struktury potřebujete. Třeba zrovna moje již zmiňovaná struktura Vector3D, tady potřebuji, abych si mohl se souřadnicemi šachovat uvnitř nějaké funkce, ale nezměnil tím vektor ve funkci, která tu vnitřní funkci zavolala.

Neduh číslo 4 - proklaté středníky

Ne, nekamenujte mě za to, není v tom nic osobního. Vyrostl jsem na BASICu, takže mi středníky prostě přijdou nelogické. Jedním z argumentů je to, že se to kompilátoru dobře parsuje. Kde je ale ta hranice? Nemáme teda začít psát v postfixu, aby to měl kompilátor ještě jednodušší?

Poznámka na okraj - postfixový zápis znamená, že nejdřív píšete parametry a pak funkci nebo operátor. Třeba 3 5 + je postfixový zápis součtu trojky a pětky, nejprve hodnoty a pak operátor. Pro kompilátor nebo interpret je to jednoduché - čte hodnoty a dává je na zásobník, když narazí na funkci, vezme si ze zásobníku tolik argumentů, kolik potřebuje, provede funkci a výsledek vrátí zase na zásobník. Výhoda je, že nepotřebujete závorky, a naimplementovat tohle je výrazně jednodušší.

Na středníky prostě nejsem zvyklý, podle mě je to zbytečný znak, když je v 99% případů za ním stejně konec řádku. V zásadě můžou nastat dva výjimečné případy - víc příkazů na jednom řádku, anebo jeden příkaz na několika řádcích. VB.NET umí oba dva případy řešit - více příkazů na jednom řádku se odděluje dvojtečkou, a jeden příkaz rozdělíte na víc řádků pomocí sekvence mezera podtržítko.

Co to ten VB vymýšlí za hlouposti a proč má tak divnou syntaxi? Je to dáno dobou jeho vzniku, jazyk BASIC byl vytvořen někdy kolem roku 1964, kdežto céčko až v roce 1972. Syntaxe většiny dnešních jazyků je odvozena od syntaxe céčka, ta je totiž velmi oblíbená. Syntaxe Visual Basicu je sice od původního BASICu hodně odlišná (řádky už opravdu nečíslujeme, jako za starých časů), ale základní myšlenky zůstaly.

Neduh číslo 5 - milion usingů na začátku

Pokud máte rozsáhlejší projekt, tak většinou prvních několik hodně řádků v C# tvoří bloky using namespace. V projektu, na kterém dělám teď, potřebuji v každé třídě nejméně 10 různých namespaců, ať už jsou to naše vlastní, nebo i ty z .NET frameworku.

Ve VB.NET můžete zaškrtnout ve Visual Studiu namespaces, které chcete používat v celém projektu, a pak je nemusíte psát na začátek každého souboru. Většinou si zaškrtnu jen ty, které potřebuji opravdu všude, a vypisouji do souborů jenom ty, které využívám jen příležitostně.

Abych jenom nechválil VB.NET

Je samozřejmě spousta věcí, které mě štvou na VB.NET. Největším problémem je to, že je strašně ukecaný. Místo toho, abyste napsali int a musíte napsat Dim a As Integer. Ve skutečnosti sice namačkám jen d a a in a Visual Studio mi zbytek doplní samo, ale to už je výhoda prostředí a upovídanost jazyka to neomlouvá.

Další věc, která mě štve, je to, že VB.NET není case sensitive. Je mimořádně pohodlné pojmenovat privátní proměnné uvnitř třídy na začátku s malým písmenem a k nim patřící veřejné property písmenem velkým. Ve VB.NET to většinou řeším podtržítkem před privátní proměnnou, což se mi ale moc nelíbí a nevypadá to hezky.

Prostředí C# má také lepší refactoring, do VB.NET musíte doinstalovat speciální nástroj třetí strany (který toho umí mírně víc), který je naštěstí zdarma, ale v základní výbavě má VB.NET jenom funkci na přejmenování.

Ale jinak si stejně pořád myslím, že VB.NET má něco do sebe a zvlášť pro začátečníky je jednodušší - neztratí se ve 4 druzích závorek a nemusí se jim vysvětlovat, proč je v tak jednoduchém výrazu pět přetypování. Díky tomu, že VB.NET i C# běží nad stejnými knihovnami, kód je víceméně identický, až na syntaktické detaily. Existuje také mnoho konvertorů.

 

No zkrátka mám VB.NET opravdu rád. V C# se mi programuje taky dobře, ale ve VB.NET mírně lépe. Nejlepší by ale asi byl C# bez přetypovávání, usingů a s okamžitým hlášením chyb a with bloky. Středníky mi zase až tolik nevadí a stručná céčková syntaxe není špatná. Ale i tak dnes má smysl psát ve VB.NET, je jednodušší na naučení a některé věci jsou v něm prostě lepší.

 

hodnocení článku

1 bodů / 1 hlasů       Hodnotit mohou jen registrované uživatelé.

 

Nový příspěvek

 

Diskuse: Co mě na C# opravdu štve a proč mám rád VB.NET?

Náhodou jsem narazil, na tento článek a musím říct, že mi ty Vaše důvody připadají opravdu komické.

1. no dobře, C++ na Vás

2. přetypování, C++ na Vás. Pokud potřebujete každý bajt, spletl jste si jazyk i platfotmu

3. Ti co umí používat clipborard to mají napsáno rychleji, otázka přehlednosti je dosti diskutabilní

4. Taky jses vyrostl na BASICu (Atari Basicu) a se středníky nemám nejmenší problém

5. ta Vaše výhoda je výhoda imho jenom imaginární, ve větších projektech takovýhle globální namespaces muže udělat jenom pěknej nepořádek. Navíc ty usingy co potřebujete opravdu všude doplňuje VS.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Proč máte potřebu všem na potkání cpát C++? Znám výhody C++ a taky vím, proč jsem si ho nevybral. Na spoustu projektů se prostě nehodí a to, co dělám právě teď, je jeden z nich. Navíc zrovna poznámky o přehlednosti a čistotě kódu jsou od člověka, který propaguje C++, dost zvláštní. Na každém bajtu nám nezáleží, ale tou pamětí nemusím zrovna plýtvat. I v .NET frameworku se dá napsat výkonná aplikace, když se to umí.

Dále nechápu, proč je potřeba každému to přetypování nutit, když to může efektivně najít a udělat sám přímo kompilátor (nedělá se to za běhu, jediný rozdíl je v tom, že to nemusíte vypisovat ručně). Když dělím dvě celá čísla a výsledek přiřazuji do doublu, je snad jasné, že chci dělit desetinně. Tak proč kvůli takové hovadině musím přetypovávat? Akorát to zesložiťuje a znepřehledňuje kód, zvlášť když u delších výrazů máte deset přetypovávání.

To, že umíte používat clipboard je opravdu obdivuhodné, to bych do vás neřekl. Nevím konkrétně, na co narážíte, pravděpodobně na With blok, ale to, že to C# neumí, je podle mě škoda. Čím víc kódu, tím menší přehlednost, a deset řádků se stejným začítkem přes půl obrazovky, no nezlobte se na mě, ale to se mi nelíbí.

Středníky jsou samozřejmě věc zvyku, já samozřejmě v C# píšu, ale to nic nemění na tom, že je nemám rád. Jde čistě o můj názor.

Ano, usingy sice Visual Studio doplňuje, ale to nic nemění na tom, že na začátku každého souboru máte pak 20 usingů a to není nic moc. Alespoň 15 je jich v každém souboru stejných a liší se zbytek, tak proč těch 15 vypisovat všude?

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Připomínáte mi ženskou, která hodnotí auto a jako nejvetší problém, který vídí je, že má špatnou barvu a nemá zrcátko u spolujezdce.

C++ neobhajuji. Jenom jsem uvedl kontrast, aby jste viděl, že vaše "problémy" s C#em jsou jsou úsměvné. Pokud kód po sobě nepřečtete kvůli dlouhým nepřehledným výrazům, použijte základy refaktoringu. Kód se nepatrně zpomalí, nebo to často optimalizace dožene.

Pokud má někdo v každém souboru 15 usingů, nesvědčí to o ničem jiném, než o špatném návrhu aplikace, který má kořeny právě v takových "features" jako jsou globální usingy.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

pardon

cicobasket

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Pokud jste nikdy nedělal velký projekt, tak neodsuzujte 15 usingů v jednom souboru. Naše solution skládá z mnoha projektů a všechno je rozdělené na vrstvy a těch namespaces je opravdu asi 15. To není žádný špatný návrh, vše je akorát úzce provázané a abychom neměli smečku stovek tříd v jednom namespace, dali jsme tomu nějakou hierarchii. Neznáte detaily, tak nekritizujte návrh.

Nikdy jsem nenapsal, že po sobě kód nepřečtu, protože je dlouhý. Na globálním usingu podle mě není nic špatného, pokud se používá rozumně a necpe se do něj všechno.

Nevím také, co má refactoring společného s tím, co jsem popisoval v článku, jde totiž o úplně, ale úplně neco jiného. Prostě mi přijde úchylné pořád vypisovat něco jako něco.něco.něco.něco.něco.něco na 10 řádcích pod sebou, když můžu mít with blok, napsat to jenom jednou, a pak přistupovat k tomu objektu v té hierarchii bez neustálého opisování. Pokud je to objekt, dá se to obejít tak, že si ho na začátku vytáhnu do proměnné, u struktury to už ale neuděláte. To píšu v článku.

Neříkám, že C# je špatný a také netvrdím, že to jsou zásadní nedostatky. Jsou to ale věci, které mě prostě štvou. Žiji s nimi, ale mám právo, aby se mi něco nelíbilo, a abych se snažil poukázat na ně. Nepopírám, že spoustě lidí je Visual Basic proti srsti, ale 90% takových lidí má vůči tomuto jazyku averzi doslova nesmyslnou, navíc způsobenou tím, že o něm nic neví. I já mám vůči VB.NET určité výhrady, něco je tam vyřešeno lépe a něco hůře.

A urážky si laskavě nechte od cesty.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Můžu Vás ubezpečit, že v opravdu velkých projektech jako je třeba tento

http://www.helios.eu/heg-pro-velke-spole...

nepřesahuje počet usingů desítku(počet namespaců desítky). Když máte 15 namespaců a musíte použít 15 usingů i kdyby třeba v jednom cs souboru, tak to prostě implikuje problém.

Vaše názory na problémy se C#em Vám neberu, jen je považuji za úsměvné. Od vývojáře bych prostě čekal konstruktivnější připomínky než je způsob zápisu.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No, řekněme, že náš projekt používá daleko více technologií, např. ASP.NET, XNA, Winforms, Silverlight a mnoho dalších, vše je tam provázané a pak máme spoustu vlastních vrstev. Neříkám, že všechny usingy jsou ve všech souborech stejné, ale poměrně velká část se jich opakuje.

Co se týče C#, jiné připomínky, než tyto drobnosti, nemám, proto kritizuji jenom syntaktické věci. Na druhou stranu právě způsob zápisu je dost podstatný, protože s ním se člověk potýká neustále.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Co mě na C# opravdu štve a proč mám rád VB.NET?

Ještě je jedna věc, která mě mimořádně vadí: Jakmile je v C# na jediném řádku chyba, tak okamžitě přestane fungovat IntelliSense a automatické formátování v celém kódu. Totální humus...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Pokud je ta chyba vážnější, tak ano. Ale většina chyba to nedělá.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Bohatě stačí chybějící středník nebo zapomenutá závorka což rozhodně není vážnější chyba. Podobné překlepy inteligentní Visual Basic většinou opraví automaticky a rozhodně u něj nepřestane fungovat IntelliSense.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

To je otázka názoru. Právě toto chování mi přijde dobré, protože že si uvědomíte, že tam máte chybu a nejedete dál s chybou.

cicobasket

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Zajimave, tohle se mi (krome pripadu, kdy mam na blbem miste napsane slozenice navic pripadne nejake zapomenute - a ani to neshodi intellisense na celem kodu) jeste nestalo. Zapomenuty strednik se mi okamzite oznaci cervenym podrzenim, stejne jako jine vazne syntakticke chyby (nespravny pocet zavorek u slozitejsiho volani fci a tak). Na druhou stranu intellisense nemuze vestit, co asi programator zamyslel a tak, kdyz proste napise o par zaviracich slozenic navic, tak se nemuze divit, ze mu nefunguje intellisense protoze uz je mimo class blok.

Ono staci jen pri psani kodu se koukat na monitor, co vlastne pisu a s intellisense problem neni.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No, zřejmě jste nikdy nenapsal ve VB.NET ani čárku takže nemá cenu s vámi dále diskutovat o kvalitě IntelliSense a automatických oprav v C# a ve VB.NET... Kdybyste programoval profesionálně, dříve nebo později byste zjistil, že výše uvedené nedostatky C# vyloženě brzdí v práci.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

i) VB.NETova syntaxe se mi nelibi a tak jsem v tom skutecne nikdy nenapsal ani carku (krome VBA skriptu v Accessu, s kterymi jsem si hral na zakladce)

ii) Nesrovnavam c# a vb.net intellisense a pokud to v mem prispevku vidite, tak se podivejte jeste jednou.

iii) V praci me brzdi spousta jinych veci (padani VS 2008, pomalost VS, houkani sanitek ...) podstatne vice nez to, ze mi vypadne intellisense na nejakem zdeformovanem kodu, ktery nepisu, nebot me ucitelka cestiny v dobach, kdy jsem jeste chodil na gympl, naucila cist po sobe to, co napisu. Velmi tento postup doporucuji.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Já se snažím usnadnit si práci pomocí prostředků dostupných ve Visual Studiu, mezi které patří i IntelliSense a automatické opravy (které jsou použitelné pouze ve VB.NET). Potom mě nic nenutí číst po sobě kód jen proto, abych někde doplnil zapomenutou závorku. Když už jste měl tak dobrou učitelku češtiny, možná vás také mohla naučit psát s diakritikou.

nahlásit spamnahlásit spam -1 / 1 odpovědětodpovědět

Nevím, jak je to ve starších verzích C# (2005 a níže), ale ve verzi 2008 opravdu zapomenutý středník nebo kulatá závorka IntelliSense nerozhodí (teď jsem to zkoušel).

A nemusíte se hned kvůli takové pitomosti hádat, spousta věcí je lepších ve VB.NET a spousta zase v C#.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

To je otázka názoru. Právě toto chování mi přijde dobré, protože že si uvědomíte, že tam máte chybu a nejedete dál s chybou.

cicobasket

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Co mě na C# opravdu štve a proč mám rád VB.NET?

Naprostý souhlas se všemi vámi uvedenými nedostatky C#. Ještě bych přidal milion složených závorek.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No, to je taky fakt, člověk pak neví, která ke které patří. Jinak s těmi podtržítky před proměnnými je to pravda, používá se to, ale nelíbí se mi to. Nevypadá to esteticky pěkně. Ale co se dá dělat.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

visual studio vam ale zvyrazni uzaviraci a otviraci zavorky kdyz na ne najedete mysi...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

To jo, ale i na mém rozlišení 1920x1200 se mi bohužel stává, že blok je příliš dlouhý a prostě nevidím, jestli je to ta závorka od foru nebo ifu. Ve VB.NET to poznáte - máte End If, Next (konec For cyklu), End Function atd.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

ctrl+}

cicobasket

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Co mě na C# opravdu štve a proč mám rád VB.NET?

Opravdu zajímavé. Zavzpomínal jsem si na svoje začátky ve VB4 - VB6 :-)

A s některými výtkami nezbývá než souhlasit.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Co mě na C# opravdu štve a proč mám rád VB.NET?

Ještě jsem si vzpomněl, že na VB.NET mě štve, že nemá konstrukci yield return jako C#, je velice užitečná, pokud chcete vracet nějaké kolekce nebo seznamy hodnot.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Co mě na C# opravdu štve a proč mám rád VB.NET?

Pekný článok.

Len jedna výhrada. To, že VB nie je case sensitive by som nepokladal za nevíhodu. To s tými podtržníkmi hádam nemyslíte vážne. Nedávno som trošku pátral po tom ako nazývať premenné podľa nejakého štandardu. Používal som hungarian codex, ktorý ako som zistil už v .net frameworku nemá svoje miesto. Namiesto toho sa dá na MSDN stránkach nájsť pomerne podrobný návod ako pomenuvávať svoje premenné, metódy atp. Bohužiaľ teraz to už na rýchlo neviem nájsť. Našiel som iba túto stručnú verziu.

http://msdn2.microsoft.com/en-us/library...

PS : Ja používam na private premenné camel case a predponu "my" a pre public ten istý názov bez predpony.

Private myUzivatel as string
Public uzivatel as string

Vašo.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

To, že VB.NET není case sensitive, je nevýhoda. A velká.

Private data As Integer
Public Property Data As Integer
    Get
        Return data
    End Get
    Set(ByVal value As Integer)
        data = value
    End Set
End Property

Tohle prostě nemůžete napsat, ve VB.NET to nejde. Nemůžete mít vlastnost s názvem Data, která manipuluje s proměnnou data. Proto tam musím mít to podtržítko, nebo případně to vaše my, ale to už je víceméně jedno, pořád tam něco musí být. Tento problém C# nemá.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Case senzitivita která mě zezačátku vadila mi nyní ve Visual Basicu velmi chybí. Jinak používání podtržítek je zcela běžné, podívejte se Reflectorem na nějakou frameworkovou třídu a budete překvapen že je to použito téměř všude.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Popravde aj ja som podtržítka nejaký čas používal. Ale potom ako som si prečítal, že ich použitie nie je najvhodnejšie som od nich upustil. Kod je s nimi o poznanie neprehladnejší.

nahlásit spamnahlásit spam 0 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.

Nyní zakládáte pod článkem nové diskusní vlákno.
Pokud chcete reagovat na jiný příspěvek, klikněte na tlačítko "Odpovědět" u některého diskusního příspěvku.

Nyní odpovídáte na příspěvek pod článkem. Nebo chcete raději založit nové vlákno?

 

  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback