Неправильно именуйте непеременные

Это еще ладно, самое противное когда называют члены класса и локальные переменные(а еще хуже аргументы) в методе этого-же класса одинаковыми идентификаторами.

Справедливости ради многие такие «сокращения» — условно принятые сообществом соглашения. Например:

for(int i = 0; i < 10;i++){}

Сокращение? Да.
Осмысленное? Нет.
Условно принятое, как норма и применяемое повсеместно? Да.
Также и с лямбдами x.

Лично для себя выработал правило — если переменная «локальная» для одной функции (или даже для части функции — можно и сократить Dot до d. Но если уж сократил так в одном месте — давай точно такое-же сокращённое имя в других местах кода. Если переменная относительно глобальная (например, публичное свойство объекта класса) тут уж будь добр — дай осмысленное имя.

Всё зависит от области видимости переменной. Если это однострочник из 10 символов, то почему бы и нет? И это вполне читаемо:

IEnumerable<int> squares = Enumerable.Range(1, 10).Select(x => x * x);

А мне короткое имя в лямбдах в одно выражение вполне ок. В котлине вон есть it и тоже неплохо для простых выражений.

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

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

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

Ну, в приницпе, всё зависит и от типа переменной и от длины кода.

Если x'ом назвать экземпляр класса, то почему нет? Ничего страшного в этом я не вижу для читаемости. С учётом того, какие атрибуты икс будет иметь и что у него будет вызываться и так будет понятно что это за переменная.

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

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

Где-то читал (может у Макконнелла), что короткие имена дают техническим переменным, которые нужны для организации работы программы, а не для моделирования предметной области. И на мой взгляд это правильно. Чем меньше у них семантики, тем меньше они обращают на себя внимание. Алиасы таблиц в SQL относятся сюда же, они используются для указания движку, какое поле имеется в виду.

Сравните:

for (int i = 0; i < users.Count; i++)
{
    var user = users[i];
    ...
}

foreach (var user in users)
{
    ...
}

Поменяли тип цикла, техническая переменная ушла в движок языка.

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

Если не сокращать, то будет у меня имя альяса 20 символов и имя поля ещё 20 символов, итого 40 символов на ровно одно поле, это пол строки, для экрана широкоформатника — треть, на мой вкус жирно, для одного поля столько от строки отъедать.
Запросы не всегда в две строки пишутся, для меня это как правило джоины от двух до пяти таблиц, иногда с формулами во фразе SELECT, и подзапросом или двумя во фразе WHERE, раздуть всё это полными именами таблиц? ещё и так что бы альяс был говорящим в рамках запроса?
Нет я конечно очень не доволен ORACLE SQL где имя объекта ограничено в 30 символов и очень рад PostgreSQL где можно использовать аж 64 символа, но не настолько что бы в запросе повторять все 64 символа для каждого поля таблицы.

Другое дело в коде программы, там другое дело, там счётчик это counter / index / element и другие более осмысленные именования, потому что тоже вложенность бывает на пару уровней и если использовать «i», «j», «k» очень легко сбиться.

Пишу на Delphi. Придерживаюсь простого правила. Все значимые переменные обязательно именую. Незначимые — временные, циклические и т.п. пишу короткими (как правило — одно-буквенными). Мне кажется оптимальный вариант.

Если у точки координаты X, Y, Z, то никто в здравом уме не будет их называть как координатаПоОси<имя оси>. В этом плане мне мешают плохо именованные объекты – много писанины, за которой смысла не видно.

А вот сущности, описывающие объекты предметной области, не грех и обозвать подробнее, тем более, что название и придумывать не надо, оно уже есть в предметной области. Это действительно улучшает понимание кода.

Какие то некорректные примеры «вредных» книжных примеров приведены. Если в лямбдах переменные называть длинно, то их еще и на несколько строк придется разбивать, а ведь переменная даже за их пределы не выйдет. Другое дело — какие-нибудь большие вложенные циклы, сравнимые с вашими 15ти строчными sql запросыми, где привычные i и y тоже могут боком выйти. Это тоже самое, что и с паттернами и уметь определять где с таким именованием будет лучше, а где вредно.

На C# привык в простых лямбдах ставить знак _ вместо буквы (особенно, когда без разницы — какую букву использовать). Потому, что так лучше видно, какие методы/свойства задействованы в лямбде. Из Лиспа что-ли это тянется…

Могу предположить, что в будущем IDE научатся сами сокращать/восстанавливать имена переменных в зависимости от настроек. Например, когда закончил работать над каким-то методом, все его внутренние переменные и структуры коллапсируют во что-то более компактное. Так, чтобы он занимал меньше места на экране и лучшим образом показывался алгоритм/структура метода. А когда нужно снова поработать над кодом — он обратно распаковывается в читаемые осмысленные переменные и структуры.

Когда в выражении более одного сокращения — это уже плохо.