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

Цитата:

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

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

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

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

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

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

[miklenew]

Цитата:

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

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

А мне всегда казалось, что префиксы не используют люди с большими амбициями и с большим желанием всё сделать по быстрому. Оказывается они просто мегагуру.
Работал и так и так и с префиксами и с префиксами ввиде названия модуля. И одно другому не мешает. префикс_названиемодуля_ит.д.
В коде вверху создаёте переменную.

        ;

и дальше работаете без префикса.
А статические методы они на то и статические чтоб вызвал и забыл.

Цитата:

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

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

Ага а остальные 10% можно не искать.
С префиксами получается 90+10. А без префиксов 90.
А сколько раз в день вы тыкаете в аот и набираете с клавы какое нибудь название, чтобы система привела вас курсором к этому объекту?
Кроме того используя перекрёстные ссылки я бывает просто отбрасываю часть объектов с префиксами или без в зависимости от того что ищу.

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

А сколько раз в день вы тыкаете в аот и набираете с клавы какое нибудь название, чтобы система привела вас курсором к этому объекту?

даже не "тыкаете в аот", а в редакторе кода нажимаете F2, Ctrl+T, F12, F11 и т.п.
префиксы в этих выпадающих списках... ну, как серпом по яйцам.

и не сочтите за рекламу.
лично я купил и активно юзаю axassist. эта штука ускоряет кодирование во много раз.

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

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

[mazzy]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

Да

Цитата:

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

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

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

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

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

[oip]

Поле добавлено в задании R128. А в задании R176 серьезно меняется принцип его заполнения так, что R128 становится уже неактуальным. Что делать? Важно же не где объект создавался, а где описано его текущее состояние.

[CDR]

Цитата:

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

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

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

Цитата:

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

Работал и так и так и с префиксами и с префиксами ввиде названия модуля. И одно другому не мешает. префикс_названиемодуля_ит.д.
В коде вверху создаёте переменную.

        ;

и дальше работаете без префикса.
А статические методы они на то и статические чтоб вызвал и забыл.

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

Цитата:

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

Ага а остальные 10% можно не искать.
С префиксами получается 90+10. А без префиксов 90.
А сколько раз в день вы тыкаете в аот и набираете с клавы какое нибудь название, чтобы система привела вас курсором к этому объекту?
Кроме того используя перекрёстные ссылки я бывает просто отбрасываю часть объектов с префиксами или без в зависимости от того что ищу.

Остальные 10% процентов объектов каждый уважающий себя DAX-программист должен знать наизусть!

Цитата:

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

Поле добавлено в задании R128. А в задании R176 серьезно меняется принцип его заполнения так, что R128 становится уже неактуальным. Что делать? Важно же не где объект создавался, а где описано его текущее состояние.

У Аксапты же идеология выражается словами "аудиторский след"
Тут странно читать о том, что важно лишь текущее состояние.

Принцип заполнения выражается на X++, где есть X++ там есть и комментарии.
Там будет что-то типа

 \\ OIP 07.10.2010 R176 ...

Так мы видим историю развития приложения.

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

[pitersky]

Цитата:

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

У Аксапты же идеология выражается словами "аудиторский след"
Тут странно читать о том, что важно лишь текущее состояние.

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

[oip]

Цитата:

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

У Аксапты же идеология выражается словами "аудиторский след"
Тут странно читать о том, что важно лишь текущее состояние.

Еще раз. Для "аудиторского следа" есть система контроля версий, которая для этого и предназначена. С помощью префикса вы можете узнать только модификацию, в рамках которой поле просто создавалось, не больше. Эта информация нужна, скажем прямо, очень-очень редко. Гораздо чаще нужна информация о как раз текущем состоянии. А в поле вы информацию о создании зашиваете навсегда. Плохо.

Если по какой-то причине вам очень часто надо узнавать, в рамах какой модификации добавлялось поле, есть куча способов гораздо лучше, даже если вы почему-то не хотите использовать систему контроля версий. От ветки с Application Documentation в АОТе до статического метода description на таблице. И заметьте, при этих способах очень редко нужная информация о номере модификации не будет постоянно мелькать перед глазами. А смотреть ее будут только тогда, когда (если) она понадобится.

[miklenew]

Цитата:

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

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

Это была ирония на ваши слова.

Цитата:

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

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

Цитата:

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

1) Смысловые префиксы облегчают восприятие кода другим программистом - это факт. 2) Программист, думающий о восприятии своего кода другим программистом, как правило думает и о развитии и сопровождении своего кода. 3) А это уже серьезная заявка на то, что бы быть мегагуру!

1)-2) это технология работа, какая бы она не была в организации ей нужно следывать.
3) Всё не пойму, зачем вы пытаетесь что в первом что во втором сообщении как то класифицировать уровень разработчиков? Одни хорошие делают так, другие так не делают значит они плохие разработчики. В моём понимание хороший специалист в своём деле, никогда не станет мегагуру, если он будет закрывать так вопросы. Помню собрались специалистов по аксе с двух компаний, человек 40. И начальник айтишников место ответа на вопрос о технологии работы начал рассказывать о своём авторитете. Лучше бы он ответил, обсудим позже.
И такие cлучаи к сожаленью не редки.
Вот mazzy. Он на этом форуме давно и в аксе давно, но я не помню чтоб он ссылался на свой авторитет хоть в одной теме. Он либо приводит доводы или просто высказывает свою точку зрения или случаи из жизни. С таким подходом даже если он человека не переубедит, человек может сам современем передумать.

