Более чистый код с венгерской нотацией
Преодолевайте ограничения, накладываемые английским языком, чтобы лучше организовать и быстрее интерпретировать свою работу.
Предисловие
Вы помните, как вы научились форматировать даты календаря для буквенно-цифровой сортировки? У вас либо были даты в американском формате первый месяц, например 09–11–1991 или в европейском формате первый день, например 11–09–1991, и вы поняли, что сортировка не работает. Сортировка по дате должна происходить сначала по году, затем по месяцу и, наконец, по дню месяца, например 1991–09–11.
Или - вы помните, когда вы изучили передовой опыт более четкого именования переменных, методов и классов? Возможно, это произошло, когда вы смотрели на чужой код и понятия не имели, что означает переменная isOvrLn… или функция с именем mkZro ();
Ха! Я инстинктивно закончил последнее предложение точкой с запятой.
В любом случае, я пытаюсь здесь сказать, что все меняется с того момента, как вы осознаете эти лучшие методы кодирования. Иногда урок оказывает такое влияние, что вы вынуждены вернуться и провести рефакторинг унаследованного кода, чтобы помочь будущим читателям и избежать возможных затруднений.
Другое прозрение, подобное этому, снова случилось со мной недавно - через двадцать лет моей карьеры программиста.
Венгерская нотация
Вот ссылка на Википедию для напоминания - это относительно древняя концепция, которая сводится к идее, что вы можете захотеть назвать что-то в коде, например переменная, класс, интерфейс и т. д. - путем включения информации о том, что это такое, т. е. о его типе.
Венгерская нотация остается спорной, поэтому в этой статье я собираюсь сосредоточиться на одном из моих конкретных вариантов использования и на том, почему я думаю, что это работает.
Пример продукта данных микробиома
Здесь я использую шаблоны JSON с низким кодом для определения продукта данных Tag.bio из исходных файлов данных. Вы должны уметь следовать этим примерам, не зная синтаксиса Tag.bio.
Этот файл верхнего уровня - config.json - описывает все файлы и функции, необходимые для создания модели данных.
Обратите внимание, как мы используем пути к файлам для ссылки на вложенный код: файлы, содержащие объекты table, имеют префикс table_, а файлы, содержащие объекты parser, имеют префикс парсеры_.
Вы можете заметить, что объектные файлы table уже находятся в папке с именем tables /, а объектные файлы анализатора уже находятся в папке с именем парсеры /. Итак, почему избыточность?
Потому что я не всегда смотрю файл по его полному пути. Часто я смотрю на имя файла как на вкладку в редакторе.
Здесь мы используем префиксы type, чтобы различать объектный файл table и объектный файл синтаксического анализатора для одних и тех же генных семейств. аспект.
Более того, при просмотре многих файлов, перечисленных в представлении «Проводник» моей IDE, я хочу быстро понять назначение каждого файла, прямо по имени файла, и мне не нужно было визуально сканировать, чтобы идентифицировать родительскую папку.
Зачем использовать префиксы вместо суффиксов?
Вот здесь и помогает ненадолго отойти от английского языка. В английском языке мы ставим прилагательные перед существительными - то есть большая река. Во многих других языках прилагательные ставятся после существительных, то есть el rio grande на испанском языке.
Учитывая тот факт, что код в этой статье - и явная большая часть всего кода, когда-либо написанного - написан на английском языке, почему мы решили назвать файл table_genefamilies.json, а не genefamilies_table.json ? Это не так очевидно. Когда мы с коллегами говорим об этих объектах, мы однозначно говорим «таблица геносемейств», а не «таблица геносемейств».
Мой аргумент в пользу использования префиксов венгерской нотации - в данном конкретном случае - снова связан с IDE и с тем, как имена файлов организованы, отображаются и сортируются.
Когда у вас открыто много вкладок редактора, имена файлов часто обрезаются. При использовании префиксов самая важная часть имени - в данном случае тип - вырезается последней.
При построении иерархии папок мы уже объявили тип каждого объекта более важным, чем аспект, т. Е. парсеры помещаются в папку parsers /, а таблицы помещаются в папку tables /.
Префиксы не только дают понять, какой тип объекта содержит каждый файл, но и избыточность префиксов - выровненных по горизонтали слева - дает понять, в какую родительскую папку я ищу.
Установив, что я нахожусь в папке parsers / и просматриваю объекты parser, я могу затем выполнить вертикальное сканирование по крайнему правому «столбцу» информации, чтобы определить конкретный файл, который мне нужно открыть, или чтобы быстро понять объем всех файлов в этой папке.
Стоит отметить, что в Tag.bio мы установили соглашение, согласно которому наши файлы JSON должны быть организованы сначала по типу, а затем по аспекту. Мы предпочитаем более широкие папки с меньшим количеством вложений, и мы часто копируем / вставляем полезный код между файлами одного и того же типа. Разработчики чаще работают с несколькими таблицами или несколькими синтаксическими анализаторами и реже работают с одним аспектом, например генные семьи.
Иногда суффиксы могут быть лучше
Переключение на другой пример кода - поскольку я заметил в мире веб-приложений, фреймворки, такие как Angular, перешли на соглашения, в которых код организован в основном по аспекту, а не по типу .
В этом примере из кодовой базы веб-приложения Tag.bio (Angular) мы группируем файлы вокруг страницы пользователя аспект, включая файлы разных типов в той же папке. . Здесь лучше подходит венгерская нотация с суффиксами для типа, т. Е. расширениями файлов.
Сообщество Angular осознало, что разработчики часто работают над файлами, относящимися к определенному аспекту - например, user.component - и реже работает с файлами, относящимися к определенному типу - например, .css.
Если подумать, расширения файлов, вероятно, являются наименее спорной формой венгерской нотации.
Разве все это не очевидно?
Что ж, проверьте свою кодовую базу (и) и решите сами, достаточно ли понятны имена файлов. Сможет ли другой разработчик понять назначение каждого файла, просто прочитав его имя?
Спасибо за прочтение!
