Что читабельнее?

Если команда, которая работает над кодом, знает, что делает версия Linq, и знает ее внутреннюю работу, тогда она более читабельна.

Я считаю, что второй вариант лучше, потому что он должен быть более эффективным. Однако то, что происходит, менее очевидно (по крайней мере, для меня).

Для тех, кто умеет читать LINQ, это LINQ one.

Для тех, кому нужно интерпретировать код шаг за шагом (с помощью intellisense / documentation короче.

Код LINQ легко читается и самодокументируется.

Ни один. Первый более подробный и, вероятно, будет понятен каждому. Второй вариант более лаконичен и понятен каждому, даже поверхностному знанию linq.

Я бы сказал, что вы можете основывать свой выбор на окружающей среде, в которой находитесь.

Используйте linq. Если вы считаете, что это требует объяснения, об этом позаботится однострочный комментарий. По мере того, как люди привыкают к linq, необходимость в комментариях отпадает.

Я бы сказал первый, так как linq не знаю. Рискуя чрезмерно задокументировать, я бы использовал его с кратким описанием происходящего. Или просто скажите, что это linq для людей, которые могут не знать.

Первый вариант более читабелен для более широкого круга людей. Второй вариант имеет «входной барьер» в том смысле, что читатель может знать или понимать LINQ. Он более лаконичен и поэтому может быть лучше, если ваша аудитория преодолеет этот входной барьер.

Если вы предоставите комментарий, объясняющий его цель, я бы выбрал вариант Linq.

Первый, если вы не знакомы с Linq. Любой разработчик может прочитать и понять первую.

Здесь нет проблем с читабельностью. Щелкните Сумма и нажмите F1.

Linq для победы.

У каждого языка есть соглашения о том, как лучше всего кодировать такие вещи, поэтому то, что лучше всего читается людьми, которые регулярно используют этот язык, не универсально. Для программиста на Java или C# первый вариант более читабелен. Для тех, кто привык к LINQ или функциональному программированию, второй будет более читабельным.

Используйте то, что вам больше нравится, но спрячьте это в методе:

return risks.SumTechnicalPremium();

Я не знаю C#, но вторая альтернатива мне кажется намного чище, и я мог понять, что она делает (хорошо, с некоторыми догадками и перекрестной проверкой с первой версией). Наверное, из-за какой-то функциональной предыстории. Но в первую очередь нужно искать техническую премию в 4 (!) Местах. Второй вариант намного короче и его легче понять, если вы просто читаете код.

или же

десятичный технический премиум = 0;

foreach (Риск риска в рисках) TechnicalPremium = TechnicalPremium + risk.TechnicalPremium;

возврат TechnicalPremium;

Я вижу, как люди говорят, что им нравится первый «если вы не знаете Linq». Да, и первый не читается, если вы не знаете C#. Вопрос не в том, «что удобнее для чтения», а в том, «какие языковые функции нам удобнее использовать?»

Начните с разговора со своей командой о частях языка / фреймворка / набора инструментов, которые все ненавидят, и объявите их запрещенными. Все остальное считается частью стандартного словарного запаса, и ожидается, что все будут свободно говорить на нем. Этот список должен быть в вашем документе о стандартах кодирования рядом с «никогда не создавайте изменяемые типы значений» и «не беспокойтесь о тривиальных свойствах для непубличных членов».

Пока Linq нет в вашем списке «исключений», второй пример далеко более читабелен, чем первый. Почему? Потому что он декларирует намерение кода, а не просто представляет механизм, который читатель может расшифровать.

Если ваша цель - сделать его более читаемым для «всех», которые могут придти после вас, используйте foreach. Я интерпретирую «более читабельный» как означающий, что любой, имеющий опыт в основах языка, должен уметь понимать. Для тех, кто не знаком с linq и все еще использует VS2005 или более раннюю версию, синтаксис linq может сбить с толку.

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

Я согласен с теми, кто говорит, что второе будет легко понять, поскольку Linq получит более широкое распространение. Это, конечно, более лаконично.

Однако меня беспокоит простота отладки. Кажется, намного проще пройтись по коду в foreach, чтобы точно увидеть, что он делает на каждом проходе.

Я думаю, это зависит от того, что вы подразумеваете под «читабельным». Первый пример четко показывает логику программы и должен быть понятен любому, у кого есть опыт программирования.

Для меня второй пример более интуитивно понятен в зависимости от контекста (т.е. вы берете массив (или какой-либо другой тип коллекции) и выполняете метод с именем Sum для каждого элемента этого массива). Единственное место, где второй пример может стать менее ясным, - это собственно лямбда-выражение, особенно для тех, кто не имел опыта работы с лямбда-выражениями или ранее имел опыт функционального программирования.

Я думаю, что по мере того, как лямбды станут более распространенными в программировании .NET, это станет меньшей проблемой. В нынешнем виде я думаю, что для понимания основ использования лямбда-выражений в .NET потребуется очень небольшая кривая обучения.

Второй, безусловно. Наличие такого большого блока кода для выполнения такой простой задачи, как суммирование, просто не нужно. Я тоже не знаю, что такое LINQ, но для меня он отлично читается.