A VS coverage-e ezt mutatja, hogy ez a sor csak részben van lefedve:
return (GetSourceItem(step) – this[step – 1]) * e + this[step – 1];
Nincs benne && vagy ||, akkor triviális lenne. Én már tudom a választ. :)
Update: alul, kommentben ott a megoldás.
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
12 COMMENTS
NullReference vagy IndexOutOfBound exception?
Nem.
GetSourceItem belsejét nem járja be teljesen?
pl
private int GetSourceItem(int step)
{
if (1 == 1)
return 4;
….
return 6;
}
Ha nem, akkor csak az indexer-t tudom elképzelni még. this[step – 1]
Ha a GetSourceItem belsejét nem járná be, az ott látszana, nem a hívó soron.
Nem az indexerrel van baj.
Hint: nem teljesen ennyi a kód, mert a compiler generál hozzá, ami nem látszik, de a coverage nyilván látja.
e==0?
Nem, ha osztás lenne e-vel, akkor esetleg, de nem.
A “this[step – 1]”-t kiemeli változóba (bár ez Debug módban érdekes lenne), hogy optimalizáljon?
Nem. :) Éjszaka megírom.
Nos, a megoldás az, hogy a számításban nullable típusokat használok, és ezek miatt a compilernek külön kódot kell írni az operátorokhoz, hogy lekezelje, ha valamelyik operandusz null.
Ha a fenti kódban minden értéknek lekérem a tényleges értékét, a .Value-val, akkor már teljes a lefedettség.
Most futottam pl. ebbe bele:
if (slow.HasValue && fast.HasValue)
{
return fast – slow;
}
Ebben is a return kifejezése csak részben lefedett, de így már teljesen:
if (slow.HasValue && fast.HasValue)
{
return fast.Value – slow.Value;
}
Érdekes, nem?
Érdekes tényleg, de azért legközelebb egy kicsit több kódot mutass a fejtörőből, mert honnan tudtuk volna, hogy nullable-ök? :)
YellowCat: először én se realizáltam :)
De igazad van, így túl nehéz volt.