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

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

Лично мне все равно. Для меня не будет ни ускорений, ни замедлений. Вопрос исключительно привычки. Собственно, ведь "префикс" в виде названия модуля никого не смущает, хотя он также бесполезен, как и обсуждаемые здесь префиксы/суффиксы клиентов/разработчиков.

Расположены рядом в AOT ? Если я что-то модифицирую, то создаю отдельный проект под эту модификацию. А там все "рядом".

Облегчение поиска другому разработчику? Поиска чего? Функционал ведь ищется исходя из кода или перекрестных ссылок, а вовсе не по наименованию.

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

Можно пройтись по всем пунктам и я не вижу принципиальной разницы. Да хоть горшком назови!

PS: Мне это напоминает дискуссию об "идеальном справочнике". Ту ее часть, где речь шла об идентификаторах элемента справочника. В конце-концов все сошлись на том, что это совершенно не имеет значения. А ведь в данной теме обсуждается именно это. Какой идентификатор объекта лучше? Да без разницы! Вопрос исключительно личных предпочтений

PPS: Как мне кажется, сама дискуссия "выросла" из того, что стандартный функционал неявно навязывает определенный стиль именования (тот же префикс в виде названия модуля). Как следствие, все то, что "выбивается" из этого стиля воспринимается как нечто "не естесственное" (читай - непривычное, "не стандартное"). При этом никто не ставит под сомнение этот самый "стандартный стиль" не потому, что он такой уж "правильный", а потому, что изменить его невозможно! Остается только ему следовать. Ну, и поддерживать несколько стилей сложнее, чем один.

[glibs]

На мой взгляд как консультанта с навыками разработки дублирование в системе одних и тех же сущностей противоречит концепциям ООП и противоестественно для самой Аксапты.

Сам стараюсь использовать стандартные типы. А если создавать, по такому же принципу как стандартные.

С Еременко, который рекомендовал при создании своего решения генерировать свои типы даже если такие же в системе уже есть (в книжке по 3.0 еще), мотивируя это тем, что в стандартном типе может поменяться метка, — принципиально не согласен.

Приложение после нескольких внедренцев видел. Для меня это дико. Попытка найти нужный тип раздражает.

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

Я не против суффиксов. С поиском они не мешают. Сам обычно не использую.

Насчет апгрейда кода. Мне кажется, что в процессе апгрейда вопрос стоит не в том, кто именно создал объект, если разработчик объекта не анархист в отношении ВР. Слоев и комментариев обычно достаточно.

[titov]

Цитата:

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

Вопрос исключительно личных предпочтений. ... Ну, и поддерживать несколько стилей сложнее, чем один.

Цитата:

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

Сам стараюсь использовать стандартные типы. А если создавать, по такому же принципу как стандартные.

В точку по нескольким стилям и стандарту.
ВР раньше рекомендовал префикс\суффикс. Родились разные стили и привычка к ним - без, один из вариантов, вариации в виде сочетаний. Теперь мнения разделились по поводу - а как правильно? Сколько стилей столько и мнений. И доводы разные, но сводятся всего к трем - уникальность, авторство и просто удобство - так привыкли, или так.

Думаю, что правильно для нас всех - одинаково по единому регламенту, желательно полученному от поставщика продукта! Тогда код будет понятен всем, и из других компаний, а не только группе разработки со своим стилем.

Цитата:

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

Против префиксов я категорически. Я не против суффиксов. С поиском они не мешают.

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

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

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

[glibs]

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

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

Навижн получил "_RU" по наследству в 2001-м, насколько я представляю. С тех пор так и осталось. И было применено на всю Восточную Европу впоследствии.

Да, временами взгляда на объект достаточно чтобы понять чей он. С этой точки зрения удобно, не спорю. Но это не панацея. Есть и альтернативы (и в рамках ВР).

По поводу авторства таблицы, типа данных, пунктов меню и схожих типов объектов мне кажется лучшим вариантом указывать в них конфигурационный ключ. Это не коверкает названия, но позволяет получить ответ на вопрос о принадлежности. Я видел команды разработчиков, которые так делают. С разными вариациями.

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