Цитата:

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

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

В приведенном выше примере как раз пошагово и были прослежены 2 изменения, если 2 мало, можно привести пример для 3 и т.д.

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

Цитата:

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

Еще раз. Для "аудиторского следа" есть система контроля версий, которая для этого и предназначена.

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

Цитата:

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

есть куча способов гораздо лучше

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

[glibs]

Цитата:

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

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

Вы разработчиков Микрософта имеете в виду?

Считаете, что стандартный код хуже вашего? Если вы представитель заказчика, собираетесь работать на нем вечно? Вы вообще код рефакторите?

Если в общем, я за единообразие кода. Вижу в этом плюсы.

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

В общем, думаю что я уже пасс дальше обсуждать. Кто прочитает — пусть думает и решает.

[CDR]

Цитата:

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

Это была ирония на ваши слова.

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

1)-2) это технология работа, какая бы она не была в организации ей нужно следывать.
3) Всё не пойму, зачем вы пытаетесь что в первом что во втором сообщении как то класифицировать уровень разработчиков? Одни хорошие делают так, другие так не делают значит они плохие разработчики. В моём понимание хороший специалист в своём деле, никогда не станет мегагуру, если он будет закрывать так вопросы. Помню собрались специалистов по аксе с двух компаний, человек 40. И начальник айтишников место ответа на вопрос о технологии работы начал рассказывать о своём авторитете. Лучше бы он ответил, обсудим позже.
И такие cлучаи к сожаленью не редки.
Вот mazzy. Он на этом форуме давно и в аксе давно, но я не помню чтоб он ссылался на свой авторитет хоть в одной теме. Он либо приводит доводы или просто высказывает свою точку зрения или случаи из жизни. С таким подходом даже если он человека не переубедит, человек может сам современем передумать.

У вас какое-то своеобразное восприятие моих слов в каком-то своем контексте.
Все мои ответы были даны исключительно в контексте исходного вопроса Сергея. А он спрашивал не о классификации разработчиков, а именно о "технологии разработки". Соответственно и я не делил разработчиков на уровни в зависимости от использования ими префиксов/суффиксов, потому что как вы правильно отметили, разработчики обязаны руководствоваться в своей работе уже принятыми правилами/стандартами разработки. А вот разрабатывает эти правила/стандарты обычно один человек - руководитель группы разработки (технический архитектор, ведущий разработчик, т.п.). И смысл моего исходного поста был в том, что чем выше уровень проффесионализма этого человека, тем больше он обращает внимание на эффективность своей и чужой работы, и тем четче у него понимание того простого факта, что наименование объектов в системе должно служить лишь одной единственной цели - простое и быстрое восприятие уже написанного кода, впрочем как и все остальные требования к написанию кода. Для решения всех остальных задач есть другие инструменты как в самой системе так и вне ее, позволяющие решать эти задачи опять же более эффективно.

Цитата:

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

В общем, думаю что я уже пасс дальше обсуждать. Кто прочитает — пусть думает и решает.

+1

[pitersky]

Цитата:

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

В общем, думаю что я уже пасс дальше обсуждать. Кто прочитает — пусть думает и решает.

Я тоже так думаю

[samolalex]

Немалый объем книги Стива Макконнелла "Совершенный код" посвящен парвильному именованию переменных, классов, их методов, отдельных функций без привязки к конкретному языку программирования. Автор, по-моему, является сторонником "осмысленного именования" вышеперечисленных конструкций посредством использования так называемых префиксов и суффиксов.
Я тоже более склонен к подобному принципу именования языковых конструкций, в котором используются и префиксы, и суффиксы. Главное, чтобы их использование было по существу и со смыслом. Это может в дальнейшем помочь быстрей разобраться с объемным кодом самому же разработчику, а также сторонним программистам. И как мне кажется, использование этих "морфологических элементов" должно быть строго регламентировано на уровне компании и максимально приближено к общим стандартам программирования (хотя это понятие - "стандарты программирования", достаточно расплывчато и динамично).

[Murlin]

Цитата:

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

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

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

Такой подход баальшой геммор для разработчиков
Просто так на форму из датасурса не перетянещь поле, или в отчет.
Одни и теже поля могут повторяться с разными префиксами. Ну и какое из них оставить? Мне не нравиться такой подход слишком все сложно будет и запутанно.
Недавно редактировал одну таблицу которую я в глаза до это не видел(забыл какое поле нужно добавить было) ну пусть custaccount чтобы я ее добавил с соответствующим префиксом. Т.к. не нашел на этой таблице поле custAccount(accountnum)и тд, там она была но именована с префиксом, просто не была вынесена на форму.
Не знаю, не понимаю до сих пор какая выгода в этих префиксах.
Может быть можно именовать классы, формы, еще какие то объекты, но переименовывать salesId в X_SalesId Или в salesId_x чо то слишком.