06.10.2010, 13:23 | #1 |
Участник
|
Префиксы-суффиксы. Как лучше? Стоит ли избавляться от них?
Есть клиент.
Теперь с ним работаем мы. Но раньше с ним кто только не работал. Поколения разработчиков использовали префиксы (как это рекомендовалось в ранних бест-практисах) в результате сейчас нередки подобные названия DDD_Codes.KKK_XXX_LL_OKVED. (где ККК, ХХХ, LL - префиксы) Поскольку кастомизированных таблиц и полей много, то сложно запомнить какие префиксы и в какой момент нужно использовать. Что выбешивает. Вопросы: = что лучше использовать на ваш взгляд для того, чтобы обозначить разработчика - префиксы/суффиксы/ничего? = вы бы стали рефакторить приложение, избавляясь от префиксов (или превращая их в суффиксы)? каковы плюсы и минусы такого рефакторинга? А также хотелось бы услышать ваше мнения и размышления по поводу префиксов/суффиксов. Используете ли вы префиксы/суффиксы? Когда они вам пригодились, а когда нет? По-моему - префиксы/суффиксы совершенно бесполезная штука. Где я ошибаюсь? Заранее спасибо. =============== добавлено 26.10.10: итог обсуждения подвел Владимир Максимов добавлено 26.10.10: создана тема Префиксы-суффиксы. Какой инструмент лучше использовать чтобы избавиться от префиксов? Последний раз редактировалось mazzy; 26.10.2010 в 15:48. Причина: добавлена ссылка на итог обсуждения. |
|
06.10.2010, 13:32 | #2 |
Участник
|
Имхо префиксы нужны как неймспейсы для бедных. Чтобы не было случайных пересечений имён (кстати, хороший критерий системы именования - если создавая обхект для какой-то надобности обнаруживаешь уже созданный объект для той же самой надобности уже так же поименованный).
Количество префиксов/суффиксов должно быть равно количеству различных реестров, в которых учитываются имена. Например, если есть 10 партнерских решений, которые могут обновиться независимо, то должно быть 10 префиксов. Если код специально для данного клиента пишут последовательно 10 партнеров то должен использоваться 1 префикс, так как называя объекты не пересечешься - у последующего доработчика есть весь перечень объектов предыдущего. Еще некоторые используют префиксы как эрзацконтрольверсий для бедных, но это из-за явной бредовости опустим. Вот таковы мои мысли. |
|
06.10.2010, 13:41 | #3 |
Участник
|
другими словами, префикс - название модуля, а не код разработчика?
Цитата:
Стоит ли рефакторить приложение избавляясь от кодов разработчиков/компаний? Плюсы и минусы такого рефакторинга? |
|
06.10.2010, 13:44 | #4 |
Ищущий знания...
|
мне кажется логично использовать префикс компании (клиента) в своих костомизациях.
например если работаем в компании Vasya Pupkin то например создавая таблицу, класс, форму и все остальное, что есть в АОТ, мы будем писать: VP_Table, VP_Class, VP_Form и т.п. Это нам поможет сразу идентифицировать то, что создано в самой компании локально (по идее слои для этого, но мало ли, внедренец тоже может накодить в слое USR и т.п.) в остальных случаях считаю, префиксы\суфиксы не нужны, а только мешают эстетическому восприятию элементов приложения
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
|
За это сообщение автора поблагодарили: Atani (1). |
06.10.2010, 13:48 | #5 |
Axapta
|
Я на всех наших проектах по мере сил борюсь с идеей использования префиксов-суффиксов. Иногда не получается, если проект уже до моего прихода стартовал и так уже делается. Если я на проекте с самого начала, то свою точку зрения я всегда отстаивал и префексы мы не использовали. Считаю саму идею префиксов-суффиксов ужасно неудобной и мешающей в работе. Чтобы найти нужный объект, приходится делать несколько итераций поиска по АОТу (в случае префиксов). Плюс сам код выглядит более громоздким и неудобным. От одинаковых префиксов даже в глазах рябит. Ладно еще, если только таблицы-классы-формы с префиксами называют. Но когда и табличные поля (например, таблица XXX_JournalTable с полями XXX_JournalId, XXX_JournalName, XXX_JournalDate...) - это уже вообще за гранью добра и зла.
Но если в системе уже так принято, то рефакторинг я уже никогда не делал. Обычно трудозатраты на это сложно объяснить руководству и заказчику. Да и самому понятно, что скорее всего оно того не стоит. P.S. Суффиксы на практике вообще не встречал, если честно. Если и используют, то префиксы. |
|
|
За это сообщение автора поблагодарили: mazzy (2), ta_and (4), Ivanhoe (2). |
06.10.2010, 13:48 | #6 |
Ищущий знания...
|
если клиент готов оплатить рефакторинг кода (или вы готовы его сделать бесплатно ), то лучше его сделать. потому что действительно поддерживать такой код как вы привели выше, проблематично и тяжело.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
06.10.2010, 13:51 | #7 |
Administrator
|
Цитата:
Цитата:
Цитата:
Сам использую сейчас суффиксы. Считаю, что нужно использовать либо ничего - либо суффиксы, т.к. в этом случае: а) в АОТе объекты, относящиеся к одному модулю стоят рядом. И их логично находить. б) это дисциплинирует разработчика при придумывании названия объекту - чтобы объект расположился именно среди "своих" соседей по модулю. Если честно - то суффиксы немного мешают. Т.к. если хочется отделить штатный функционал от модификаций - то для этого есть слои и сравнение слоев. Все равно - если взять штатный метод и его полностью закомментарить - то суффикса/префикса не добавить, в то время как логика может быть изменена кардинально. Еще один камень в огород префиксов. Допустим есть у меня объект XXX_InventJournalTable и объект YYY_InventJournalTable. При создании второго объекта - сразу можно не догадаться, что первый уже есть. А чем больше кода в системе - тем сложнее в нем разбираться. А были бы суффиксы - глядишь и второй объект и не был бы создан. Цитата:
Цитата:
Хотя...один раз пригодились. Для того, чтобы лишний раз сказать клиенту - что вам впарили код с такого-то клиента
__________________
Возможно сделать все. Вопрос времени |
|
06.10.2010, 13:55 | #8 |
Administrator
|
Вдогонку. Хорошо именовать объект по тем же принципам, которые уже есть в системе.
Т.е. сначала идет префикс модуля, затем некоторое обозначение (корень слова) и окончание. InventJournalTable LedgerJournalTable InventJournalTrans CustTable Видно - что есть "журнальные" таблицы, есть "транзакционные" и видно что к какому модулю относится. Думаю, что суффиксы пошли от локализации - когда нужно было отличать объекты, относящиеся к разным странам
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
06.10.2010, 13:56 | #9 |
Axapta
|
Что мешает делать префикс у кода проекта? Определить, в рамках какого проекта создавался объект проблем не составляет никаких. Обычно же нет необходимости определять это "сразу", просто при взгляде на АОТ.
|
|
06.10.2010, 14:01 | #10 |
Ищущий знания...
|
Цитата:
2. когда нажимаешь из формы Пр. кноп. мыши\Настройка, сразу видно кто создал и к кому вопросы Это на вскидку, если посидеть подумать думаю ещё много вариантов найдется, когда надо посмотреть объект, не входя в проект.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
06.10.2010, 14:03 | #11 |
Участник
|
Я против префиксов / суффиксов. В комментах можно писать все что угодно, а вот АОТ портить... Наименование объектов и методов должно быть стандартным.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: blokva (2). |
06.10.2010, 14:04 | #12 |
Administrator
|
Ну это не повод... Код всегда можно закомментарить с указанием того, кто ваял.
А еще можно по слоям разграничиваться. Каждый ответственен за свой слой.
__________________
Возможно сделать все. Вопрос времени |
|
06.10.2010, 14:07 | #13 |
Axapta
|
По коду всегда должно быть сразу понятно, кто, когда и зачем его писал. У вас код не помечается меткой, в которой указан разработчик, дата, код проекта и желательно название модификации?
Цитата:
Нужно закомментарить. |
|
06.10.2010, 14:11 | #14 |
Участник
|
Префиксы\суффиксы использовать нужно, хотя бы для нормального перехода на новые версии\хот фиксы. Потому что, если при наименовании объекта программист будет размышлять так же, как поставщик MS DAX, то при переходе возникнет коллизия, особенно, если типы данных не совпадут по одинаково именованным объектам.
Между префиксом и суффиксом я бы выбрал суффиксы (_RU,_L, _W)- тогда объекты в АОТ сгруппируются по модулям\функциональности, да и при кодировании поиск в два раза меньше. Выше об этом писалось. Но на большинстве проектов заведено писать префиксы. Если заведено, то желательно продолжить в том же стиле - это уже этика. Когда корректируется код нижестоящих слоев, то правильнее делать в русле алгоритма того, кто начал уже что-то как-то писать. Иначе - переписывать. Переписывать - вопрос времени и денег. Для внутренних плюсов при разработке - можно привыкнуть, но если клиент платит, то почему бы "за его счет не создать себе комфортные условия". |
|
|
За это сообщение автора поблагодарили: sukhanchik (2). |
06.10.2010, 14:23 | #15 |
северный Будда
|
Я считаю, что для почти всех кастомных объектов (кроме проектов) нужен единый для компании префикс. Т.е. новаю таблицу надо называть не блаблаTable, а Х_блаблаTable. Это сразу покажет, какие именно объекты нестандартные + обезопасит от возможных перекрытий имён при переходе на новые версии продукта. Название проекта должно начинаться с префикса-идентификатора разработчика.
Суффиксы нужны только в классах-потомках и нигде более.
__________________
С уважением, Вячеслав |
|
06.10.2010, 14:27 | #16 |
Administrator
|
Цитата:
Сообщение от titov
Префиксы\суффиксы использовать нужно, хотя бы для нормального перехода на новые версии\хот фиксы. Потому что, если при наименовании объекта программист будет размышлять так же, как поставщик MS DAX, то при переходе возникнет коллизия, особенно, если типы данных не совпадут по одинаково именованным объектам.
Пример. Если классы Bank_XX, где XX - код страны, для которой осуществляется проверка банковского счета (у каждой страны своя проверка). Так вот. Класса Bank_RU (4.0 SP2) нет в природе. А нужен. И создавать такой класс с префиксом/суффиксом иным - просто некорректно по отношению к том, кто будет разбираться в коде. А МС однозначно обзовет такой класс именно так - если вдруг решит его выпустить. Вывод - свой код и код от МС тут хорошо "скрестить" и этто повод делать делать не потом "генеральную уборку", а сразу не мусорить за собой.
__________________
Возможно сделать все. Вопрос времени |
|
06.10.2010, 14:27 | #17 |
Участник
|
По поводу вопросов: а надо ли? будет ли остальное? как относится клиент?
Цитата:
Сообщение от sukhanchik
Нет. Точнее только ради переименования - нет. Если есть другие причины - то по мере правки - плавно переходить. Грубо говоря - сильно задел объект - изволь его переименовать и обновить ссылки на него (обновление ссылок или косметическое трогание объекта не должно вести к переименованию - тут конечно все очень субъективно- на усмотрение проверяющего код). Но опять-таки - вопрос. Ради чего? Оценит ли это клиент? А не дешевле будет обновить версию с осмысленным переносом (с переименованием) модификаций ? Глядишь - часть кода отпадет. Но опять-таки - эту черную работу никто может не оценить. Клиент также может сменить внедренца/обслуживающую его компанию. И новая компания может опять все замусорить. Хотя сначала будет сливки снимать от того, что все подчищено.
Там версия древняя, сейчас выполняется переход на ax2009. инвентаризация и чистка кода - производится. Клиент отлично понимает что это такое и чем ему грозит (есть масса внешних систем и всяких отчетностей, которые используют данные аксапты). Именно из-за вопросов совместимости и минимизации префиксы пока не трогались. Но рано или поздно по ним нужно принять решение. Двойное-тройное сканирование объектов АОТ тормозит как нас, так и программистов/администраторов самого клиента. Надеюсь, что убирание префиксов повысит скорость дальнейшей работы. Хотелось бы сосредоточиться на конкретно префиксах/суффиксах. плюсы/минусы? стоит ли избавляться? (если все остальные вопросы решены) |
|
06.10.2010, 14:28 | #18 |
Administrator
|
После того как таких объектов переваливает за 5 штук - это становится неудобным (см мой пост про XXX_InventJournalTable и YYY_InventJournalTable) и ненужным (уже смотрится на модуль)
__________________
Возможно сделать все. Вопрос времени |
|
06.10.2010, 14:30 | #19 |
Administrator
|
Цена уборки может не оправдать ожидания. Либо цена будет большая, либо ожидания могут оказаться меньшими.
__________________
Возможно сделать все. Вопрос времени |
|
06.10.2010, 14:31 | #20 |
Участник
|
Цитата:
а почему не суффикс? |
|