vb10 _

O noutate în Visual Basic 10 care a paralizat planeta la aflarea ei și la care savanții americani, indieni, chinezi și români au lucrat din greu 3 ani este posibilitatea de a scrie cod VB fără a mai specifica prin caracterul _ (underscore) cînd vrei să continui o linie logică pe următoarea linie de pe ecran.

Paranteză pentru necunoscătorii de Visual Basic.

Dacă vrei să te împrăștii pe două linii cu următoarea atribuire:

x = x * (2 + a) * (3 + b)

în Visual Basic se face cam așa:

x = x * (2 + a) * _

(3 + b)

Liniuța de subliniere din dreapta primei linii îl informează pe compilator că treaba nu s-a terminat, mai urmează ceva pe linia următoare.

Paranteză: de ce e nevoie de asta? Pentru că spre deosebire de C# de exemplu, unde compilatorul află explicit că linia s-a terminat din cauză că FIECARE (aproape) linie e încheiată cu punct-virgulă, în Visual Basic liniile normale nu se termină cu nimic (cazul uzual e să-ți termini propoziția pe o linie) și se tratează ca un caz excepțional (care merită complicații suplimentare deci un caracter în plus), situația rară cînd nu ai terminat ideea.

Mă întreb cîți utilizatori Visual Basic au cerut includerea luxuriantei delicatese în limbaj. Cîți oameni care scriu cod VB sînt deranjați de ocazionalele underscoruri și ar vrea să renunțe uneori al ele? Mai degrabă cred ca scriitorii de la Microsoft care oricum nu scriu în VB și care cred că nici nu cunosc limbajul decît din documentația scrisă de managerii lor ca teme implementare, ei au fost ofensați vizual de atîtea liniuțe de subliniere prin codul clienților.

Trebuie să recunosc că în comparație cu rotunjimea apetisantă a acoladelor din “si șarf”, continuatorul de linie din Visual Basic arată demodat. Trebuia făcut ceva urgent. Și au făcut-o.

Cum se poate spune că o linie nu e terminată și că urmează continuarea ei privind codul? Foarte greu. Nu e vina nimănui, așa e logica limbajului. Ăsta e prețul pe care îl plătește programatorul VB pentru faptul că nu termină fiecare linie de cod cu punct-virgulă: trebuie să spună cumva cînd NU a terminat pentru că implicit se consideră că e gata.

Problema de a renunța la underscore e cu adevărat grea, imposibilă aș spune și băieții au constatat-o pe propria piele. Dacă nu ar fi existat vreun șef care să își riște scaunul din cauza recunoașterii eșecului și a renunțării la atîta muncă, bunul simț comun ar fi trebui să le spună că noutatea nu poate fi livrată clienților. Și pehașpiștii și-ar bate joc de ce a ieșit și pe bună dreptate.

Ce au făcut savanții? S-au uitat la managerul rîios ca la broască (sau alta să fie topica aici?) dar nu au avut tupeul să-și riște scaunul contrazicîndu-l ferm. Au zis în bunul spirit lingătoresc – remondian “să trăiți șefu! awesome! mai aveți și altele că noi mai putem duce”. S-au pus pe treabă și au extras dumnezeu știe cum din limbaj N-șpe mii de cazuri cînd se poate deduce dacă o linie se continuă totuși pe linia următoare fără a fi nevoie de caracterul ofensiv. La 50% din cazurile identificate au fost identificate Ț-șpe mii de excepții dar băieții au fost muncitori și le-au catalogat pe toate. Combinațiile sînt aproape infinite și nu poți să-i explici cuiva cînd poate să se lipsească în siguranță de underscore decît cu cîteva pagini de expresii regulate. Asta nu i-a descurajat însă deloc. Ei și-au scris expresiile regulate în cod, să le explice alții programatorilor ce și cum: “și clienții care nu sînt mulțumiți să treacă dracului odată la C# că deja ne-am săturat și noi”.

Acum, în 2010, putem să ne lipsim de liniuța de subliniere cînd continuăm linia pe o linie nouă. UNEORI. Cînd? Păi… De exemplu imediat după o paranteză dacă nu urmează o cifră, ampersand sau ByVal respectiv ByRef. Sau înainte de orice operator matematic (+, -, /, *) dar nu dacă + e folosit pentru concatenare (deși se poate și atunci cu condiția să…). Cam așa arată lista de cazuri cînd te poți lipsi de underscore (deși cazurile date de mine sînt pură ficțiune pentru că nu am reuști să rețin cazuri reale și concrete).

