[C#/2.0]Restituire valore solo se non nullo

[RaouL_BennetH]

allora, leggendo diversi vostri post, sto provando anche io ad aderire alla campagna anti-if ...

ho questa situazione:

private double GetCellValue(int cellNumber)
{
    return double.Parse(grid.CurrentRow.Cells[cellNumber].Value.ToString());
}

Sembrerebbe ok... se non fosse che:

Se trova un valore nullo, ovvero una cella vuota, mi sparafracassa i maroni chiedendomi di creare una nuova istanza dell'oggetto..

allora, dovrei fare così:

private double GetCellValue(int cellNumber)
{
    if(grid.CurrentRow.Cells[cellNumber].Value != null)
       return double.Parse(blabla)
    else
    return 0.00
}

ma così, non aderisco + alla campagna anti-if

Come potrei risolvere?

Grazie mille

RaouL.

[wizard1993]

Originariamente inviato da RaouL_BennetH

ma così, non aderisco + alla campagna anti-if

qusta è la prima volta la sento nominare

[RaouL_BennetH]

http://www.metodiagili.it/campagna-anti-if/index.htm

[^TiGeRShArK^]

con il try - catch?
Ma sempre se è un campo obbligatorio e quindi è giusto che debba lanciare un eccezione, altrimenti se è un campo facoltativo devi comunque usare l'if a meno di non riscriverti il controllo di windows in ottica "anti-if" così ad occhio...

[||ElChE||88]

private double GetCellValue(int cellNumber)
{
   try
   {
       return double.Parse(grid.CurrentRow.Cells[cellNumber].Value.ToString());
   }
   catch
   {
       return 0;
   }
}

PS: Che cazzata la campagna anti-if. Va bene non usarli quando non servono, ma qua si esagera...

[RaouL_BennetH]

Originariamente inviato da ||ElChE||88

private double GetCellValue(int cellNumber)
{
   try
   {
       return double.Parse(grid.CurrentRow.Cells[cellNumber].Value.ToString());
   }
   catch
   {
       return 0;
   }
}

PS: Che cazzata la campagna anti-if. Va bene non usarli quando non servono, ma qua si esagera...

Beh, più che altro a me serve per studio, non per un'applicazione reale

chiedo venia

[tomminno]

Usare double.TryParse?
Così nascondi l'if sotto il tappeto (del framework).

[tomminno]

Originariamente inviato da ||ElChE||88

PS: Che cazzata la campagna anti-if. Va bene non usarli quando non servono, ma qua si esagera...

Il problema è che è indirizzata male.
La maggior parte degli if non si usano per verificare il tipo di un oggetto ma per stabilire se è nullo o ha un valore ben definito.

Senza gli if in questo caso il codice è meno leggibile e almeno con il C# finisce che per fare veloce il codice si legge al contrario perchè prima viene il codice che andrebbe dentro l'if/else e poi il check della condizione.
In ogni caso è sempre più lungo da scrivere di un banale if.

[^TiGeRShArK^]

Originariamente inviato da tomminno

Il problema è che è indirizzata male.
La maggior parte degli if non si usano per verificare il tipo di un oggetto ma per stabilire se è nullo o ha un valore ben definito.

beh, ma se gli oggetti li hai creati tu puoi sempre usare il null-pattern per evitare il controllo sul null o una mappa per controllare i vari valori.
Il problema è quando, come in questo caso, si devono utilizzare componenti che *possono* restituire null anche in casi non eccezionali.
Se, ad esempio, alla MS avessero previsto un flag "obbligatorio" per quel componente, e avessero consentito di associarlo ad un ben determinato tipo di dato, anzichè utilizzare il generico string, sarebbe stato possibile restituire il valore di default corretto e si sarebbe potuto eliminare quell'if.

[tomminno]

Originariamente inviato da ^TiGeRShArK^

beh, ma se gli oggetti li hai creati tu puoi sempre usare il null-pattern per evitare il controllo sul null o una mappa per controllare i vari valori.

Null non è l'unico valore da controllare, e usando le mappe o delegati il codice è certamente molto meno chiaro di un if.
Me ne sono accorto quando mi sono imposto di creare un parser per i log di pureFTP assolutamente senza if.
E' velocissimo ad eseguire (che era l'obiettivo principale), quanto al codice si legge al contrario, inoltre ci ho messo molto più tempo a scriverlo.
Per quanto mi riguarda l'if lo uso in casi come:
if (i < x)
if (IsEnabled())

E spesso quando si hanno a che fare con intervalli di valori creare le mappe diventa complicato.

Il problema è quando, come in questo caso, si devono utilizzare componenti che *possono* restituire null anche in casi non eccezionali.
Se, ad esempio, alla MS avessero previsto un flag "obbligatorio" per quel componente, e avessero consentito di associarlo ad un ben determinato tipo di dato, anzichè utilizzare il generico string, sarebbe stato possibile restituire il valore di default corretto e si sarebbe potuto eliminare quell'if.

double.Parse non può restituire null semplicemente perchè ritorna un double che non è un oggetto. Al limite solleva FormatException o ritorna 1.0
Per questo esiste il metodo TryParse che restituisce true o false se la conversione è avvenuta con successo.