[EVGL]

Цитата:

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

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

Когда появились первые "_RU", еще долго не было никаких проектов. Просто как-то повелось...

Смысл использования префиксов/суффиксов сильно увязан с наличием и качеством документации по проекту.

Если есть вменяемые детальные описания автоматизируемых процессов, которые порождают пронумерованные задания на разработку, то смысл в префиксах/суффиксах есть.

Пример:
Название SomeTable_R012
говорит нам о том, что таблица была добавлена в рамках задания 12 проекта внедрения с кодом R (возможно это первая буква в названии консалтера).
Ищем проектную документацию этого консалтера, находим задание 12 и описание процесса, автоматизации которого способствовало выполнение данного задания.
После прочтения становится ясно с какой целью это появилось и как это использовать.

Поля в новой таблице называем без префиксов.

Затем в новом задании 128 нам вдруг понадобилось добавить поле в SomeTable_R012. Называем его SomeField_R128. Это говорит нам о том, что описание полей без суффикса искать в задании 12, а описание этого поля в задании 128.
Тоже самое проделываем, если добавляем поле в стандартную таблицу.

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

[oip]

Цитата:

Сообщение от Кирилл

Название SomeTable_R012 говорит нам о том, что таблица была добавлена в рамках задания 12 проекта внедрения с кодом R (возможно это первая буква в названии консалтера)
....
Затем в новом задании 128 нам вдруг понадобилось добавить поле в SomeTable_R012. Называем его SomeField_R128. Это говорит нам о том, что описание полей без суффикса искать в задании 12, а описание этого поля в задании 128.
Тоже самое проделываем, если добавляем поле в стандартную таблицу.

В очередной раз спрошу. Что мешает оставлять комментарии в коде с названием проекта, номером модификации, датой и id разработчика? Что мешает пользоваться системой контроля версий? Зачем уродовать приложения всякими SomeField_R128? На наших проектах никогда не встает вопрос о том, кто, когда и зачем написал какой-то код/добавил объект - это итак ясно. Хотя никаких префиксов и суффиксов мы не используем. Что мы делаем не так?

Цитата:

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

В очередной раз спрошу. Что мешает оставлять комментарии в коде с названием проекта, номером модификации, датой и id разработчика? Что мешает пользоваться системой контроля версий? Зачем уродовать приложения всякими SomeField_R128?

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

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

Цитата:

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

На наших проектах ...

На чьих проектах?

Цитата:

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

Что мы делаем не так?

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

[oip]

Цитата:

Сообщение от Кирилл

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

Есть система контроля версий.

Цитата:

Сообщение от Кирилл

На чьих проектах?

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

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

Вот как раз хорошо документированное приложение и не требует никаких префиксов-суффиксов.

P.S. Наболело просто. Сейчас как раз частично работаю в приложении, где приняты префиксы. Ужас.

[sukhanchik]

2Кирилл: Подход интересный - но не могу не согласиться с мыслью от oip - что от цифр в коде рябить будет.
Во-первых - есть неудобство по отношению к консалтинговой компании. Если хочется "разлить" на несколько приложений (разным заказчикам) одну и ту же модификацию - то придется перенумеровывать поля, т.е. править код.
Во-вторых - есть неудобство по отношению к запоминанию полей. Думаю, что многие специалисты уже привыкли к штатным названиям полей - типа CostAmountPosted, AmountCurDebit и т.д. Без технологии IntelliSense (а она далеко не везде применима) - вспомнить название поля может быть нетривиальной задачей. Конечно по сравнению с префиксами - может так и лучше - но ... наверное действительно вопрос привычки.

