Érezted valaha úgy, mint a kódolás Sherlock Holmes-ja, amikor hibakereséskor követted a legkisebb nyomot, amely a probléma gyökeréhez vezet?
A hibák vagy nyilvánvalóak, vagy nevetségesen nehéz kijavítani. Ahhoz, hogy valóban megértsük a nem triviálisakat, gyakran szükségünk van némi out-of-the-box gondolkodásra.
Egészen olyan, mint egy House-epizód. Amikor a csapat látszólag zsákutcába jutott a diagnosztika kidolgozása során, elkezdik átértékelni eddigi hipotézisüket.
Van ez az epizód, ahol House káprázik, és ezért meg kell kérdőjeleznie, hogy mely élmények valósak. Ennek érdekében elkezdi megkérdőjelezni csapata legalapvetőbb feltételezéseit is.
Valahogy ezt tettük, amikor megoldottuk a következő rejtélyes hibát. Íme a kód!
A sértő kód ezen lecsupaszított verziójában azt vártuk, hogy a someField 11-es értékkel végződjön az IncrementSomeField() közvetett hívás után a someActionen keresztül. > delegál.
Némi fájdalmas fejvakarás és a kódfolyam helyességének kétszeri ellenőrzése után azon tűnődtünk, mit hagytunk ki.
És akkor jutottunk hozzánk: mi van, ha az IncrementSomeField()-ben az implicit this nem ugyanaz a this a myVar esetén em> változó a Test()-en belül? Ez mindent megmagyarázna. A someField valóban 11 lenne, de egy egy másik példány esetében, amely elveszett a függvényhívási láncban.
Most pedig a magyarázathoz! Kiderült, hogy a this mutatót értékkel rögzíti a someAction += IncrementSomeField; helyen létrehozott lezárás. És mivel struktúrát használunk, és a struktúrák értéktípusok, amikor az IncrementSomeField() mezőben vagyunk, ez valójában a struktúránk másolata, amellyel dolgozunk. .
Emiatt a myVar változónkat soha nem érintjük meg, és ezért a someField az eredeti 10-es értéken marad.
Ez van, srácok! És továbbra is kérdőjelezd meg a kódok érvelését!
Ez volt a fiad, Matheus Lessa, aki kijelentkezett, és visszament dolgozni. Béke!