[^TiGeRShArK^]

Originariamente inviato da tomminno

Null non è l'unico valore da controllare, e usando le mappe o delegati il codice è certamente molto meno chiaro di un if.
Me ne sono accorto quando mi sono imposto di creare un parser per i log di pureFTP assolutamente senza if.
E' velocissimo ad eseguire (che era l'obiettivo principale), quanto al codice si legge al contrario, inoltre ci ho messo molto più tempo a scriverlo.
Per quanto mi riguarda l'if lo uso in casi come:
if (i < x)
if (IsEnabled())

E spesso quando si hanno a che fare con intervalli di valori creare le mappe diventa complicato.



double.Parse non può restituire null semplicemente perchè ritorna un double che non è un oggetto. Al limite solleva FormatException o ritorna 1.0
Per questo esiste il metodo TryParse che restituisce true o false se la conversione è avvenuta con successo.

Ma infatti io non mi riferivo al double.parse, ma al componente di windows da cui prendeva la stringa che poi deve essere parsata.
Se anzichè usare questo meccanismo si fosse utilizzato un componente cosciente del tipo di dato che dovrà contenere, allora si sarebbe potuta eliminare la necessità dell'if perchè semplicemente non sarebbe stata necessaria alcuna conversione dato che il componente avrebbe restituito direttamente un double o un int o qualsiasi altra cosa a seconda del tipo di dato.

[RaouL_BennetH]

facendo un pò di chiarezza:

l'oggetto in questione è una griglia, e l'operazione che devo svolgere è una banale somma o differenza tra i valori contenuti nelle celle.

Il fatto è che questa operazione deve avvenire in corrispondenza di un evento, ovvero quando si lascia la cella corrente per scrivere in quella successiva.

Sono quindi incappato in questo problema, ovvero, lasciando la cella corrente, supponiamo la cella 3, che contiene 12,79, andando in quella successiva (quindi già sono nell'evento di EndEdit) mi ritrovo già che 12,79 cerca di sottrarsi o addizionarsi ad un valore ancora non presente nell'evento BeginEdit della cella.

Avrei potuto risolvere il tutto comodamente settando a zero il valore di default di ogni cella, ma, ripeto, dato che è solo per studio, cerco di vedere lo stesso problema sotto diversi punti di vista, cercando di volta in volta di non adottare quello che già conosco, ma cercando di fare qualcosa di nuovo a scopo didattico

[tomminno]

Originariamente inviato da ^TiGeRShArK^

Ma infatti io non mi riferivo al double.parse, ma al componente di windows da cui prendeva la stringa che poi deve essere parsata.
Se anzichè usare questo meccanismo si fosse utilizzato un componente cosciente del tipo di dato che dovrà contenere, allora si sarebbe potuta eliminare la necessità dell'if perchè semplicemente non sarebbe stata necessaria alcuna conversione dato che il componente avrebbe restituito direttamente un double o un int o qualsiasi altra cosa a seconda del tipo di dato.

Una griglia generics in cui specificare per ogni cella il tipo di contenuto non è propriamente fattibile.

[tomminno]

Originariamente inviato da RaouL_BennetH

facendo un pò di chiarezza:

l'oggetto in questione è una griglia, e l'operazione che devo svolgere è una banale somma o differenza tra i valori contenuti nelle celle.

Il fatto è che questa operazione deve avvenire in corrispondenza di un evento, ovvero quando si lascia la cella corrente per scrivere in quella successiva.

Sono quindi incappato in questo problema, ovvero, lasciando la cella corrente, supponiamo la cella 3, che contiene 12,79, andando in quella successiva (quindi già sono nell'evento di EndEdit) mi ritrovo già che 12,79 cerca di sottrarsi o addizionarsi ad un valore ancora non presente nell'evento BeginEdit della cella.

Avrei potuto risolvere il tutto comodamente settando a zero il valore di default di ogni cella, ma, ripeto, dato che è solo per studio, cerco di vedere lo stesso problema sotto diversi punti di vista, cercando di volta in volta di non adottare quello che già conosco, ma cercando di fare qualcosa di nuovo a scopo didattico

Ma non ti viene sollevata nessuna eccezione?

[^TiGeRShArK^]

Originariamente inviato da tomminno

Una griglia generics in cui specificare per ogni cella il tipo di contenuto non è propriamente fattibile.

perchè no?
Ad esempio utilizzando una DataGridView puoi già specificare il tipo di dato di ogni colonna, e non mi pare ci siano problemi di sorta...

[RaouL_BennetH]

Originariamente inviato da tomminno

Ma non ti viene sollevata nessuna eccezione?

Ovviamente si facendo come sto facendo io, ovvero senza dire a priori al datagridview che tipo di valori ci saranno nelle celle.

P.S.:

con il datagridview puoi tranquillamente settare il tipo di valore per ogni colonna.
Dispone di eventi che ne facilitano moltissimo l'utilizzo.

Eventi appunto... che NON sto usando ma solo per imparare