[.NET] Perchè il goto è così usato?

[DanieleC88]

Originariamente inviato da cdimauro

Se rivedo il mio vecchio codice, mi sento male: MOLTO diverso da quello che tiro fuori da qualche anno a questa parte. :|

Questo anche io, scrivo codice decisamente migliore... ma da qui all'abolizione degli if ce ne metterò ancora parecchio.

[fek]

Originariamente inviato da cdimauro

In tutta onestà debbo dire che nel mio codice gli if sono ancora abbastanza presenti nonostante le rifattorizzazioni, ma la tendenza è quella di ridurli all'osso (senza if poi il codice è molto più leggibile).

Diciamo che quando ho tempo per rifattorizzare, mi capita di sistemare meglio il codice, eliminandone qualcuno.

Se rivedo il mio vecchio codice, mi sento male: MOLTO diverso da quello che tiro fuori da qualche anno a questa parte. :|

Per altro eliminare gli if mi da' un'interessante vantaggio collaterale in questo periodo: il codice esce piu' veloce perche' elimino i branch che non vanno molto a genio di una CPU in-order a pedali.

[cdimauro]

Indubbiamente. Con quelle carrette (come le chiami tu ) un branch misprediction è LETALE per la pipeline... :|

[thebol]

Originariamente inviato da fek

Io sto iniziando ad abolire gli if dal mio codice.

http://www.metodiagili.it/campagna-anti-if.html

[fek]

Originariamente inviato da thebol

http://www.metodiagili.it/campagna-anti-if.html

La voglio!

[shinya]

Originariamente inviato da thebol

http://www.metodiagili.it/campagna-anti-if.html

Ahaha! che sborata!

[m.distrutti]

sinceramente prima di entrare in questo forum manco sapevo cosa significasse agile XD se non era per il fatto di averlo letto una o due volte in una tesi riguardandte un certo peuck(), non era una sviolinata come può sembrare eh' (in effetti e' vero non avevo mai letto sta parola asd)


ma perchè a scuola non li insegnano gia dalle superiori questi metodi di sviluppo? alla fine non e' difficile in se, ma lo diventa se per molti anni ci si e' fossilizzati come me in modi completamente sbagliati T.T, io senza if non so come disegnarlo un programma e riguardando dei programmi fatti alle superiori mi sono reso conto perche a volte non li continuavo e mi fermavo

[cdimauro]

Alle superiori? Manco all'università le insegnano!

P.S. STUPENDA quella maglietta!!!

[DanieleC88]

Originariamente inviato da cdimauro

Manco all'università le insegnano!

È più che altro questa la cosa strana.

[cdimauro]

Mica tanto. Molti docenti sono abbastanza reazionari: imparano alcune cose, e se le tengono strette.

[m.distrutti]

nel corso della mia uni lo stanno per iniziare lo unit testing , il refactoring dovrei aspettare la magistrale T.T

meglio cominciare ora

[tomminno]

Speravo che fornissero qualche esempio concreto di realizzazione "agile", invece ritorna sempre il solito esempio che si realizza bene tramite ereditarietà.
Ma come lo tolgo l'if in un caso simile?

if (tbUsername.Text.Length < 8 || tbUsername.Text.Length > 50)
{
    lbError.Visible = true;
    return;
}

[cionci]

Posta anche il resto del codice altrimenti non possiamo capire bene...

[fek]

Originariamente inviato da tomminno

Speravo che fornissero qualche esempio concreto di realizzazione "agile", invece ritorna sempre il solito esempio che si realizza bene tramite ereditarietà.
Ma come lo tolgo l'if in un caso simile?

if (tbUsername.Text.Length < 8 || tbUsername.Text.Length > 50)
{
    lbError.Visible = true;
    return;
}

    lbError.Visible = IsVisible();

bool IsVisible()
{
  return tbUsername.Text.Length < 8 || tbUsername.Text.Length > 50;
}

IsVisible() non e' un if, ma una proprieta'.
Il return si implementa senza if conoscendo il contesto del metodo. Molto probabilmente e' la situazione ideale per uno State pattern.

Qualcosa di simile a:

currentState[IsVisible()].DoSomething();

Easy.

[tomminno]

Originariamente inviato da cionci

Posta anche il resto del codice altrimenti non possiamo capire bene...

Ridotto all'osso è una validazione dati lato server:

private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostBack)
{

/*Controllo sulla lunghezza dello username per validazione dati*/
if (tbUsername.Text.Length < 8 || tbUsername.Text.Length > 50)
{
lbError.Visible = true;
lbError.Text = "Username non valido"; 
return;
}
if (tbPassword.Text.Length < 8)
{
lbError.Text = "La password non rispetta le policy";
return;
}
if (Session["data"] == null)
{

lbError.Visible = true;
lbError.Text = "Sessione scaduta";
return;
}
Login();
}
}

[tomminno]

Originariamente inviato da fek

Il return si implementa senza if conoscendo il contesto del metodo. Molto probabilmente e' la situazione ideale per uno State pattern.

