По-малко редове код не винаги са по-добри

Отстранявах грешки в този метод онзи ден:

Ето някои проблеми, които открих с този един лайнер:

Прегледът на върнатата стойност е неудобен

Вместо просто да мога да задържа курсора на мишката върху променлива, трябваше да маркирам всичко след return и да го добавя към прозореца за наблюдение.

Актуализирането на върнатата стойност по време на тестването е невъзможно

Тъй като IdMap.Contains<Deposit>(dto.DepositID) не е променлива, не успях да актуализирам върнатата стойност в незабавния прозорец на Visual Studio, както понякога трябва да направя.

Улеснете живота на другите разработчици и вашия живот, използвайте два реда!

Ако кодът беше написан по този начин, щеше да е МНОГО по-лесно за отстраняване на грешки:

Обобщение на коментарите от Reddit

Обсъдих тази тема в Reddit и повечето хора бяха против.

Ето обобщение на техните точки и моите отговори:

Можете да използвате прозореца Autos, за да видите върнатите от функцията стойности

Можете също да направите това с променлива. Като имате променлива, вие предоставяте опцията на разработчиците да задържат курсора си над променливата, за да видят стойността, ако искат.

Прозорецът autos може да бъде наводнен с други променливи, които не ви интересуват. Да се ​​налага да преглеждате или превъртате, за да намерите вашата променлива, не е идеално.

Можете да изчакате, докато методът се върне

Методът се връща и след това можете да задържите курсора на мишката над променливата, към която е приета върнатата стойност. Но какво ще стане, ако искате да намерите стойността веднага след като е изчислена? Какво ще стане, ако върнатата стойност не е уловена в променлива, а се използва в оператор if? Ами ако върнатата стойност на един метод се върне от извикващия метод, чак до метода за действие, в който случай никога нямате шанс да видите/актуализирате резултата.

Можете да маркирате една линия и да добавите часовник

Това е повече работа, отколкото просто да задържите курсора на мишката върху променлива. Също така, това може да има нежелани странични ефекти, тъй като това включва изпълнение на една линия всеки път, когато добавите часовника.

Можете да използвате тестване на единици или да кодирате твърдо стойността, за да тествате различни върнати стойности

Това е много усилие, особено когато може да няма смисъл да се тества методът (ами ако е частен метод?). Ами ако сте по средата на отстраняване на грешки в работещо приложение, отнели са ви пет минути, за да стигнете до реда, на който се намирате в момента, и искате да тествате различна върната стойност, само за да откриете, че трябва да спрете програмата, да редактирате кода, за да кодирате твърдо нова стойност, или да напишете единичен тест? Не е идеално. Единичното тестване също не ви позволява да видите резултата от различни стойности на променливи в получения потребителски интерфейс.

Резюме

Прихващането на върнатата стойност към променлива не помага за четливостта, тъй като името на метода вече трябва да ви каже какво ще бъде върнато. Това обаче не намалява четливостта.

Ползата от наличието на два реда (по-лесни за отстраняване на грешки) далеч надвишава незначителния минус (имат един малък допълнителен ред), според мен.