Я помешан на соглашениях об именах. Серьезно. Я предполагаю, что это мышление разработчика/оператора, но одной из самых важных частей любого проекта являются имена, которые вы используете для различных частей этого проекта.
Я был музыкантом в течение достаточно долгого времени, и у меня было много практики в искусстве давать названия песням, альбомам, группам и тому подобному. Для песен вы иногда хотите, чтобы название отражало общий смысл указанной песни. Иногда вам нужно имя, которое зависит только от контекста и намекает на смысл. Иногда названия ваших песен нестандартны или совершенно нелогичны. То же самое касается и названий групп и альбомов.
В программировании имена методов, проектов и т. д. следуют общим соглашениям, а также более конкретным соглашениям, принятым во время создания (и иногда измененным и рефакторинговым по ходу дела). При именовании классов и методов вы хотите дать следующему программисту представление о том, какова цель класса/метода. Если метод получает текущую дату и время и присваивает их переменной, вы НЕ хотите вызывать метод «calendarMethod» или что-то общее и в основном двусмысленное. Конечно, по такому названию можно было бы, ПО КРАЙНЕЙ МЕРЕ, установить, что метод имеет какое-то отношение к дате. Вы можете назвать метод чем-то вроде «dateTimeVarAssign». Вкратце, любой программист, плохо знакомый с проектом, может легко понять, что этот метод получает дату и время и присваивает их переменной. Это соглашение должно распространяться и на классы.
Точно так же переменные должны быть названы так, чтобы они имели контекстуальный смысл, но также, по крайней мере, намекали на то, для чего они предназначены, и при этом не были слишком многословными. Вы не хотели бы называть свою возвращаемую переменную «dateTimeVarAssign» «smurfAntler», потому что это не имеет никакого контекстуального смысла. Точно так же вы не хотели бы называть его «stringWhichWillBeUsedLaterThatContainsTheCurrentRuntimeDateAndTimeFormatted». Это просто слишком долго, чтобы быть полезным. Вместо этого приемлемо, понятно и читабельно что-то вроде «runtimeDateTime» или просто «dateTime».
Для таких артефактов, как папки и другие иерархические структуры, ключевым фактором является организация. Если то, что вы пишете, должно иметь начальное число (например, в случае с последовательными тестовыми классами JUnit для запуска), вполне приемлемо включать их, но обязательно используйте подчеркивание при отделении числа от имени. На самом деле подчеркивание является довольно распространенным разделителем в программировании. Они очень приятны для глаз, и их включение приводит к тенденции быстро сканировать предметы и находить то, что вы ищете. Папка с именем «01_Financial_Information_FINAL» легко читается в контексте файлового менеджера, а также предлагает нам контекстное резюме: этот файл содержит финансовую информацию, которая больше не находится в состоянии черновика и имеет идентификатор «01», который нужно сохранить. он находится на вершине иерархии, что указывает на его потенциальную важность в общей схеме вещей. С другой стороны, файл или папка под названием «Dean Walker Financials» не дает нам никаких указаний на ценность содержимого или даже на самом содержимом. Если бы это был файл в единственном числе, я бы спросил себя: «Почему «финансы» во множественном числе? Если есть более одного набора «финансов», не следует ли их разделить и поместить в папку?» — Видишь, что я там делал? Потому что, если бы это была папка, в этом был бы хоть какой-то смысл, но мы все равно не до конца понимаем, на первый взгляд, что в папке. Что за финансы? Это финансовая информация или финансовая отчетность? Кто такой Дин Уокер и какое отношение он имеет к проекту?
Я бы ошибся из-за осторожности и переименовал приведенный выше пример, включив в него некоторую цель и приоритет. Возможно, что-то вроде «01_Financial_Information_DRAFT_DWalker» было бы более подходящим в этом случае. Теперь мы можем легко увидеть приоритет (помеченный «01»), содержание («Финансовая информация»), состояние (обозначенное «ЧЕРНОВИК») и, в данном случае, автора, «Дуокер», сокращение от Дина Уокера. . Обычно вы можете сокращать (в разумных пределах) и сокращать имена файлов и папок, не теряя при этом точности.
Более важно, чем все это, СОБЛЮДЕНИЕ соглашений об именах чрезвычайно важно. Например, если у вас есть две папки
01_Financial_Info_DRAFT_DWalker
02_Банк_Контакты_FINAL_DWalker
…и переходим к присвоению имени следующей последовательной папке
Разное
…вы можете попасть в горячую воду, и быстро! Можно сказать, что хотя ваше имя должно быть контекстуальным, способ организации также будет контекстуальным зверем со многими головами. Папка с именем «Разное» полностью нарушает установленные соглашения об именах и совершенно расплывчата. Я не говорю, что папка «Разное» — это нехорошо, просто КОНТЕКСТУАЛЬНО она сейчас ничего не значит. И может случиться так, что вы не совсем уверены, куда или в какую категорию поместятся файлы в этой папке, что вполне понятно, но, по крайней мере, вы должны продолжать использовать установленные соглашения, пока не разберетесь во всем.
01_Financial_Info_DRAFT_DWalker
02_Банк_Контакты_FINAL_DWalker
03_Miscellaneous_Docs_DRAFT_DWalker
Таким образом, соглашения об именах и общая номенклатура проекта могут быть столь же важны, как и все остальное, содержащееся в самом проекте. Легко понятные, понятные, контекстуальные имена могут упростить организацию и последовательность основных элементов любого проекта, в котором вы участвуете.
