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

[Ace of Database]

А я за префиксы.
Зная повадки, рефлексы, образ мышления, восприятие окружающего мира конкретных людей или групп людей, которые разрабатывали модификации с префиксами, мне легче понять, как работает тот или иной кусок кода, написанной этими людьми, или зачем эти люди создали ту или иную таблицу.
Например, мне встречались приложения, в которых присутствовали модификации двух и даже более консалтинговых компаний.
У некоторых консалтинговых компаний есть определенные наработки, и видя префикс класса, я уже знаю, что есть некий другой класс с таким же префиксом, с помощью которого, например, можно осуществить интеграцию с другой базой, вывести отчет в эксель, или осуществить другие операции, которые уже были разработаны данной консалтинговой компанией.
Короче, если мне надо вывести отчет в Эксель, то я смотрю, какие префиксы преобладают в приложении, и если я их узнаю, то я ищу знакомый мне класс для вывода в Эксель.
Мне знакомы классы и объекты 4 консалтинговых компаний, и еще нескольких индивидуальных разработчиков

[Владимир Максимов]

Цитата:

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

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

"И это правильно!" (с)

Насколько я понимаю, закачка "чужих" решений выполняется через проекты. Проект - это нечто, лежащее вне AOT. Как следствие, здесь фантазия разработчиков в именовании собственно проекта ничем не ограничена. Префиксы, суффиксы, порядковые номера и т.д. и т.п. Да все, что угодно!

Имя проекта никак, никоим образом, не нарушает "стандарт" именования объектов Axapta. Это уже сами разрабатываете свои внутренние стандарты именования проектов. С Best Practices это уже не пересекается. Более того, никто не мешает в любой момент переименовать проект, если имя показалось не удачным.

В этом случае, если надо найти объект полученный от стороннего разработчика, открываем проект, через который все модификации и были импортированы. Все сразу и видим.

Но если задача обратная. Не известно (не помню!), кто именно создал (модифицировал) тот или иной объект, но известно к какому модулю он относится. То здесь поиск идет именно по AOT (по горячим клавишам в алфавитном порядке) и префиксы явно мешают.

Цитата:

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

Все лежит в голове.
Для поиска таблиц и других объектов использую специальную форму.

Это и есть две основные проблемы, которые появляются, если есть префиксы у объектов AOT и поиск идет именно по ним.

1. Новый сотрудник не может залезть к тебе в голову. Ему придется кроме Best Practices изучать еще несколько стандартов именований объектов от сторонних разработчиков. Хуже того, в случае дополнительных модификаций, всем этим стандартам придется следовать!

2. Стандартные механизмы поиска объектов по горячим клавишам - перестают работать. Приходится мастерить собственные "поделки". Т.е. сами себе создаем трудности, а потом начинаем их героически преодолевать.

[LeonDerCom]

Link
Вот именно, что приходится разбираться и запоминать, кто и где когда менял и отвлекать людей, если вдруг чего забыл, а иначе тратим время на поиск. Мало того, до определенного времени были стандартная конфигурация, одни начали модифицировать таблицы и классы - не меняя их имя, а вставляя коментарии в те места кода. Потом пришел другой и говорит - вот Бест Практис от МС говорит, что нужны префиксы - придумал свой и давай. Третий говорит, что он тоже умный и так как его модули идут в другую область - тоже придумал свой префикс и т.д. После приходит человек и видит все это... Полный бардак и каждый раз начинать алфавитный поиск с перебора префиксов, когда знаешь название объекта - лично у меня радости не вызывает. В то время как суффиксы позволяют найти название таблицы и все ее модификации, отличающиеся суффиксами - будут находится рядом в алфавитном порядке. Удобно и легко. Никаких костылей там не нужно.

[kashperuk]

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

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

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

[user_ax]

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

[trud]

Цитата:

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

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

Ну неиспользование префиксов при разработке решений может потенциально приподнести большие проблемы. предположим вы купили 2 ISV решения в которых есть таблица PostingParameters или что-то подобное. при этом установка по сути превратится в большую проблему

т.е. как раз делая что-то, что планируется использовать где-то еще, а не на одном проекте префиксы must use
ну и модели конечно

[mazzy]

Цитата:

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

Ну неиспользование префиксов при разработке решений может потенциально приподнести большие проблемы. предположим вы купили 2 ISV решения в которых есть таблица PostingParameters или что-то подобное. при этом установка по сути превратится в большую проблему

почему именно префиксы, а не суффиксы?

[Ivanhoe]

Работаем с одним западным партнером, который все делает с префиксами + внедряем Process Industries (там местами тоже префиксы). Ужасно неудобно!

[LeonDerCom]

Цитата:

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

Ну неиспользование префиксов при разработке решений может потенциально приподнести большие проблемы. предположим вы купили 2 ISV решения в которых есть таблица PostingParameters или что-то подобное. при этом установка по сути превратится в большую проблему