Кстати - по ходу писания возник вопрос. А как дела обстоят с перекрытыми методами? Их же нельзя переименовывать? Добавили мы метод myMethod_R0123(). Спустя полгода - решили сделать наследника класса и перекрыть этот же метод. Он будет сделан уже в рамках другой модификации. А нумерация останется той же?
Аналогичный вопрос по отношению к Map-ам и нумерации полей в нем. Особенно интересно - когда 2 поля в разные таблицы были добавлены в рамках двух разных модификаций, а соединить в Map все это было решено в рамках 3-й модификации.

Лирическое отступление. В свое время довелось мне спорить с Валерием Ушаковым (VALU - для тех кто знает - отвечал некоторое время за разработку АХ в МС) по поводу оформления смысловых комментариев в коде. Он был противником любых комментариев в коде. В качестве убийственного аргумента, с которым я не смог не согласиться был довод - что любая документация нуждается в обновлении при изменении кода. Т.е. если я пишу в качестве комментария - описание того, что делает тот или иной класс/метод, то при изменении кода - я обязан изменить комментарий (а это лишнее время). При этом для человека, который будет разбираться в моем коде - наличие неверных комментариев гораздо больше будет мешать вниканию в код, нежели их отсутствие.
Т.о. получается следующая ситуация - что наличие корректных комментариев (=корректная ссылка на документацию) помогает разобраться в коде, а наличие некорректных комментариев (=некорректная ссылка на документацию) - только мешает.
Отсутствие комментариев - действует нейтрально. Теперь - зададимся все вопросом - мы всегда обновляем свои и чужие комментарии в коде при его изменении? А если эта ссылка "зашита" в название поля/метода/объекта?

[glibs]

Кирилл, а в чем практическая ценность понимания на основании какого задания что-то добавлено?

Предположим, что мы добавляем на основании задания 25 в некой таблице поле Currency_25. В задании 60 нам нужно использовать поле с валютой в этой же таблице. Я предполагаю, что еще одно поле Currency_60 вы не создаете, а используете существующее. И вряд ли его переименовываете в Currency_25-60 с перелопачиванием всего кода.

Разработчик все равно будет пользоваться перекрестными ссылками и прочими стандартными инструментами.

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

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

[mazzy]

Цитата:

Сообщение от Кирилл

Пример:
Название SomeTable_R012
говорит нам о том, что таблица была добавлена в рамках задания 12 проекта внедрения с кодом R (возможно это первая буква в названии консалтера).

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

с суффиксом получится
SomeTable_R012_D0045_C05

с префиксом получится
C05_D0045_R012_SomeTable

[mazzy]

Цитата:

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

Есть система контроля версий.

Угу. А вы его устанавливаете всем клиентам?
А если программисты клиента тоже работают в этом приложении и категорически отказываются? (типа, сложно...)

(впрочем, это оффтопик)

Цитата:

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

P.S. Наболело просто. Сейчас как раз частично работаю в приложении, где приняты префиксы. Ужас.

[titov]

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

Лучше для кого? - одного разработчика, группы, партнера, клиента, майкрософт или всех вместе взятых? - В новом ВР и отражена "новая" точка зрения поставщика продукта на подход к вопросу наименования - без преффиксов\суффиксов - именно так лучше для ВСЕХ!. Все-таки приоритет теперь только за бизнес-логикой.

Стоит ли от них избавлятся? По старым версиям, думаю, нет. Скажем так - там мы живет по тем "старым законам - ВР с преффиксами\суффиксами". А на при переносе на новую версию с "новыми законами" - ВР - Да!, по возможности избавляться. По возможности - если это не противоречит уже юридическим законам.

Как правильнее? - По актуальному правилу (ВР) на текущую версию.

PS Надо признать, что старый ВР привил нам очень сильную "привычку" и создал целую "культуру" мысли в разных направлених. Майкрософт это признал. Осталось дело за нами.

[miklenew]

Цитата:

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

Есть клиент.
Теперь с ним работаем мы. Но раньше с ним кто только не работал.

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

Поскольку кастомизированных таблиц и полей много, то сложно запомнить какие префиксы и в какой момент нужно использовать. Что выбешивает.

