Все началось лет 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.
Вместо послесловия. На самом деле проблема вовсе не в «плохом» коде. Проблема в том, что подобные куски попадаются мне уже год, а внимания на них я обратил лишь сейчас. Возникает вопрос: сколько еще недочетов лежит на самом видном месте?
ссылка на оригинал статьи https://habrahabr.ru/post/328278/
Добавить комментарий