Как и все исторические артефакты, Венгерская нотация когда-то имела смысл. А именно, это имело смысл при отсутствии проверки типов. Начните с того, что вы считаете целым числом, и каким-то образом получите массив с плавающей точкой. Страшно! Пользователи языка выбрали разумную идею включения типа переменной в качестве короткого префикса перед ее именем, чтобы упростить анализ программ и предотвратить ошибки.
В большинстве современных сред программирования это устаревшая потребность, а венгерская нотация имеет противоположный эффект. Языки и идеи вместе взятые делают (по крайней мере, почти) невозможным неправильное использование переменной данного типа. Это приводит к исчезновению преимуществ и появлению недостатков: код загроможден случайными буквами.
Пока все хорошо. Почему же тогда подобные модели все еще существуют на уровне класса? Возьмем наиболее очевидный пример – практику префикса интерфейсов буквой “I”, которая встречается в некоторых базах кода Java:
public interface IDataSource {
// ...
}
Было бы лучше, если бы интерфейс был просто назван Источник данных . Изменение Источника данных на Источник данных лучше, потому что нет необходимости придавать слишком большое значение вызывающему коду, который использует интерфейс. Стандартная практика в объектно-ориентированном языке, таком как Java, заключается в предпочтении интерфейсов из-за их многочисленных преимуществ перед классами. Если вы заинтересованы в более глубоком изучении причин, ознакомьтесь с Пункт 20 книги Джошуа Блоха, Эффективная Java .
Конечно, внесение такого изменения может привести к возникновению у вас другой проблемы. Если существующий код имеет Источник данных , , интерфейс и Источник данных , реализующий класс, тогда что вы делаете? Я видел код, в котором префикс просто заменяется на суффикс в классе, например, Источник данных интерфейс и DataSourceImpl
Если вам нужны примеры хорошего именования, посмотрите не дальше некоторых стандартных пакетов библиотек Java, таких как java.util. Коллекции. Там вы найдете интерфейсы типа List и реализации типа ArrayList или LinkedList . Почти всегда, немного подумав, вы обнаружите, что аналогичное, более конкретное имя может быть присвоено реализующему классу, с которым вы имеете дело. В примере Источник данных имя может быть таким же общим, как DBDataSource и это все равно было бы лучше, чем DataSourceImpl .
Другой связанной с этим практикой было включение типа переменной в ее имя. Например, вы можете увидеть Строку userJson или int count Int . К счастью, это встречается реже, но все равно прискорбно. Я думаю, что это происходит чаще всего, когда в редакторе нет механизма для отображения типа переменной. Если у вас нет ИДЕИ, которая показывала бы вам тип переменной при наведении курсора, нажатии ctrl + или чем-то еще, найти ее довольно легко. Я нашел такие механизмы в Visual Studio Code, Atom и IntelliJ, чтобы назвать лишь некоторые из них.
Более тревожной основной причиной такой практики является то, что объявление переменной далеко от ее использования. Если вы не видите, где userJson объявлен на том же экране, что и используется, рассмотрите возможность рефакторинга, чтобы сблизить их и удалить часть json .
Строго типизированный язык поможет устранить необходимость в таких “суффиксах типа”, предоставляя полезные языковые механизмы. В Scala, например, есть функция псевдонима типа, которая позволяет заменять имена типов в заданной области. Вы можете найти преимущество в возможности объявить тип например, и использовать Номер телефона пользователя ячейки в данном блоке кода вместо гораздо более запутанная Строка пользовательской ячейки .
Как всегда, тщательное рассмотрение как имен, так и типов позволит получить более читаемые программы. Настоящий тест заключается в том, можете ли вы передать какой-то код кому-то без контекста, и он все равно в основном сможет его понять. Анализ кода с новым разработчиком или кем-то из другой команды часто дает ценную информацию, которая в противном случае невозможна, поскольку мы все, так сказать, лягушки в кипящей воде. У нас постепенно развиваются слепые зоны для запутанных терминов, так как мы так привыкли к ним. Мне нравится всегда спрашивать себя что-то вроде: “Через десять лет, если я больше не буду работать в этой кодовой базе и даже не буду поблизости, сможет ли кто-нибудь открыть этот код и улучшить его или исправить ошибку с минимумом суеты?”
Я всегда считаю высшим комплиментом, если другим разработчикам нравится работать с моим кодом.
Оригинал: “https://dev.to/scottshipp/when-hungarian-notation-lies-hidden-in-plain-sight-372”