Префиксы-суффиксы. Как лучше? Стоит ли избавляться от них?

[oip]

Цитата:

Сообщение от pitersky

Это сразу покажет, какие именно объекты нестандартные

Слои.

Цитата:

Сообщение от pitersky

обезопасит от возможных перекрытий имён при переходе на новые версии продукта.

Есть хоть один реальный пример пересечения? Много такого? Как по мне, так риски и трудозатраты на исправление, если даже ситуация возникнет, минимальны. И как правильно заметили выше, "Если логика программиста вдруг совпала с логикой от МС - то это повод задуматься об удалении /изменении собственного кода"!

Цитата:

Сообщение от pitersky

Название проекта должно начинаться с префикса-идентификатора разработчика.

Зачем? Разработчик должен быть указан в коде. Проект тоже удобно искать используя стандартный Naming Convention с названием модуля в его начале и так далее. А в вашем случае придется несколько раз сканировать. И все ради чего?

Кстати, ужасно раздражает, когда в название проекта в виде префикса зашивается не только код заказчика (это как раз правильно), но и внутренний номер модификации.

[lev]

Цитата:

Сообщение от oip

По коду всегда должно быть сразу понятно, кто, когда и зачем его писал. У вас код не помечается меткой, в которой указан разработчик, дата, код проекта и желательно название модификации?

помечается.

но бывают вариант когда по каким то причинам метки такой нет. (разработчик забыл, забил или ещё что то)

ещё раз хочу обратить внимание, я против суфиксов и префиксов. просто предположил, что единственный случай когда, на мой взгляд, можно как то попробовать объяснить их присутствие это обозначение компании (клиента).

[fed]

Гм. Я тоже пожалуй выскажусь.
Во первых - я, в целом, негативно отношусь и к префиксам и к суффиксам. Читаемость кода они, однозначно, снижают, а легкость апгрейда повышают весьма незначительно.Кроме того, в большинестве случаев, никакого апгрейда в наших условиях не бывает, а бывает перевнедрение. Нет, есть конечно исключение, но если на проекте было так много доработок что стали префиксы/суффиксы использовать - значит там над аксапточкой надругались настолько сильно и противоестественно, что никакого апгрейда там точно не случиться.

Использование кодов имени программиста, партнера или кода проекта в качестве префикса/суффикса - однозначный тупик. Классический пример попытки решения организационной проблемы (плохого разграничения ответственности между разработчиками или партнерами) с помощью программных механизмов. Причем попытки заведомо неудачной. Если в качестве префикса/суффикса используется код клиента (типа у партнера три клиента и для каждого свой префикс), то это вообще верх демонстрации неуважения к клиенту. Какое мне дело, что у моего партнера еще 4 проекта и его программеры запутались в собственных доработках?
Я считаю допустимым (и наверное иногда даже полезным) использование префикса модуля, но только в том случае если модуль большой, достаточно отдельно стоящий (а не состоящий из кучи дополнений к штатным таблицам и формам) и более или менее переносимый...

Удалять префиксы из существующего приложения как отдельную задачу - я бы не стал. Если вы там какой-то кусок в порядок приводите - то удалите. Если переносите более или менее в лоб - пусть остаются, эти префиксы противные, но не страшные...

[MikeR]

На самом деле мы уже говорим, когда в системе все хорошо, в первую очередь архитектура приложения и бизнес процессы, тогда можно браться за префиксы. Просто был на проекте, где некий архитектор вычесывал блох типа, что надо писать в validateWrite, а не во Write и так далее. А в архитектуре была просто разруха. Весь модуль состоял из четырех-пяти таблиц с одинаковым набором полей и при записи в одну таблицу шла длинная очередь записи в другие. Не учитывались возможные блокировки, транзакции, наследование и так далее.
Использование префиксов говорит о том, что разработчик со стажем и более ничего. При нынешних технологиях можно, конечно, обойтись и без этого. Но на мой взгляд - это не главное с чем стоит боротся.

[Zabr]

Цитата:

Сообщение от sukhanchik

чтобы лишний раз сказать клиенту - что вам впарили код с такого-то клиента

