Приводит ли использование выражений LINQ и Lambda к менее читаемому коду? [закрыто]

У меня беседа с коллегой по Linq, я напишу здесь:

Сотрудник: Давайте будем честными здесь. Синтаксис Linq отстой. Это сбивает с толку и не интуитивно понятно.

Я: да ладно, более запутанно, чем T-SQL?

Сотрудник: да.

Я: он имеет те же основные части, выберите, где и из

Сотрудник: Linq, для меня, является ублюдком реляционных + OO. Коллега: не поймите меня неправильно - это невероятно мощный инструмент, но они перенастроили SQL на использование коллекций объектов.

Я считаю, что использование Linq + Lamda очень мощно (он согласен), а также облегчает чтение кода (он не согласен с этим):

pickFiles = from f in pickFolder.GetFiles("*.txt")
where ValidAuditFileName.IsMatch(f.Name)
select f;

или

var existing = from s in ActiveRecordLinq.AsQueryable<ScannedEntity>()
where s.FileName == f.FullName && s.DocumentType != "Unknown"
select s;

или (код VB здесь)

   Dim notVerified = From image In images.AsParallel
     Group Join verifyFile In verifyFolder.GetFiles("*.vfy").AsParallel.Where(
      Function(v) v.Length > 0
      ).AsParallel
   On image.Name.Replace(image.Extension, ".vfy") Equals verifyFile.Name
     Into verifyList = Group
    From verify In verifyList.DefaultIfEmpty
    Where verify Is Nothing
    Select verify

Для меня это чисто и легко (по крайней мере, легче, чем альтернативы) читать, что вы думаете об этом?

Я больше не могу найти нужный пост, но Эрик Липперт (и, возможно, несколько других софтинов) несколько раз высказывался о том, как Linq декларативен , что для нескольких классов проблем гораздо более интуитивно, чем императивный синтаксис.

Linq позволяет вам писать код, который выражает намерение , а не механизм .

Вы говорите мне, что легче читать. Это:

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    List<Customer> results = new List<Customer>();
    foreach (Customer c in source)
    {
        if (c.FirstName == "Aaron")
        {
            results.Add(c);
        }
    }
    results.Sort(new LastNameComparer());
    return results;
}

class LastNameComparer : IComparer<Customer>
{
    public int Compare(Customer a, Customer b)
    {
        return x.LastName.CompareTo(b.LastName);
    }
}

Или это?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return from c in source
           where c.FirstName == "Aaron"
           orderby c.LastName
           select c;
}

Или даже это?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return source.Where(c => c.FirstName == "Aaron").OrderBy(c => c.LastName);
}

Первый пример - это просто набор бессмысленных шаблонов для получения простейших результатов. Любой, кто думает, что он более читабелен, чем версии Linq, должен проверить свою голову. Не только это, но первый тратит впустую память. Вы даже не можете написать это, используя yield returnсортировку.

Ваш коллега может сказать, что он хочет; лично я думаю, что Linq улучшил читабельность моего кода неизмеримо.

В Linq тоже нет ничего «реляционного». Он может иметь некоторые поверхностные сходства с SQL, но он никоим образом не пытается реализовать реляционное исчисление. Это просто набор расширений, которые облегчают запрос и проектирование последовательностей. «Запрос» не означает «реляционный», и на самом деле существует несколько нереляционных баз данных, которые используют SQL-подобный синтаксис. Linq является чисто объектно-ориентированным, просто он работает с реляционными базами данных через такие структуры, как Linq to SQL, из-за некоторого дерева выражений вуду и умного дизайна команды C #, делающего анонимные функции неявно конвертируемыми в деревья выражений.

Сотрудник: Давайте будем честными здесь. Синтаксис Linq отстой. Это сбивает с толку и не интуитивно понятно.

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

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

Что касается того, что является «интуитивным», то мне вспоминается история английского лингвиста, который изучал много разных языков и, наконец, пришел к выводу, что английский язык был лучшим из всех языков, потому что в английском слова встречаются в том же порядке, что и вы. думай им . В отличие от французского, где они постоянно говорят что-то вроде «собака белая ест мясо красное». Как трудно французам думать слова в правильном порядке, а затем произносить их во французском порядке! Французский такой не интуитивный! Удивительно, что французы говорят на нем. А немецкий? где они думают, что «собака ест мясо», но затем должны сказать «собака ест мясо»!?!

Часто то, что является «интуитивным», является просто вопросом знакомства. Мне потребовались месяцы работы с LINQ, прежде чем я перестал начинать свои запросы с предложением «select». Теперь это вторая натура, и порядок SQL кажется странным.

Который это! Правила области видимости все перепутаны в SQL. Что-то, на что вы могли бы обратить внимание коллеги, - это то, что LINQ был тщательно спроектирован так, чтобы (1) введение переменных и областей происходило слева направо (*) и (2) порядок появления запроса на странице был порядок, в котором он выполняется. То есть когда ты говоришь

from c in customers where c.City == "London" select c.Name

c появляется в области видимости слева и остается в области видимости справа. И порядок, в котором происходят вещи: сначала оцениваются «клиенты». Затем «где» оценивается для фильтрации последовательности. Затем отфильтрованная последовательность проецируется с помощью «выбора».

У SQL нет этого свойства. Если вы говорите

SELECT Name FROM Customers WHERE City = 'London'

затем «Имя» вводится в область видимости чем-то справа, а не слева, и запрос выполняется в полном беспорядочном порядке; сначала оценивается среднее предложение, затем последнее предложение, а затем первое предложение. Это сейчас кажется мне сумасшедшим и незаметным, ведь я так долго работал исключительно с LINQ.

