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

[titov]

Цитата:

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

[glibs]

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

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

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

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

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

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

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

[glibs]

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

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

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

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

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

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

[EVGL]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

Пример:
Название 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]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

Если же все последующие проекты записывать каким-то образом в первоначальный проект. Но снова возникает вопрос неактуальности. Расхождений кода и документации и т.п.
И снова разработчик должен сканировать код.

Цитата:

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

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

Да

Цитата:

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

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

А как изменен?
На примере таблицы добавленной в рамках одного задания и поля, добавленного в нее в рамках другого задания все прозрачно.

Поля SomeTable_R12, которые не имеют суффиксов описаны в R12, поле SomeField_R128 из таблицы SomeTable_R12 описано в R128.

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

[sukhanchik]

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

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

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

Цитата:

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

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

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

В примере каждое поле в таблицах имеет свой суффикс 1 и 2, у нового мапа суффикс 3, а у его полей вообще нет суффиксов.

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

[glibs]

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

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

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

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

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

[titov]

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

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

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

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

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

Цитата:

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

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

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

Новые бойцы читать документацию ради ее чтения вряд ли будут. Полистают максимум.

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

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