Работаю на клиенте. Компания-внедренец в своих объектах (которых немало, т.к. это тиражируемое отраслевое решение) ни префиксы, ни суффиксы не использует. Однако дисциплинированность в комментариях их программмистов легко позволяет обнаружить в нашем приложении коды для нескольких других предыдущих клиетов. (Да и я свои принес, чего уж там).

Лично я - сначала предпочитал использовать префиксы, причем только в именах объектов (но ни в коем случае не в полях таблиц). Потом мнение изменил. Сейчас префикс (идентифицирующий компанию) использую, но только в именах классов специально написанных тут на клиенте отчетов, и более нигде. Так показалось удобнее с ними работать, так как таких отчетов уже под сотню (!), дорабатывать приходится часто (или писать новые на основе предыдущих), и так легче их искать, так как они в классах АОТ лежат рядышком, с одним префиксом.

Рефакторинг - в общем случае я бы не стал делать, не стоит того. В частном случае - делал, когда перенёс ряд доработк (в основном отчеты) с предыдущего проекта (почившего вместе с компанией-заказчиком, так что совесть чиста), имевшие префикс заказчика. Естественно, переделывал на другой префикс (попутно рефакторил код под реалии нового заказчика).

[EVGL]

На мой взгляд, префиксы с кодом клиента очень даже полезны. Как раз в случае "тиражируемых решений" часто есть соблазн продать модификацию сразу 2 клиентам, хотя в договоре прописано, что код остается в собственности первого клиента. Если в этой модификации теперь поменяем XX_ на YY_, то чисто формально код окажется разным, и придраться будет труднее.

[oip]

EVGL, то есть префикс делать для того, чтобы потом можно было в будущем попытать с чистой совестью обмануть клиента? Кстати, сильно сомневаюсь, что в случае каких-то судебных разбирательств измененние префексов будет признано достаточным условием для того, чтобы код не считался собственностью клиента, если такое условие в договоре прописано. С таким же успехом можно просто в коде делать метки с названием клиента, а потом для следующего клиента производить их автозамену на новые.

[pitersky]

Цитата:

Сообщение от sukhanchik

После того как таких объектов переваливает за 5 штук - это становится неудобным (см мой пост про XXX_InventJournalTable и YYY_InventJournalTable) и ненужным (уже смотрится на модуль)

Я не о том писал. Я имел в виду, что если нужно добавить новую таблицу, то лучше называть её не SourceTable, а X_SourceTable. При этом никаких Y_SourceTable быть не должно - название после суффикса уникально. Ну и, разумеется, штатной таблицы SourceTable в системе тоже нет.

Цитата:

Сообщение от mazzy

компании клиента или компании разработчика?
а почему не суффикс?

клиента, конечно. Т.е., если развивается приложение ООО "Рога и Копыта", то объекты надо называть РиК_Объект.
почему не суффикс? не знаю, суффиксы обычно как раз занимают локализаторы (_RU). Это ж моё ИМХО всё-таки

Цитата:

Сообщение от oip

Есть хоть один реальный пример пересечения? Много такого? Как по мне, так риски и трудозатраты на исправление, если даже ситуация возникнет, минимальны.

Когда я завожу в системе новую таблицу, я не с потолка беру её название - оно всё-таки как-то должно описывать хранимые в таблице данные. При этом одни и те же данные можно обозвать по-разному, да и одно название на английском может описывать разные сущности (invoice тот же, например). Если мой предшественник в базе клиента создаст таблицу RequestTable (которая будет задействована во МНОГИХ местах), а потом одноимённая таблица появится в Ax6 в сводном - будет совсем не хорошо.

[fed]

Цитата:

Сообщение от EVGL

На мой взгляд, префиксы с кодом клиента очень даже полезны. Как раз в случае "тиражируемых решений" часто есть соблазн продать модификацию сразу 2 клиентам, хотя в договоре прописано, что код остается в собственности первого клиента. Если в этой модификации теперь поменяем XX_ на YY_, то чисто формально код окажется разным, и придраться будет труднее.

Почему-то сразу вспомнился Коламбус 1999-2001 годов

[Андре]

Цитата:

По-моему - префиксы/суффиксы совершенно бесполезная штука. Где я ошибаюсь?