(*) Правила области видимости немного странны в LINQ с предложениями объединения. Но кроме этого, области видны хорошо.

Как и все остальное в мире программирования, вы должны привыкнуть к синтаксису, и тогда его (потенциально) легче читать.

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

Как и все остальное в мире программирования, вы можете сделать это так или иначе.

Как и все остальное в мире программирования, ваш пробег может варьироваться.

Я увидел комментарий / замечание, в котором он что-то сказал - в отношении LINQ / lambda - в духе: «Пишите код, читаемый людьми, а не читаемый вашим компьютером».

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

Я гордился тем, что сделал свой код максимально читабельным и многократно используемым, и принял многие из принципов шаблонов проектирования GOF, чтобы предоставлять системы и сервисы качества производства во многих различных бизнес-секторах.

Когда я впервые столкнулся с лямбда-выражением, я подумал: «Что это, черт возьми, ?!» Это было сразу нелогично моему знакомому (и потому удобному) явному декларативному синтаксису. Младшие <5 лет на работе, ребята, однако, сложили это, как будто это была манна небесная!

Это потому, что в течение многих лет мыслить как компьютер (в синтаксическом смысле) очень легко переводилось в синтаксис прямого кодирования (независимо от языка). Если у вас было такое вычислительное мышление в течение примерно 20 лет (в моем случае 30+), вы должны понимать, что первоначальный синтаксический шок лямбда-выражения может легко перерасти в страх и недоверие.

Может быть, сотрудник в ОП произошел от меня, похожего на меня (то есть несколько раз был в этом районе), и это было для них нелогичным в то время? Мой вопрос: что вы с этим сделали? Пытались ли вы переучить своего сверстника в понимании преимуществ встроенного синтаксиса, или вы осудили / осудили его за то, что он «не участвует в программе»? Первый, вероятно, видел бы, как ваш коллега пришел к вашему образу мышления, а второй, вероятно, заставил бы их еще больше не доверять синтаксису LINQ / лямбда и, таким образом, усугубил бы негативное мнение.

Для себя я должен был перевоспитать свой собственный образ мышления (как выводит Эрик выше, это не незначительное изменение ума, и мне пришлось программировать в Миранде в 80-х, так что у меня был свой опыт функционального программирования) но как только я прошел через эту боль, преимущества были очевидны, но - что более важно - там, где его использование было чрезмерно использовано (то есть использовалось ради его использования), более сложным и повторяющимся (учитывая принцип СУХОЙ в этом случае).

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

Так что, когда кто-то говорит, что они "не получают лямбду?" или синтаксис LINQ, вместо того, чтобы рекламировать их, пытаться помочь им понять основные принципы. В конце концов, у них может быть «старая школа», как у меня.

Лямбда-выражения приводят к снижению читабельности кода, если запросы слишком длинные. Однако это намного лучше, чем слишком много вложенных циклов .

Это лучше со смесью двух .

Напишите это в Lambda, если это быстрее (вам нужно, чтобы это было быстро) или легче для чтения.

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

Я думаю, что ссылка помогает с первым, но часто (особенно при отладке) вредит второму.

ИМХО, когда я смотрю на код, я незнаком с первым, что гораздо важнее второго, поэтому я нахожу его гораздо более читабельным.

Я нахожу синтаксис LINQ интуитивно понятным и легким для чтения, тем более что они помещают FROM в начале, где он принадлежит, а не в середине, как в SQL. Но лямбды IMO сбивают с толку и затрудняют чтение кода.

Я согласен с вами, что синтаксис Linq существенно не отличается от T-SQL. Я думаю, что ваш коллега, возможно, действительно возражает против смешения реляционных вещей, в которых его красивый и блестящий ОО-код. С другой стороны, функциональное программирование требует некоторого привыкания и готовности к нему.

Это зависит. Очевидно, T-SQL однозначно предоставляет некоторые DB-реляционные решения. Очевидно, что LINQ однозначно предоставляет некоторые ОО-решения.

Тем не мение; "более запутанным, чем T-SQL?" - обсуждается / задается в первоначальном вопросе. Это явно подразумевает некоторые особенности, которые не рассматриваются ни в одном из существующих ответов, вместо этого обвиняя (очевидно, знакомого с SQL) критику в том, что он застрял в прошлом.

Поэтому, хотя я ценю LINQ за определенные качества и не сильно не согласен с существующими здесь ответами, я считаю, что контрапункт заслуживает представления:

Спустя годы после знакомства с LINQ выполнение определенных типов групповых операций, внешних объединений и неравных объединений, работа с составными ключами и другие операции в LINQ по-прежнему вызывают у меня беспокойство. (Особенно при нацеливании на реляционный сервер с вопросами, чувствительными к производительности.)

from c in categories
join p in products on c equals p.Category into ps
from p in ps.DefaultIfEmpty()

Если вы думаете, что это интуитивно, больше силы для вас. ;)

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

попробуйте показать эту функцию в linqlamdathings, и вы увидите, что вся красота исчезла, а классический способ остается читабельным. Не говоря уже о проблемах отложенного выполнения и установки точек останова.

Правда в том, что LinqLambda. В некоторых случаях они очень полезны, и считается, что они не заменяют всю изящную объектную ориентацию, которую вы, ребята, никогда не понимали.

    public IList<Customer> GetVipCustomers(IList<Customer> source, int maxCount)
    {
        var results = new SortedList<string,Customer>();

        foreach (Customer c in source)
        {
            if (maxCount == results.Count)
                break;

            if (c.IsVip && c.FirstName== "Aaron" || c.SecondName== "Aaron")
                results.Add(c.LastName, c);
        }

        return results.Values;
    }