Вопросы:
= что лучше использовать на ваш взгляд для того, чтобы обозначить разработчика - префиксы/суффиксы/ничего?
= вы бы стали рефакторить приложение, избавляясь от префиксов (или превращая их в суффиксы)? каковы плюсы и минусы такого рефакторинга?

А также хотелось бы услышать ваше мнения и размышления по поводу префиксов/суффиксов.
Используете ли вы префиксы/суффиксы?
Когда они вам пригодились, а когда нет?

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

Заранее спасибо.

1) Если код пишет клиент, то использует свой префикс.
2) Если код пишет консалтинг для клиента, то желательно чтоб использовал свой префикс.
3) Префикс используем только для нового объекта. Для методов или полей этого объекта не используем. Т.е. ситуация когда место DDD_Codes.OKVED будет DDD_Codes.KKK_OKVED считается исключительной. Т.е. написал например свой объект консалт. А клиенту потом пришлось дописывать(создать у этого объекта свой метод). Или наоборот. Но при этом смотря на объект сразу понятно кто писал и что было вмешательство в алгоритм.
4) Я придерживаюсь мнения, что если объект писал один человек, то он его и должен дорабатывать. С таким подходом исключительных ситуаций возникает мало.
Если консалтинг своё отработал и необходимо вмешательство. Ок. Делай на его объекте метод с клиентским префиксом и работай. Как только на этом объекте будет рябить в глазах от префиксов, это значит что класс сильно переработали и это повод для рефракторинга.
А в первоначальной постановке вопроса вижу какую то предвзятость.
1) Потому что специально наверно сделали связку префикс_префикс_префикс. Которая не является нормой для подход изложенного выше. А является нормой для какого то другого подхода.
2) имя метода OKVED написано капсом. Что само посебе заставляет задуматся.

[gl00mie]

Цитата:

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

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

К слову, суффиксы по странам в локализации очень сильно упрощают понимание того, какое поле/метод/таблица/класс для какой страны предназначены и насколько в твоем конкретном случае применимы и нужны. К примеру, скрипты обновления данных отчасти грешат тем, что не всегда увязывают выполнение того или иного метода с конфигурационным ключом для соответствующей страны. Так вот, когда нужно ускорить процесс конвертации базы при обновлении, то, видя такие суффиксы в названиях методов или обрабатываемых в них полей/таблиц, сразу понимаешь, что их можно безболезненно отключить. Аналогично с полями таблиц в повседневной работе: если есть какое-то "многообещающее" по названию поле, но с суффиксом от явно не используемой на данном проекте локализации, сразу понятно, что рассчитывать на него не стоит.
Но тут ситуация сильно отличается от того, что обсуждается в данной теме: стандартное приложение поставляется "как есть" - без всяких там историй в системе контроля версий и документации по запросам, на основании которых появились те или иные поля/таблицы/классы, в то время как для доработок такая дополнительная информация как минимум может (если не должна) быть обеспечена разработчиками.

Цитата:

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

В свое время довелось мне спорить с Валерием Ушаковым (VALU - для тех кто знает - отвечал некоторое время за разработку АХ в МС) по поводу оформления смысловых комментариев в коде. Он был противником любых комментариев в коде.

К счастью, подход MS в целом к комментированию кода стандартного приложения коренным образом изменился.

Цитата:

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

В качестве убийственного аргумента, с которым я не смог не согласиться был довод - что любая документация нуждается в обновлении при изменении кода. Т.е. если я пишу в качестве комментария - описание того, что делает тот или иной класс/метод, то при изменении кода - я обязан изменить комментарий (а это лишнее время).

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

Цитата:

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

наличие корректных комментариев (=корректная ссылка на документацию) помогает разобраться в коде, а наличие некорректных комментариев (=некорректная ссылка на документацию) - только мешает. Отсутствие комментариев - действует нейтрально. Теперь - зададимся все вопросом - мы всегда обновляем свои и чужие комментарии в коде при его изменении? А если эта ссылка "зашита" в название поля/метода/объекта?