Использую префиксы для обособленно созданных модулей, типа Reports...... Не очень удобно, но так как отсутствует понятие пакетов (неймспейсов или как там их еще) приходится пользоваться этим.

Для других разработчиков удобно - так как они сразу видят, что это мое и со всеми вопросами надо подходить ко мне. Мне удобно финальный проект собирать.

Из минусов - увеличивается количество символов при декларации переменных в коде.

Естественно префикс использую только для именования элементов АОТ. В наименовании полей, методов и прочих элементов n-го уровня вложенности префиксы не использую.

[Андре]

Цитата:

Стоит ли рефакторить приложение избавляясь от кодов разработчиков/компаний?

Меня, кстати, в этом случае больше интересует моральный и этический аспекты. То есть, я правильно понял, что мы просто берем чужой модуль и стираем в нем префиксы, который по сути является единственным признаком авторского права разработчика?

[Андре]

Цитата:

мне кажется логично использовать префикс компании (клиента) в своих костомизациях

Мне этот подход не очень нравится, ибо система контроля версий рулит, но этого часто требует заказчик. Префикс, как идентификатор разработчика, теряет свой смысл как только с объектом поработало несколько разработчиков (компаний).

[Андре]

Цитата:

Что мешает делать префикс у кода проекта?

Количество Shared проектов сильно ограничено и нам приходится периодически их удалять.

[titov]

Цитата:

Сообщение от sukhanchik

Если логика программиста вдруг совпала с логикой от МС - то это повод задуматься об удалении /изменении собственного кода.
Вывод - свой код и код от МС тут хорошо "скрестить" и этто повод делать делать не потом "генеральную уборку", а сразу не мусорить за собой.

По классам спорный вопрос, что лучше - мусор в виде объектов+суффикс или объекты в проекте расхождений с ошибками? оба варианта имеют и плюсы и минусы...
Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму - по функциям коду и принимать решение о слиянии (удалении своих). Здесь еще плюс есть - приложение уже работоспособно сразу после перехода (ну почти сразу). А без преффиксов\суффиксов - в двух местах - есть два варианта развития событий. И приложение с ошибками!

еще момент - а если код партнера\клиента лучше MS DAX ? пройтись по своим классам и переименовать + код по ссылкам - то есть обратные действия?

А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало?
Вот именно - нужны дополнительные действия.

В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало!

Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться.

еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний.

и еще - практикуется продажа решений айти компаниями - суффиксы объектов в таких проектах хро очень даже кстати. И не всегда сразу ясно, что будет решение при начальном создании объектов.

[_scorp_]

Вопрос уже не раз поднимается. Всегда пишут, что раньше по BP нужно было использовать префиксы, а теперь суффиксы. Но где в данный момент находятся актуальные рекомендации? Тут вообще нет ни слова не про одно не про другое.

Цитата:

General Rules
All names must be in U.S. English.

The default rule is to use logical and descriptive names if no other specialized rules apply.

Identifier names have a limit of 40 characters.

Names in the Application Object Tree (AOT) and in X++ code must correspond to the names in the U.S. English user interface.

Names must be spelled correctly.

Names must be used consistently.

Each path in the AOT must be unique; nodes must not have identical names.

All texts that appear in the user interface must be defined by using a label. (This rule applies only if you want your solution certified as an international solution.)

Do not begin a name with "aaa", or "CopyOf". Do not begin a name with "DEL_" unless it is a table, extended data type or enum, and it is needed for data upgrade purposes. Names that use these prefixes cause a best practices error when you check the objects into the version control system.

Цитата:

Where possible, application object names should be constructed hierarchically from three basic components:

{business area name} + {business area description} + {action performed (for classes) or type of contents (for tables)}

Может это означает, что по BP их(префиксы/суффиксы) уже не нужно использовать?

[wb]

Цитата:

Сообщение от mazzy

Но рано или поздно по ним нужно принять решение.
Двойное-тройное сканирование объектов АОТ тормозит как нас, так и программистов/администраторов самого клиента.
Надеюсь, что убирание префиксов повысит скорость дальнейшей работы.
)

мой опыт такой уборки показал, что скорость повысилась, но очень не значительно, поскольку знание, чем каждый объект занимается необходимо. Большой плюс остался только эстетическое наслаждение

