Имена переменных лямбды - короткое имя или короткое имя?

Ответ 1

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

IE:

myCollection.Where(person =>....); //non descriptive collection name

myPeopleCollection.Where(p=>...); // descriptive collection name

Ответ 2

Я пытаюсь использовать однословные, но содержательные имена. Поэтому я хотел бы использовать "person", а не "p", но не пошел бы за "newAddedPerson".

Это также относится к выражениям запросов - я вполне могу это нарушить в примерах быстрого выброса, но мне обычно не нравится:

from p in source
where p.Age > 10
select p.Name;

Я бы скорее посмотрел

from person in source
where person.Age > 10
select person.Name;

Ответ 3

Мне нравится короткая вещь. Я делаю это все время. Я в основном использую i, y, x в lambdas, но я использую a, b, c, d в sql.

Ответ 4

Я бы сказал, что согласен с BFree. Для меня это будет зависеть от контекста, но я всегда стараюсь сделать его максимально "кратким". Заметьте, я говорю краткое, а не краткое или короткое.

Здесь два примера на диалекте LISP Clojure:

user=> (def names ["ryan" "bob" "tom" "tim"])
#'user/names

user=> (filter (fn [name] (.startsWith name "t")) names)
("tom" "tim")

Для тех, кто не знает Lisp/Clojure, моя лямбда является аргументом функции "фильтр". То есть "(fn [name]....)". Я решил использовать здесь "имя", потому что он короткий, но описывает, с чем я работаю. Тем не менее, я думаю, что "a", "i", "x" и т.д. Будут такими же читаемыми.

user=> (def odds (iterate (fn [n] (+ n 2)) 1))
#'user/odds

user=> (take 5 odds)
(1 3 5 7 9)

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

Я, конечно, НЕ использовал бы имена "nameOfPerson" или "previousOddNumber". Это просто ПУТЬ слишком много информации. Я также пытаюсь сохранить типы из моих имен большую часть времени, например. 'NameString. Я часто нахожу такие вещи, как большую часть времени, чтобы быть лишней информацией.

Лично я считаю, что дополнительные многословные имена, как правило, связаны с идеей, что она помогает документировать код. Это особенно распространено в таких языках, как Java/С#. Я думаю, это можно было бы утверждать в обоих направлениях, в зависимости от стиля программиста. Тем не менее, чем более подробное имя, тем более жестким (читаемым хрупким) может стать код. Если мое имя очень специфично, и функция часто меняется, то, скорее всего, имя тоже сильно изменится. В конце концов, DEV может стать ленивым, и вы получите имя, которое фактически не описывает, для чего используется переменная. Это не проблема, если и только если программист не считает, что имя правильное. Конечно, это, вероятно, будет быстро выяснено во время компиляции (потому что программист попытается разделить две строки или какую-нибудь такую ​​вещь), но это может привести к растрате времени и путанице в крупных проектах.

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

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

Извините за книгу.

Ответ 5

Наша команда не разрешает однобуквенные переменные, а не событие в lamdas.

То, что мы находим, так же, как и в TSQL, чем дольше работает код, тем более запутанным он становится. Что касается лямбды

Мы сделали бы что-то вроде этого:

people.Where(personFound => personFound.FirstName.Contains("blah!"));

Таким образом, следующий разработчик не будет смотреть на

people.Where(p => p.FirstName.Contains("blah"));

Это кажется читаемым, но он всегда делает это сначала

Как насчет присоединения