Qualcosa di simile a:

currentState[IsVisible()].DoSomething();

Easy.

Certo che sostituire ad ogni possibile if un qualcosa del genere il numero di classi aumenta esponenzialmente e tutte devono avere accesso alla classe base (in questo caso una pagina asp), il che comporta anche creare metodi/proprietà per impostare i controlli o renderli pubblici direttamente (che non è proprio l'ideale) quindi altro lavoro se una pagina ha una ventina di controlli significa scrivere altrettanti get e set con altre validazioni dei dati (visto che è la classe pagina a conoscere i criteri di validità, campi solo numerici o formattati in un certo modo)

[fek]

Originariamente inviato da tomminno

Ridotto all'osso è una validazione dati lato server:

Ovvero uno State pattern grosso come una casa. L'oggetto Validator ritorna lo State object corrente che imposta i campi di Text come necessario.
Certo che se al contrario usi catene di if, poi ti servono commenti per capire che cosa succede in un pezzo di codice che non e' chiaro di suo

Qui il problema e' proprio la scarsa qualita' del codice di partenza, ad esempio:

if (!IsPostBack)
{
// malloppo di if

Inizia a scriverlo con la logica dritta e non negata:

if (IsPostBack)
{
  return;
}

Cosi' ti accorgi che l'essere in PostBack e' uno stato, non serve trattarlo con un if, e tutto quello che viene dopo e' un'azione...

[fek]

Originariamente inviato da tomminno

Certo che sostituire ad ogni possibile if un qualcosa del genere il numero di classi aumenta esponenzialmente e tutte devono avere accesso alla classe base (in questo caso una pagina asp), il che comporta anche creare metodi/proprietà per impostare i controlli o renderli pubblici direttamente (che non è proprio l'ideale) quindi altro lavoro se una pagina ha una ventina di controlli significa scrivere altrettanti get e set con altre validazioni dei dati (visto che è la classe pagina a conoscere i criteri di validità, campi solo numerici o formattati in un certo modo)

Al contrario, scrivendo buon codice diminuisce il numero di classi e diventano piu' coese. Non per altro si chiama programmazione orientata agli oggetti.
Non serve avere accesso alla classe base per tutto se non si ragiona in ottica C, basta passare le informazioni strettamente necessarie agli oggetti che le devono usare. Ovvio, ci vuole un po' di dimestichezza, ma non serve scrivere un solo get/set

Poi con anonymous class, delegate e ammenicoli vari queste cose si fanno in una manciata di righe codice. Basta togliersi dalla testa gli.

[tomminno]

[quote=fek;21971668]Ovvero uno State pattern grosso come una casa. L'oggetto Validator ritorna lo State object corrente che imposta i campi di Text come necessario.
Certo che se al contrario usi catene di if, poi ti servono commenti per capire che cosa succede in un pezzo di codice che non e' chiaro di suo

Qui il problema e' proprio la scarsa qualita' del codice di partenza, ad esempio:

if (!IsPostBack)
{
// malloppo di if

Inizia a scriverlo con la logica dritta e non negata:

if (IsPostBack)
{
  return;
}

Cosi' ti accorgi che l'essere in PostBack e' uno stato, non serve trattarlo con un if, e tutto quello che viene dopo e' un'azione...

In una pagina ASP cambia poco perchè spesso c'è qualcosa da fare anche nel caso IsPostBack.

Sinceramente nelle pagine web mi riesce poco di evitare gli if, ci sono così tanti controlli da fare che mi torna decisamente più facile l'if (e da quanto vedo in giro non sono certo il solo).
Ogni volta che peschi una variabile dalla sessione devi controllare che non sia nulla e affidarsi alle eccezioni significherebbe riempire il codice di decine try catch, idem per i controlli web in cui in base allo stato di uno decidi o meno se mostrare un altro controllo.

[fek]

Originariamente inviato da tomminno

In una pagina ASP cambia poco perchè spesso c'è qualcosa da fare anche nel caso IsPostBack.

Quello che accade spesso non conta. Conta quello che accade. E nel codice che hai scritto un if negato come quello e' semplicemente cattivo codice.

Sinceramente nelle pagine web mi riesce poco di evitare gli if, ci sono così tanti controlli da fare che mi torna decisamente più facile l'if (e da quanto vedo in giro non sono certo il solo).
Ogni volta che peschi una variabile dalla sessione devi controllare che non sia nulla e affidarsi alle eccezioni significherebbe riempire il codice di decine try catch, idem per i controlli web in cui in base allo stato di uno decidi o meno se mostrare un altro controllo.

Chi ha mai parlato di affidarsi alle eccezioni? Bisogna affidarsi alla scrittura di buon codice semplice e non procedurale come ti e' stato mostrato in tutti gli esempi che hai riportato.
Il fatto che tu non veda come un if possa essere eliminato, non vuol dire che non sia possibile. E' sempre possibile, basta volerci provare
Una lettura a Design Patterns ti farebbe un gran bene: quasi tutti gli esempi che fai sono gia' stati ampiamente risolti.