Цитата:

Сообщение от mazzy

Хотелось бы сосредоточиться на конкретно префиксах/суффиксах.
плюсы/минусы? стоит ли избавляться? (если все остальные вопросы решены)

Префикс удобен в названиях проектов (содержит код из реестра модификаций) и отчетах (удобно искать, похожие отчеты, но из разных модулей, разные сотрудники заказывали), в остальном считаю крайне вредным.

Суффикс удобен, чтобы 1) ловить объекты без комментария 2) в стеке сразу видно, где пошли другим путем.

Если аксу подвергли такой кастомизации, что сервис пак стандартно не ставится. Программисты клиента, выбрали из сервис пака новую функциональность и перенесли. Все топчутся в одном слое - тогда о суффиксе можно вспомнить с благодарностью

Ихмо, лучше использовать только один суффикс/префикс, только чтобы отличать доработки для клиента от системы

[titov]

Цитата:

Сообщение от _scorp_

Each path in the AOT must be unique; nodes must not have identical names.

в цитате из ВР требование к уникальности. Уникальность по оси АОТ, или еще и по оси времени, то есть и на будущее, там где новые версии?
Вопрос каверзный.
Либо автор ВР действительно исключил префиксы\суффиксы, рекомендуя в будущем совмещать совпадающие объекты, либо пропустил момент уникальности на завтра, либо отдал нам на откуп. Узнать бы... А пока спорим

[mazzy]

Цитата:

Сообщение от Андре

То есть, я правильно понял, что мы просто берем чужой модуль и стираем в нем префиксы, который по сути является единственным признаком авторского права разработчика?

Если бы модуль, то я бы даже не спрашивал, а оставил.
нет, не модули. а ошметки, группы таблиц и группы полей, оставшиеся от разных разработчиков.

после перехода на ax2009 префиксы потеряли всякий смысл, поскольку все совсем другое.

соображение насчет авторских прав - понял. спасибо.
подумаем и посоветуемся.

[mazzy]

Цитата:

Сообщение от Андре

Меня, кстати, в этом случае больше интересует моральный и этический аспекты.

И еще одно. автор остается в свойствах объекта (кто и когда создал, когда и когда последний модифицировал).

у полей, методов таких свойств нет
зато есть у таблиц, классов.

я еще согласен про группу таблиц, классов и отчетов...
надеюсь вы согласны, что поле с префиксом не тянет на премет авторского права.
как и индекс, как и тип...

в общем, не думаю, что это решающий аргумент
хотя подумать над этим надо.

[sukhanchik]

Цитата:

Сообщение от EVGL

На мой взгляд, префиксы с кодом клиента очень даже полезны.

Полезны для кого? Для внедренца? Дык не им же потом (возможно) придется разгребать чужой код. Польза д.б. в первую очередь для конечного клиента. Как следствие - если конечный клиент обратится к внедренцам - им проще будет.

Цитата:

Сообщение от fed

Почему-то сразу вспомнился Коламбус 1999-2001 годов

Потому что о нем в первую очередь и речь. Очень сильно вспоминается приложение в котором половина объектов с PRK_, из оставшегося - половина - штатный функционал, а половина - XXX_ и YYY_. Понятно - что внедренец "слепил" код с разных проектов. Если не брать во внимание этические/правовые моменты - то просто мне как разработчику, которому нужно чего-то усовершенствовать в этом коде - просто замучаться разбираться как можно поаккуратнее "вклиниться".

Цитата:

Сообщение от pitersky

Я не о том писал. Я имел в виду, что если нужно добавить новую таблицу, то лучше называть её не SourceTable, а X_SourceTable. При этом никаких Y_SourceTable быть не должно - название после суффикса уникально. Ну и, разумеется, штатной таблицы SourceTable в системе тоже нет.

клиента, конечно. Т.е., если развивается приложение ООО "Рога и Копыта", то объекты надо называть РиК_Объект.
почему не суффикс? не знаю, суффиксы обычно как раз занимают локализаторы (_RU). Это ж моё ИМХО всё-таки

. Вот поэтому и нужно делать суффикс (если делать) - чтобы все было в одном месте и было наглядно видно и сразу пропадало желание делать Y_SourceTable

