Что более читабельно? [закрытый]

используйте то, что вы предпочитаете, но скрыть его в методе:

return risks.SumTechnicalPremium();

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

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

для тех, кто может читать LINQ, LINQ one.

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

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

код LINQ очень удобочитаем и самодокументирован.

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

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

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

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

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

здесь нет проблем с читаемостью. Нажмите на Sum и нажмите F1.

Linq для победы.

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

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

или

decimal technicalPremium = 0;

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

возврат technicalPremium;

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

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

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

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

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

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

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

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

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

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

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