Имена переменной лямбды - к краткому названию, или не к краткому названию? [закрытый]

Я пытаюсь использовать но понятные имена однословные. Таким образом, я был бы склоняться для использования "человека", а не "p", но не пошел бы для "newlyAddedPerson".

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

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

я видел бы

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

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

Я сказал бы, что соглашаюсь с 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 [имя]....)". Я принял решение использовать 'имя' здесь, потому что это коротко, но описывает точно, с чем я работаю. Однако я думаю, 'я', 'x', и т.д. был бы так же читаем.

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

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

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

я, конечно, НЕ использовал бы имена 'nameOfPerson' или 'previousOddNumber'. Это - просто Слишком много информации. Я также пытаюсь не допустить типы в свои имена большую часть времени, например, 'nameString'. Я нахожу, что материал как этот, большую часть времени, лишняя информация.

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

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

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

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

Это может просить, чтобы много задало вопрос для 'согласия' по 'именованию'.:)

я соглашаюсь, что 'важность хорошего имени' пропорциональна объему имени. Ответ Jon Skeet предпочтения

from person in source ...

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

from p in persons ...

Я иду с один, две или три буквы, которые формируют сокращенное представление рассматриваемого объекта.

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

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