Цитата:

Сообщение от pitersky

Когда я завожу в системе новую таблицу, я не с потолка беру её название - оно всё-таки как-то должно описывать хранимые в таблице данные. При этом одни и те же данные можно обозвать по-разному, да и одно название на английском может описывать разные сущности (invoice тот же, например). Если мой предшественник в базе клиента создаст таблицу RequestTable (которая будет задействована во МНОГИХ местах), а потом одноимённая таблица появится в Ax6 в сводном - будет совсем не хорошо.

На самом деле не совсем все так. Просто так дубль не появится. Обязательно будет префикс модуля. А вот уж если в МС "забыли" поставить префикс модуля и программист у клиента тоже забыл - то это уже урок этому программисту - что надо думать.
Именно из-за наличия префикса модуля - табличка в сводном никогда не пересечется с табличкой в ГК к примеру. Поэтому - никогда не следует создавать табличку RequestTable. Она должна относиться к чему-то. Либо это LedgerRequestTable (А может быть даже и LedgerRequestJournalTable), либо это InventRequestTable, smmRequestTable, MyModuleRequestTable и т.д.

Цитата:

Сообщение от titov

По классам спорный вопрос, что лучше - мусор в виде объектов+суффикс или объекты в проекте расхождений с ошибками? оба варианта имеют и плюсы и минусы... Но главное - если приняты префиксы\суффиксы, то искать по одному алгоритму

"Безобразно но единообразно" - это точно.

Цитата:

Сообщение от titov

еще момент - а если код партнера\клиента лучше MS DAX ?

Хотя это и вполне так бывает - но я бы стал отталкиваться от штатного кода как от эталона. По причине его тиражируемости. Таблицу CustTable знают все. А таблицу XXX_MySuperTable - никто.

Цитата:

Сообщение от titov

А вот другой пример. Добавили новые таблицу или поле. Наименования совпали при переходе, но не типы для полей и обязательно! - разные ID. Что делаем, чтобы обновление базы заработало??
Вот именно - нужны дополнительные действия.?

Как уже писал fed - случаи апгрейда редки. Значит ими можно пренебречь. Вероятность такого события - очень мала. Да и оно некритично - сборка приложения делается не в авральном режиме за ночь. Т.е. берем перекрестные ссылки и проходимся у себя и выясняем - насколько отличается бизнес-логика, завязанная на это поле. После этого либо поле переименовываем - либо переделываем наши модификации на новые реалии (опять-таки - по проекту из перекрестных ссылок - это не такая проблема)

Цитата:

Сообщение от titov

В целом - если объекты "развязаны" по наименованию, то после перехода меньше ошибок, меньше дополнительных действий, но больше мусора. Процент мусора низкий, потому что "пророков" мало!

Важно - малый процент совпадающих полей\таблиц могут принести большую головную боль при обновлении. "Мусору" в таких случаях только радоваться.

Да, но есть такой инструмент как слои. Они очень хорошо показывают все расхождения. Без них конечно - было бы сложнее. Кстати - при желании - можно выгрузить все в хпо, а дальше сделать поиск и замену

Цитата:

Сообщение от titov

еще довод созрел для суффиксов, как раз для конкретного случая. Если у Заказчика несколько Исполнителей, то как различить, что делали они, если нет суффикса? А если разовая работа и не активирована журнализация изменений в АОТ, или этот журнал чист? Возникает проблема ответа на извечный вопрос "как же до вас то работало?" - а не работало вовсе! И создателем объекта числится администратор - ведь так чаще переносят код. Код на слое VAR у всех. Надо поднимать бэкапы приложения до.., а последний полгода назад был...и там нет этого объекта! Здесь же вариант одновременной работы двух исполнителей-ай-ти компаний.

2 вывода:
1. Если делать префикс/суффикс - то он должен обозначать внедренца, но никак не клиента.
2. Развести исполнителей по модулям и включить систему контроля версий. Не верится - что одновременно 2 исполнителя будут править один и тот же объект.
Если же рассматривать работу исполнителей во времени - то как раз получим ворох разнопомеченных объектов. Не спасет суффикс от неработоспособности функционала. Тут нужно как-то по-другому организовывать работу. Проектами может делить.