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

Все началось лет 8 назад. Я тогда писал одну программу для математических расчетов, и мой преподаватель указал, что я неверно именую переменные. Он был прав: x, xx, xxx сложновато различить в коде. После переименования они превратились в redSegment, greenSegment, blueSegment (в контексте задачи именование было подходящее). Потом были «Рефакторинг» Фаулера, «Совершенный код» Макконнелла, «Паттерны проектирования» банды четырех… каждый день я погружался все глубже в бездну.

В моей текущей компании никто не упоминает о правильном именовании переменных, это несерьезно. Мы обсуждаем с коллегами стили именования тестов, стоит ли использовать TestCase атрибут в nUnit, спорим о целесообразности #region в C#, пишем кастомные анализаторы для своих проектов и пьем смузи вообще всячески наслаждаемся жизнью.

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

foreach (Dot d in dots)
{
    WriteToOutput(d.X, d.Y);
}

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

Через пару часов я наткнулся на код в sql скрипте

select u.* from Users u

Еще через несколько минут в соседнем скрипте обнаружился кусок

select u.UserName, b.Locked, d.PropertyValueStrings
from Users u
join Bindings b on b.UserId = u.UserId
join Dossiers d on d.UserId = u.UserId
where u.UserName = 'USERNAME'

Последовал диалог с автором:

— Почему ты используешь u,b,d вместо нормальных имен?
— Так короче.

Вы знаете, этот аргумент абсолютно верен. Действительно, так короче.

А как насчет

select bi.BusinessIdentifir, bia.SSAFA, IsNull(bia.Bullshit, ‘Bullshit’), bis1.*, bis2.*, bis.*
from businessItems bi 
    inner join businessItemsArtifacts bia on ...
    inner join businessItemsSegment bis1 on ...
    inner join businessItemsSegment bis2 on ...
    inner join businessItemsSegment bis3 on ...
where 
bia.Date = @creationDate
and bi.Staus = ‘RFW’
AND
(
	(bis1.SignIn = ‘Europe’ and ss2.Limit = 42 and bis3.Connection not in (‘Towel’, ‘Galaxy’))
OR
	(bis1.SignIn = ‘USA’ and ss3.Limit = 146 and bis2.Connection not in (‘Trump’, ‘Klinton’))
	OR
(bis1.PNH = ‘SP’ and ss2.Limit = 21 and bis3.Connection not in (‘Stan’, ‘Kyle’, 'Cartman'))	
)

Запрос и так полон специфических констант и фильтров, неужели нужно усложнить его bis1, bis2, bis3?

Но добил меня

SELECT 
     MFID# as MemberId,
     TRIM(ACX) as FirstName,
     TRIM(ABX) as LastName,
     TRIM(FGS) as Suffix,								
     TRIM(c.DSC) as Country,
     TRIM(mm.CCC) as CountryCode,								
FROM {0}.mailfl
    LEFT OUTER JOIN BDSMTAMDRT.MEMFLT mm ON MFID# = mm.MMID#
    LEFT OUTER JOIN BDSMTAMDRT.CTRCOD c ON mm.CCC = c.CCTRY
WHERE mfid# = ?

Автор дал вменяемые имена выбираемым полям, но не поименовал таблицы.

Знаете, откуда берется эта привычка у шарпистов? Из учебной литературы.

Открываем Шилдта:

var posNums = nums.Where(n => n > 0).Select(r => r);

Открываю msdn:

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

Открываю Троелсена:

List<int> evenNumbers = list.FindAll(i => (i % 2) == 0);

Metanit, professorweb — везде вылезает

numbers.Select(n => ...), teams.Select(t => ...)

А потом в коде возникают артефакты вроде

team.Select( p => p.Age > 18);

Еще одна причина появления «коротышек»: изменения в коде. Был однострочный запрос с таблицей Products, городить именования не особо нужно, оставили p. Потом добавили join на ProductGroups, появилась pg, просто чтобы не изменять текущий стиль. Потом кусок кода скопипастили в другой запрос, там join на Profiles, в итоге имеем p, pg, pr.

Вместо послесловия. На самом деле проблема вовсе не в «плохом» коде. Проблема в том, что подобные куски попадаются мне уже год, а внимания на них я обратил лишь сейчас. Возникает вопрос: сколько еще недочетов лежит на самом видном месте?