Избегайте имен, которые меняются от места к месту
Обоснование
Хуже всего, когда имя атрибута меняется от таблицы к таблице. Рассмотрим в качестве примера слегка подчищенный фрагмент кода из группы новостей, посвященной SQL
SELECT Incident.Type, IPC.DefendantType,
Recommendation.Notes, Offence.StartDate, Offence.EndDate,
Offence.ReportedDateTime, IPC.URN
FROM IPC
INNER JOIN Incident ON IPC.URN = Incident.IPCURN
INNER JOIN IncidentOffence ON Incident.URN = IncidentOffence.IncidentURN
INNER JOIN Offence ON Offence.URN = IncidentOffence.OffenceURN
INNER JOIN IPCRecommendation ON IPCURN = IPCRecommendation.IPCURN
INNER JOIN Recommendation ON IPCRecommendation.RecommendationID = Recommendation.ID;
Полные имена таблиц трудно читать, но новичок, написавший код, считал, что имя таблицы обязательно должно быть частью имени столбца. Ведь в старых программах на Коболе все было именно так! Это означает, что если у вас есть сотня таблиц, в каждой из них один и тот же атрибут будет иметь новое имя, поэтому о нормальном словаре данных вам остается только мечтать. Кстати, обратили внимание, как рябит в глазах от множества точек?
Теперь взгляните на исправленную версию, которая четко центрирована на таблице IPC (схема-“звезда”).
SELECT 11.incident_type,IPC.defendant_type, R1.notes,
01.start_date,01.end_date, 01.reported_datetime,IPC.urn
FROM Incidents AS 11, IPC, Recommendations AS R1, Offences AS 01,
WHERE IPC. recommendation_id = R1.recommendation_id
AND IPC.urn = 01.urn AND IPC.urn = 11.urn
AND IPC.urn = RLurn AND 11.urn = 01.urn;
Я понятия не имею, что такое URN, но в данном случае понятно, что речь идет о каком-то стандартном для этой задачи идентификаторе. А теперь взгляните на разнообразные URN в оригинальном запросе — URN, IPCURN, OffenseURN... Чувствуешь себя, как в сувенирной лавке при крематории.
Вы меняете свое имя, переходя из комнаты в комнату? Конечно, нет! Вот так и корректное имя элемента данных зависит от его смысла, а не расположения.
Исключения
В запросе элементу данных можно дать временное новое имя (псевдоним), которое удаляется после выполнения выражения. Подробнее об этом — в разделе “Имена корреляций подчинены тем же правилам, что и другие имена. Почти всегда”.
Не используйте нестандартные физические указатели
Обоснование
Главный принцип современного моделирования данных — разделение логической модели и физической реализации. Это позволяет использовать одну и ту же модель на различных платформах.
В старые добрые времена логическая и физическая реализации были неразделимы. Подробно я буду говорить об этом в главе 3, пока же просто правило — не применяйте нестандартные физические указатели. Они противоречат самой идее ключа в реляционной модели.
Стремление новообращенных программистов SQL использовать IDENTITY, GUID, ROWID или другое нестандартное средство автонумерации в качестве ключа проистекает из привычки работать с магнитными лентами. Им хочется знать, в каком порядке строки добавлялись к БД, точно так же, как раньше им нужно было знать порядок добавления записей в конец магнитной ленты!
Исключения
Ну разве что вам действительно зачем-то нужно имитировать файл последовательного доступа с помощью таблицы SQL, не беспокоясь о целостности данных.
ГЛАВА 2.
Шрифты, пунктуация и интервалы
Программы обычно отображаются с помощью моноширинных шрифтов. За более чем столетнюю историю пишущих машинок и десятилетия перфокарт мы убедились, что в моноширинном варианте код действительно легче читается. В частности, знаки препинания в этом случае занимают такое же пространство, как и буквы, тогда как в пропорциональных шрифтах они бы зачастую просто терялись.
Типографика кода
При работе с программами ваши глаза и мозг действуют не так, как действуют они при чтении, счете, работе с картой или разглядывании картинок. Кроме того, имеется масса индивидуальных различий между людьми.
Некоторым нравятся текстовые редакторы, в которых элементы синтаксиса языка программирования отображаются разными цветами. Другие считают это многоцветье поводом для головной боли и предпочитают простой черно-белый текст. Конечно, невозможно было бы, например, читать газету, в которой существительные напечатаны красной краской, глаголы — зеленой и т.п. С другой стороны, разбираться с черно-белой картой значительно сложнее, чем с цветной. Почему? Это связано с различиями в восприятии цвета.
Есть такой тест на предмет выявления повреждений мозга. Проверяющий показывает пациенту карточки, на которых слова напечатаны различными цветами (например, слово “красный”, напечатанное зеленой краской), спрашивает его о смысле слов и записывает время, которое уходит на получение ответа. Время это на протяжении жизни человека само по себе меняется мало, поэтому зафиксированное изменение является симптомом физической или химической перемены. Теперь прочтите следующее:
Война
в Крыму.
Все в
в дыму.
При первом прочтении практически никто не замечает, что один из предлогов “в” напечатан дважды. Это — особенность того, как мы просматриваем блоки слов в вертикальном направлении. Она важна при работе с кодом: при чтении программ глаз совершает множество вертикальных движений, которых нет при чтении простого текста.
Несколько лет назад по Интернету гулял следующий текст:
“Солгсано унёчым из Кмерибжда, внажо, чотбы на сове мтесо в своле пдалопаи паврея и псоелндяя бквуы. Дуигре бувкы мугот сяттоь в бе-сопдярке, но ткест всё рнаво бдеут чтатьися без порлбем. Это сявпазо с тем, что мзог човеекла чтаеит не оыетдльне бвкуы, а цыеле совла”.
Я не уверен, что этот фрагмент действительно имеет своим источником Кембриджский университет, но в качестве иллюстрации он нам подходит. Поскольку компилятор гарантирует отсутствие в коде опечаток, читатель знает, что ему ожидать от следующего слова, с гораздо большей уверенностью, чем при чтении обычного текста. Тут уж слова не просто воспринимаются, как целое, они еще и ожидаемы. Скажем, увидев в программе на Паскале или другом языке из семейства Алгола ключевое слово “IF”, я ожидаю, что выражение закончится ключевым словом “THEN”.
Давайте поговорим о некоторых основных правилах набора программ, которые опираются на то, как люди читают код.