Cine ar alege să-și bată capul? Aproape nimeni. Întotdeauna există un “dar”. Dar-ul în cauză sînt tinerii neștiutori care nu înțeleg ce să ignore ca fiind prostie pură în toată treaba și iau propaganda de bună:

“Auzi, în VB din 2010 cică nu mai e nevoie de underscore cînd continui linia”.

De ce l-ar mai folosi? Doar e demodat. Vor scrie cod fără (deși asta e imposibil de multe ori chiar teoretic, există numeroase cazuri neacoperite de lista rîioasă în care nicio euristică nu a funcționat și caracterul _ a rămas obligatoriu de folosit).

Exact ca în incidentul .net 2008 cînd au fost introduse tipurile anonime și nu s-a mai cerut declararea obligatorie a tipului variabilelor, urmînd ca bietul compilator să “infereze” (presupună / spere  / greșească) ce ai vrut de fapt, așa și acum, cînd nu folosești caracterul de continuare, compilatorul speră că ai vrut ceea ce crede el (pentru că nu are cum să fie sigur în multe situații deci rămîne cu speranța și nu doar atît dar o și pune în practică).

Cît de acceptabilă e treaba asta că să lăsăm pe compilator să ghicească și să facă lucrurile cum vrea el… nu îmi dau seama dar pare la mare modă.

Cînd am citit despre noutate prin nu știu care beta și am fost și eu paralizat odată cu planeta de surpriză, m-am uitat lung și am zis că-s tîmpiți să se chinuiască pentru așa o treabă care clar nu poate fi făcută rezonabil. M-am calmat rapid gîndindu-mă că nu mă va afecta deloc, în cel mai rău caz vor fi încă 3 minute de procesor pe zi aruncate pe apa sîmbetei cu căutări de sensuri subînțelese prin codul meu de către compilator și asta pentru orgoliul sau avansarea unui manager de la Microsoft.

Nu a fost să fie chiar așa.

Azi m-am uitat la o linie de cod ca curca în lemne.

Codul care urmează e pur ilustrativ.

Private Sub Form1_Load(…) Handles MyBase.Load

With Me
.Text = „Fereastra mea”
.ShowInTaskbar = True
.Width =
.Show

End With

End Sub

Să spunem că nu știu pe ce valoare să pun o proprietate Width și o las necompletată urmînd să revin la ea (pentru că oricum nu se va compilează fără să rezolv deci nu am cum să uit). Continui lista cu atribuiri cu ceea ce știu ca să nu mă întrerup cu căutatul necunoscutei.

Cînd îmi ridic ochii la ecran văd că obiectează IDE-ul la… .Show.

Mă uit, mă mai uit odată… ce probleme poate avea cu .Show? Cum adică expresia nu produce o valoare? Păi ce valoare să producă? Și care expresie? M-am tot uitat, am închis fereastra de cod, poate își revine cînd o redeschid. Degeaba. Am închis complet IDE, l-am redeschis, tot așa. Deja treaba era serioasă așa că am încercat să și citesc ceea ce vedeam. Uitasem unde mă aflu, în care secol și în care versiune de Visual Basic.

Ce se întîmplă de fapt în codul de mai sus?

Compilatorul bănuiește că aș vrea să continui linia .With = pe următoarea linie. Pînă acum nu m-ar fi putut bănui de așa ceva pentru că regulile erau clare: dacă nu ai terminat, pui liniuța de subliniere și continui mai jos. Acum nu mai e obligatoriu, ba chiar e recomandat să riști, e pe val. Compilatorul ce poate să facă? Să spere și să presupună. Ce a fost în mintea lui? Că .Show e expresia cu care vreau eu sa setez lățimea ferestrei din linia anterioară.

Am avut și noroc. De ce spun asta? Dacă în loc de .Show îmi venea să scriu altceva (complet greșit), aveam toate șansele să îl fericesc pe compilator, să compileze și să și execute.

Secvența următoare e pe cît de absurdă din punct de vedere logic și ca sintaxă tradițională VB, pe atît de corectă sintactic și compilabilă în 2010:

Nici măcar pîs (adică warning) nu zice.

Norocul meu a fost că nu am vrut să afișez fereastra ca dialog… pentru că ShowDialog ÎNTÎMPLĂTOR întoarce o valoare care ÎNTÎMPLĂTOR e de un tip compatibil cu .With deci toată lumea va fi fericită. Mai puțin eu.

Cred că am un destin nefast. Nu astea sînt vremurile în care aș fi fost fericit să-mi compilez codul.