т.е. как раз делая что-то, что планируется использовать где-то еще, а не на одном проекте префиксы must use
ну и модели конечно

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

[Vadik]

Цитата:

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

Работаем с одним западным партнером, который все делает с префиксами + внедряем Process Industries (там местами тоже префиксы). Ужасно неудобно!

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

Цитата:

В своих решениях КОРУС не использует искусственные префиксы и суффиксы, работаем в стандартной нотации - префиксы используются только для областей

Ну, я бы не стал на самом деле это выпячивать. Если Я Ваш клиент и использую только Ваши решения - мне как правило фиолетово, каких naming conventions вы там придерживаетесь. Допустим, я в нагрузку к Вашему замечательному решению прикупил еще одно и БАЦ - надцать объектов \ методов \ полей пересеклись по именам.. Оба решения несколько лет на рынке, клиентская база есть, никто для меня ничего переименовывать не будет ("у нас все работает") - куда бежать жаловаться ? Поймите же, это уже не вопрос Вашего эстетического восприятия - это забота о клиенте прежде всего

Цитата:

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

почему именно префиксы, а не суффиксы?

С префиксами поля \ методы от каждого аддона сгруппированы (рядышком лежат) при алфавитной сортировке в AOT (очень удобно в AX 2012), сразу понятно что где искать ("был какой-то метод из аддона А на SalesFormLetter, название не помню но сразу определю если начну набирать в Intellisence XXX_construct")

[Ivanhoe]

Цитата:

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

Ну, я бы не стал на самом деле это выпячивать. Если Я Ваш клиент и использую только Ваши решения - мне как правило фиолетово, каких naming conventions вы там придерживаетесь. Допустим, я в нагрузку к Вашему замечательному решению прикупил еще одно и БАЦ - надцать объектов \ методов \ полей пересеклись по именам.. Оба решения несколько лет на рынке, клиентская база есть, никто для меня ничего переименовывать не будет ("у нас все работает") - куда бежать жаловаться ? Поймите же, это уже не вопрос Вашего эстетического восприятия - это забота о клиенте прежде всего

Забота о клиенте - не врать ему . Не обещать, что Ваше решение заработает "из коробки". Не врать, что он "легко" сможет обновиться на новую версию и т.п. Проговаривать с клиентом каждую модификацию и последствия (даже если "просто добавить галочку на форму"). Можем в отдельной ветке обсудить - welcome!

Цитата:

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

С префиксами поля \ методы от каждого аддона сгруппированы (рядышком лежат) при алфавитной сортировке в AOT (очень удобно в AX 2012), сразу понятно что где искать ("был какой-то метод из аддона А на SalesFormLetter, название не помню но сразу определю если начну набирать в Intellisence XXX_construct")

Откройте проект, раз вы знаете аддон, - там и смотрите Заодно все связанные объекты в одном месте увидите (в т.ч. измененные стандартные, у которых суффикс никто в здравом уме не изменяет).

[Vadik]

Цитата:

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

Можем в отдельной ветке обсудить - welcome!

Ну зачем же в отдельной-то.. Давайте уж тут мою проблему ("не используем суффиксы-префиксы.. купили два аддона") и пообсуждаем

Цитата:

Забота о клиенте - не врать ему . Не обещать, что Ваше решение заработает "из коробки"

Прекрасные слова (с). А кто-то изначально проектирует так, чтобы с максимальной вероятностью заработало (понятно что слияние X++ кода есть неизбежное зло в случае нескольких аддонов в одном приложении но и его при желании умудряются в большинстве случаев обойти с помощью event handler-ов)

Цитата:

Проговаривать с клиентом каждую модификацию и последствия (даже если "просто добавить галочку на форму")

А тут мы похоже каждый о своем. Я - о тиражируемом "коробочном решении" (аддон), Вы - о штучной кастомизации под конкретного клиента (модификация). Так мы пожалуй ни о чем не договоримся

[mazzy]

Цитата:

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

С префиксами поля \ методы от каждого аддона сгруппированы (рядышком лежат) при алфавитной сортировке в AOT (очень удобно в AX 2012), сразу понятно что где искать

А с суффиксами в АОТ сгруппированы по модулям. Очень удобно.

Объекты аддонов все равно удобнее в проекты отфильтровывать.

[trud]

Цитата:

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

А с суффиксами в АОТ сгруппированы по модулям. Очень удобно.
Объекты аддонов все равно удобнее в проекты отфильтровывать.

фильтрация в проекты будет работать при любом подходе

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

не самая конечно нужная функция, но зачем выбирать решение которое априори вас в чем-то ограничивает

[Vadik]

Цитата:

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

А с суффиксами в АОТ сгруппированы по модулям. Очень удобно

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

Цитата:

Объекты аддонов все равно удобнее в проекты отфильтровывать