За "мы" не скажу - я обновляю и, порой, комментирую чужой код, если при модификации нахожу какие-то моменты трудными для (собственного) понимания или важными по неочевидным причинам. Если же в названии поля/метода объекта написано одно, а вы делаете так, что смысл получается совсем иной (скажем, в методе написано validate, а вы в нем начинаете данные править), то это явно указывает на ошибки в проектировании - либо у исходного автора, либо у того, кто вносит модификации. Что мешает переименовать поле/метод, чтобы название корректно отражало "новые реалии"? Опять время экономим? См. также исправление имён

[Raven Melancholic]

Комментарии в коде, описывающие проект, разработчика и т.п. то же вызывают неоднозначное отношение, вспомнил ветку:
А в ваших разработках тоже не принято ставить комментарии?
То же очень интересует вопрос, нужно ли использовать префиксы-суффиксы. Пока везде, где работал использовались суффиксы, кроме одного места шабашки, где используют префиксы - лично мне этот подход очень не понравился.
Может быть для статистики mazzy добавить к теме голосовалку? Хочется посмотреть статистику.

[mazzy]

Цитата:

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

4) Я придерживаюсь мнения, что если объект писал один человек, то он его и должен дорабатывать. С таким подходом исключительных ситуаций возникает мало.
Если консалтинг своё отработал и необходимо вмешательство. Ок. Делай на его объекте метод с клиентским префиксом и работай. Как только на этом объекте будет рябить в глазах от префиксов, это значит что класс сильно переработали и это повод для рефракторинга.

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

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

Цитата:

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

А в первоначальной постановке вопроса вижу какую то предвзятость.
1) Потому что специально наверно сделали связку префикс_префикс_префикс. Которая не является нормой для подход изложенного выше. А является нормой для какого то другого подхода.
2) имя метода OKVED написано капсом. Что само посебе заставляет задуматся.

1) я тоже не знаю почему так сделали. но оно есть
2) Блондинка я, блондинка.

Цитата:

Сообщение от Raven Melancholic

Может быть для статистики mazzy добавить к теме голосовалку? Хочется посмотреть статистику.

Думал об этом.
Но не вижу осмысленных вариантов.

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

Предложите варианты.

[CDR]

Пожалуй вставлю свои пять копеек...

Как показывает практический опыт, от использования различных кодов (номер модификации, номер проекта и т.п.) в наименовании объектов системы абсолютно никакой пользы нет! Однако их использование значительно ухудшает восприятие кода. Единственное исключение - Использование номеров модификаций в наименовании проектов (при условии, что есть какой-то реестр модификаций со сквозной нумерацией).

Использование префиксов в классическом смысле (большие буквы с нижним подчеркиванием) в наименовании объектов также стараюсь избегать. Однако использование смысловых префиксов (какое-то имя, объединяющее группу разных объектов по общему смыслу) очень удобно. Классический пример - название модуля в имени объекта. Хотя каких-то концептуальных различий между префиксом "LG_" и "Ledger" я не вижу. Просто исторически так сложилось, что используется удобочитаемый префикс, который облегчает восприятие кода. Соответственно не вижу смысла изобретать велосипед и ставить везде какие-то особенные префиксы.

Суффиксы часто использую в классах-наследниках для их группировки в АОТ. Однако опять же использую в основном смысловые суффиксы ("_Purch", "_Sales"), а не классические ("_RU").

Аргумент, что правильное наименование облегчает поиск объекта в AOT, считаю полным бредом. Как правило, поиск 90% объектов в системе начинается с меню/формы. И тот факт, что в классе использован префикс "Ledger" вместо "LG_" абсолютно никак не ускоряет его.

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

Вообщем, мое ИМХО, использование префиксов/суффиксов зависит от уровня профессионализма программиста. Чем выше уровень, тем больше программист уделяет внимания восприятию своего кода и его удобочитаемости , и тем меньше использует классические префиксы/суффиксы, а все больше смысловые.