citizenShip.Join(people, c => c.personid, p => p.persoinid, (p, c) => new { p.FirstName, c.IsCitizen})
.Where(pc => pc.FirstName.Contains("blah");

то же самое с именами переменных

citizenShip.Join(people, 
                 citizenToJoin => citizenToJoin.personid, 
                 personToJoin => personToJoin.persoinid, 
                 (joinedPerson, joinedCitiznship) => 
                     new { joinedPerson.FirstName, joinedCitiznship.IsCitizen})
.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah");

О, но это запутанно и уродливо. Просто используйте отличительные буквы, чтобы они менее запутывали

citizenShip.Join(people, 
                 c => c.personid, 
                 p => p.persoinid, 
                 (jp, pc) => 
                     new { jp.FirstName, jc.IsCitizen})
.Where(pc => pc.FirstName.Contains("blah");

Все еще запутанно, но теперь его хуже. Таким образом, мы ломаем лямбду, поэтому мы реформатор для удобочитаемости

var peopleWithCitizenship = citizenShip.Join(people, 
                                             citizenToJoin => citizenToJoin.personid, 
                                             personToJoin => personToJoin.persoinid, 
                                             (joinedPerson, joinedCitiznship) => new { joinedPerson.FirstName, joinedCitiznship.IsCitizen});

var peopleWithCitizenshipFilteredByName = peopleWithCitizenship.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah"));

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

Ответ 6

Возможно, у вас много вопросов, чтобы задать вопрос "консенсус" в отношении "именования".:)

Я согласен с тем, что "важность хорошего имени" пропорциональна объему имени. Джон Скит отвечает предпочитая

from person in source ...

является убедительным, но если имя используется много, и особенно если ввод лучше назван, я думаю, что предпочитаю

from p in persons ...

Ответ 7

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

Persons.Where(p => ...)
AnalysisCode.Where(ac => ...)

Ответ 8

Как правило, я думаю, что чем более явным вы являетесь с именами переменных/объектов/методов, тем лучше. Поскольку мы часто тратим большую часть времени на чтение кода других людей, тем легче нам понять, чем быстрее вы сможете сосредоточиться на синтаксисе и на логике. В наши дни с IntelliSense и т.д., На самом деле это не может быть ошибкой на стороне ясности, когда это возможно.

Ответ 9

Я согласен с @Johnny Wey; назовите свои переменные - по той же причине вы называете их в любом другом коде! Не поймите это превалирование от ясности только из-за "встроенного" характера кода. Считываемость является ключевым - с первого взгляда/без необходимости "зависать" над вещами; в противном случае вы могли бы также сказать, что никакая переменная не должна быть названа соответствующим образом. Может быть, небольшая свобода, если она используется с чем-то "Enuerable", но все же приятно видеть (снова с первого взгляда), что черт делает код. Если вывод типа переменной опирается на какой-то общий тип, переданный в класс или что-то еще, c'mon, назовите его. Сделать весь код прочитанным как предложение; компьютеры должны адаптироваться к нам ( "гуманизировать" ), а не наоборот, где мы начинаем действовать как компьютеры и становимся загадочными только потому, что мы можем/чувствовать себя умнее/больше, чем технические выродки, когда мы делаем (искушение есть, я KNO!). Легко ввести четкое имя, и у вас все еще есть все варианты завершения Intellisense/предложения, которые вы используете в названных методах. Кроме того, зависание в случае с lambdas не всегда дает вам информацию о var (расстраивает во время отладки), поэтому приятно видеть "ясное/представительное" имя, особенно для новых разработчиков, которые не прошли через всю психическую гимнастику быть в состоянии вывести типы, пройдя контекст оператора (который также может быть загадочным).

Ответ 10

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

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

public Foo Do()
{
    return Do(_ => true);
}

public Foo Do(Func<T, bool> pattern)
{
    return SomethingElse(pattern);
}

Ответ 11

Основываясь на приведенных выше ответах, я думаю, что существует общее мнение о том, что, если вы не можете сказать из контекста, с чем имеете дело, лучше использовать описательное имя. Например:

entities.Where(person => person.Age >= 21);

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

people.Where(p => p.Age >= 21); или people.Where(x => x.Age >= 21);

Вопрос в том, что лучше, p или x?

• В пользу p, это знакомый шаблон в SQL-запросах и дает немного дополнительного напоминания о том, что вы говорите о Person.
• В пользу x, если вы переименуете Person в Customer, вам не нужно беспокоиться об исправлении всех ваших параметров лямбда. Если вы использовали p, на самом деле было бы немного запутать, если ваш код стал customers.Where(p => p.Age >= 21), тогда как x в основном агностик.

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