Проекты из модели в AX 2012 создавать одинаково удобно что с префиксами-суффиксами что без них (см. Tools \ Model management \ Create project from model). А дальше что? Мне проект как таковой не нужен (во первых он вендором уже создан, во вторых - там одних форм, таблиц и классов полтыщи). Мне нужен интуитивный и быстрый способ просмотреть \ добраться до модификаций принадлежащих к определенному аддону, мне субъективно делать это с префиксами удобнее.

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

[Владимир Максимов]

Цитата:

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

Мне нужен интуитивный и быстрый способ просмотреть \ добраться до модификаций принадлежащих к определенному аддону, мне субъективно делать это с префиксами удобнее.

Здесь сделано допущение: Заранее известно, о каком именно аддоне (каком префиксе) идет речь.

А сама тема была создана исходя из допущения, что заранее НЕ известно, о каком именно аддоне идет речь, но известно о каком именно модуле Axapta. И как в этом случае искать нужный объект?

Стандартный сценарий поиска по Best Practices (по имени модуля) в этом случае не годится. Приходится "изобретать велосипед" и создавать собственный функционал поиска.

И, кстати, а когда знание того, к какому именно аддону относится тот или иной объект имеет существенное значение для выполнения модификации? Ведь Вы исходите из предположения, что СНАЧАЛА надо определится с именем аддона, а ПОТОМ с функциональностью (модулем Axapta). Вот мне и интересно когда, в каких случаях, это имеет принципиальное (первостепенное) значение?

Разве при сопровождении приложения так уж важно каким образом объект попал в АОТ? Разве не важнее знать какую функцию этот объект выполняет (к какому модулю относится)?

[Vadik]

Цитата:

Сообщение от Владимир Максимов

Здесь сделано допущение: Заранее известно, о каком именно аддоне (каком префиксе) идет речь.

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

Цитата:

И, кстати, а когда знание того, к какому именно аддону относится тот или иной объект имеет существенное значение для выполнения модификации?

Если модифицируется функциональность определенного аддона, с большой долей вероятности можно сказать что пользоваться будем его же полями\методами\классами. Нет здесь принципиальной разницы, есть текущий контекст (аддон \ модуль) и соглашения по именованию которые позволяют быстро отфильтровать то что в данном контексте несущественно

Цитата:

Разве при сопровождении приложения так уж важно каким образом объект попал в АОТ? Разве не важнее знать какую функцию этот объект выполняет (к какому модулю относится)?

Если вендор позаботился о том чтобы установка \ обновление его решения импортом модели у меня (клиента) были рутиной а не русской рулеткой - мне пофиг

[fed]

А скажите - вы вот когда про префиксы говорите - вы совсем-совсем исключений не делаете?
Просто мне имена методов типа axInventTable.XYZparmNewField() очень режут глаз. Я уж скорее напишу что-то типа axInventTable.parmXYZNewField() чем префикс перед методом поставлю.

[mazzy]

Цитата:

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

Я такой человек - мне чтобы понять надо увидеть. Покажи что и как у тебя сгруппировано.

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

Но я привел пример с суффиксами.

1. обрати внимание, что объекты группируются по имени модуля. В списке есть и мои объекты (не выведены на скриншот из-за NDA)
2. можно фильтровать и по суффиксам. Я написал и вывел тестовый job в группу.
3. Обрати внимание на фильтры. Все просто

Цитата:

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

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

Не. Это не вкус.
Обрати внимание, что у тебя объекты находятся в разных местах.

Если речь идет о конечном клиенте, то у него будут таблицы в разных местах списка "DDD_Codes.KKK_XXX_LL_OKVED. (где ККК, ХХХ, LL - префиксы)"
Помнить все эти префиксы - очень сложно, если ты работаешь на клиенте, а не у партнера, где есть только свое решение.

Впрочем, я об этом уже писал в первом сообщении этой ветки

[Ace of Database]

Методы, названия которых начинающиеся с "parm" - особый случай. Я всегда ищу в незнакомом классе методы parm, чтобы передать в него параметры. А если нужного параметра нет, то я добавляю новый метод, и называю его parmXYZNewField().
То есть получается 2 префикса: первый "parm", второй "XYZ"
Если я не добавлю второй префикс "XYZ", то потом забуду, что это именно я добавил этот метод. Бывает, приходится через полгода возвращаться к забытым доработкам, а префиксы помогают быстро разобраться.
Правда у меня префикс всего из одной буквы "z", так что мне легче. Мои методы выглядят как parmzNewField().
У кого длинные префиксы, тем сложнее.
Все зависит от порядка, установленного на каждом конкретном проекте. Практически везде правила разные - у кого-то суффиксы, у кого-то префиксы. Из-за того, что ведущие разработчики разные на разных проектах. В итоге по почерку можно узнать, с какого проекта пришел тот или иной кусок кода.