C# programozók, átálltatok a foreach helyett a LINQ használatához? Melyiket preferáljátok?

Linq minden esetben. Optimálisabbak és olvashatóbbak az algoritmusok mintha foreach-et használnék.

Ráadásul refaktorálásnál úgyis átírják majd Linq lekérdezésre szóval nem tök mind1?

Nálunk is volt ebből aranyos kis probléma. A dev ezt írta:

try {

Book[] availableBooks = books.Where(async x => stockService.IsAvailableAsync(x)).ToArray();

}

catch (ApiException ex) {...}

Aztán csak pislogtunk, hogy miért hal meg a program unhandled ApiException kivétellel. LINQ mindenhol ^^ nem pedig csak ott, ahol van is értelme.

Na jó, a Where rossz példa volt, csak még véletlenül sem akartam olyan kódot írni, ami hasonlít a cégesre. A List<T>.ForEach(Action<T>) metódusával történt az eset. Ha megfigyeled, egy ilyen lambda kifejezés Func<T, Task<bool>>, ami implicit cast-olható Action<T>-re. Elvégre egy függvényt is meghívhatsz úgy, mint egy eljárást, ha nem érdekel a visszatérési érték.

De pont emiatt a Task nem is lesz await-elve (kontextuson kívül fut), és ha kivétel keletkezik, az egyetlen kivételkezelő, ami elkaphatja, az a CLR, ami leöli az alkalmazást. Hiába van ott a try-catch, nem tudja elkapni, mert a szálak nincsenek szinkronizálva.

Bocs a rossz példa miatt, ami nem is fordulna le (bool helyett Task<bool> ugye), de arra szerettem volna felhívni a figyelmet, hogy jó a LINQ, csak épp vigyázni kell, ha async kóddal együtt használod.

#5

Na igen, amikor valójában azt sem tudja, mit csinál az ember.

Néha elszörnyülködök, miféle borzadványokat képesek beírni egy lambda expression-be, olyan összetett feltételeket, hogy a hajam égnekáll, képtelenség megérteni.

Egyes válaszolóval is vitatkoznék egy kicsit, mert sokszor egy linq olvashatatlan.

Lehet, hogy te egy sorban leírtad azt az expression-t, de azt nem érti sok fejlesztő, hogy a kódot nem saját magának írja elsősorban, meg nem is a fordítónak, hanem a többi programozónak.

Tehát az érthetőség és jól olvashatóság az kiemelten fontos szempont.