AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Результаты опроса: Какой вариант вы бы предпочли? И почему?
validateAndWrite() + validateAndWriteNoThrow() 1 8.33%
validateAndWriteOrThrow() + validateAndWrite() 0 0%
validateAndWrite(boolean noThrow = false) 1 8.33%
validateAndWrite(boolean noThrow = true) 0 0%
validateAndWrite(boolean throwIfError = false) 0 0%
validateAndWrite(boolean throwIfError = true) 2 16.67%
я предложил свой вариант в этой ветке 2 16.67%
затрудняюсь ответить, просто хочу посмотреть результаты опроса 6 50.00%
Голосовавшие: 12. Вы ещё не голосовали в этом опросе

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 30.07.2021, 13:14   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
[CodeStyle] методы *noThrow vs *OrThrow vs optional parameter?
Вопрос про стиль кодирования. Любая версия аксапты.

Disclaimer:
Понимаю, что о стилях не спорят.
Поэтому спрошу "а как вы предпочитаете делать сами"?
Мало того, чтобы отсечь уложняющие моменты, вопрос будет не о стандартной аксапте, а о самописном методе.

Итак,
в жизни есть методы, которые могут вернуть true/false, а могут бросить исключение.

типичный пример: вы создаете метод validateAndWrite(). этот метод выполняет validateWrite() и write().

по идее, метод validateAndWrite может:
* вернуть true/false, тогда вызывающий метод обязан обработать результат и что-то сделать.
* бросить исключение если validateWrite не прошел.

а можно создать два метода - один бросает исключение, а второй возвращает true/false. также можно добавить опциональный параметр в единственный метод.

И тут собственно вопрос по CodeStyle.
Какой вариант вы бы предпочли? И почему?
__________________
полезное на axForum, github, vk, coub.
Старый 30.07.2021, 13:25   #2  
axm2017 is offline
axm2017
Участник
 
1,747 / 292 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от mazzy Посмотреть сообщение
типичный пример: вы создаете метод validateAndWrite(). этот метод выполняет validateWrite() и write().
...
И тут собственно вопрос по CodeStyle.
Какой вариант вы бы предпочли? И почему?
Предпочел бы validateWrite() и write()
В чем смысл одной функции с функционалом двух не очевидно
Старый 30.07.2021, 13:38   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от axm2017 Посмотреть сообщение
Предпочел бы validateWrite() и write()
В чем смысл одной функции с функционалом двух не очевидно
axm2017, вы снова показали, что ни фига не умеете читать вопросы и ТЗ.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Вопрос про стиль кодирования.
Есть у кого ответы про стиль кодирования?
Спасиба.
__________________
полезное на axForum, github, vk, coub.
Старый 30.07.2021, 13:47   #4  
axm2017 is offline
axm2017
Участник
 
1,747 / 292 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от mazzy Посмотреть сообщение
axm2017, вы снова показали, что ни фига не умеете читать вопросы и ТЗ.
Увы.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Есть у кого ответы про стиль кодирования?
Спасиба.
Сферический конь в вакууме конечно интересно, но стиль рождается от практики. Если некорректный пример то смысл рассуждать дальше.
Старый 30.07.2021, 13:50   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
axm2017, спасибо за ваше ценное мнение.

итак,
Цитата:
Сообщение от mazzy Посмотреть сообщение
И тут собственно вопрос по CodeStyle.
Какой вариант вы бы предпочли? И почему?
__________________
полезное на axForum, github, vk, coub.
Старый 30.07.2021, 14:37   #6  
Pandasama is offline
Pandasama
Участник
 
448 / 133 (5) +++++
Регистрация: 11.08.2014
Адрес: Барнаул
Возможно я тоже вопроса не понял, но я бы предпочел сделать/иметь один метод с опциональным параметром - ибо зачем плодить сущности в виде двух методов (которые внутри себя, вероятно, ещё вызывают третий с параметром - чтобы код не дублировать)?
За это сообщение автора поблагодарили: mazzy (2).
Старый 30.07.2021, 14:48   #7  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
не знаю почему, но я в 95% случаев в своем коде validateWrite() просто не вызываю. Просто мне кажется что механизм этот был придуман для контроля пользовательского ввода. В своем коде я скорее в какие-нибудь транзакционные таблицы или таблицы с документами пишу, в которых validateWrite() обычно отсутствует. Есть конечно 5% случаев когда приходится в справочники или таблицы документов писать (при всяких импортах например), и мне в этих 5% случаев не тяжело руками написать if (table.validateWrite()) table.update()
Вообще я когда в коде вижу расставленые на всех таблицах initValue(), validateField() и validateWrite(), мне сразу приходит в голову что код новичек писал и вызов этих методов - карго-культ.
За это сообщение автора поблагодарили: Ace of Database (2), vmoskalenko (5).
Старый 30.07.2021, 15:22   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Pandasama Посмотреть сообщение
ибо зачем плодить сущности в виде двух методов
Чтобы использование было удобным.
сравни код, который использует такие методы:

X++:
buf.validateAndWriteOrThrow(); // ок понятно что происходит, и понятно, что результата нет

if (buf.validateAndWriteNoThrow()) // тоже понятно, хотя и длинно
  ...

buf.validateAndWrite(); // будет исключение или нет? может просто результат отбрасывается?
                        // легко решить, если в классе реализованы оба метода
                        // легко ошибиться и пропустить результат, если в классе только один метод с опциональным параметром

buf.validateAndWrite(false); // а что собственно здесь происходит?
                             // надо заглянуть в класс или посмотреть в tooltip-подсказку
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 30.07.2021 в 15:27.
Старый 30.07.2021, 17:18   #9  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Проголосовал за первый вариант validateAndWrite() + validateAndWriteNoThrow()

Но как и остальным написавшим мне тоже это всё не нравится. Якобы "безопасный" метод, который перехватывает свои исключения и не отдаёт их наружу не должен быть нормой. Это скорее исключение, синтаксический сахар. Это грязный метод, после вызова которого остаётся неопределённость: а что именно выполнилось, что откатилось. Лучше так не делать, а если уж делать такие методы, то пусть их будет видно издалека.
За это сообщение автора поблагодарили: mazzy (2).
Старый 30.07.2021, 17:46   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
а почему только boolean в параметрах. иногда приходится писать что-то где есть 3 значения.
1 - просто возвращать true-false для дизейбла кнопок на форме
2- показывать warning без исключения - когда что-то нельзя сделать, но дальнейший код не прерывать, т.е. типичный сценарий показывать ошибки по всем строкам журнала
3- выдавать исключение
Т.е. это один метод типа validateAndWrite с параметром типа enum
Старый 30.07.2021, 18:33   #11  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Но как и остальным написавшим мне тоже это всё не нравится. Якобы "безопасный" метод, который перехватывает свои исключения и не отдаёт их наружу не должен быть нормой.
да, было бы нормой.
но в аксапте в транзакции срабатывает только самый внешний catch.
поэтому никаких гарантий перехват не даст.

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

методы с OrThrow означают, что метод содержит throw, который явно вставил автор кода.

Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Это скорее исключение, синтаксический сахар. Это грязный метод, после вызова которого остаётся неопределённость: а что именно выполнилось, что откатилось. Лучше так не делать, а если уж делать такие методы, то пусть их будет видно издалека.
угу. я собственно поэтому и спрашиваю

да, именно про синтаксический сахар, который помогает понять код.
и самому не забывать о.
пример написания самих методов https://github.com/mazzy-ax/SysUtil/....xpp#L498-L519
пример использования я привел выше

Цитата:
Сообщение от trud Посмотреть сообщение
а почему только boolean в параметрах. иногда приходится писать что-то где есть 3 значения.
пиши.

Цитата:
Сообщение от trud Посмотреть сообщение
Т.е. это один метод типа validateAndWrite с параметром типа enum
(o_O)

ты ведь обратил внимание, что мы не сам метод validateAndWrite обсуждаем?
а оформление, которое касается исключений (Throw - NoThrow - OrThrow).
и о том, как оформление кода может помочь, а может запутать читателя.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 30.07.2021 в 18:40.
Старый 30.07.2021, 19:23   #12  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
а оформление, которое касается исключений (Throw - NoThrow - OrThrow).
и о том, как оформление кода может помочь, а может запутать читателя.
Обработку исключений я бы делал снаружи. Потому что обработка внутри метода сразу ограничивает возможности его использования. Лучше иметь больше возможностей, чем меньше. Лучше иметь возможность по-разному реагировать на исключения в разных случаях использования такого метода, чем не иметь возможности этим управлять,
Старый 30.07.2021, 19:41   #13  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Zabr Посмотреть сообщение
Обработку исключений я бы делал снаружи.
делайте.
(только помните, что любой может начать транзакцию и вызвать ваш код. и ваша обработка тут же превратится в тыкву во внутреннюю)

а внутри то методы как писать?
__________________
полезное на axForum, github, vk, coub.
Старый 30.07.2021, 21:01   #14  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
а внутри то методы как писать?
Сергей, перечитайте свой исходный пост. Там нет вопроса, как писать внутри. Там вопрос, писать ли один метод или два. Вам отвечают на заданный вопрос, а Вы ожидаете ответов на другой вопрос, который не задавали. Поэтому Вам не нравятся ответы. Попробуйте переформулировать вопрос.

А писать надо красиво и аккуратно.
Старый 30.07.2021, 21:11   #15  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Вообще говоря, пример с validateWrite + Write наглядный, но вводит в заблуждение относительно самой постановки вопроса. Сразу вопрос о транзакциях, разделении проверки и модификации и т.д. и т.п. Если не рассматривать именно этот пример, а сосредоточится на исходной постановке

Метод возвращает true/false. Если false, то следует ли вызывать исключение вместо возврата false?

То тут проблема не столько в разовом (однократном) написании, сколько в сопровождении. Т.е. возможности внесения изменений

Например, к указанной постановке задачи еще добавляют, а надо ли в случае false, если это не throw выводить текст сообщения об ошибке? Или, например, делать throw не для всех ошибок, а только для определенных?

Если у нас один метод с параметром, то просто добавим еще параметры в этот один метод. А если методов много, то во все придется делать такое добавление.

Ну, и традиционно, дублирование кода получаем, что крайне не желательно. Впрочем, об этом уже говорили

Т.е. я за один общий метод с параметрами.

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

То же самое и по поводу сокращения написания кода. Ну очень сомнительный аргумент. Далеко не факт, что такое сокращение вообще получится. А в общем случае, основное время разработчик тратит вовсе не на первичное написание кода, а на его отладку.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 30.07.2021, 22:33   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Zabr Посмотреть сообщение
Сергей, перечитайте свой исходный пост. Там нет вопроса, как писать внутри. Там вопрос, писать ли один метод или два.
Цитата:
Сообщение от Zabr Посмотреть сообщение
Вам отвечают на заданный вопрос, а Вы ожидаете ответов на другой вопрос, который не задавали.
?!

некоторые отвечают.
вы конкретно где ответили? можно цитату?

Цитата:
Сообщение от Zabr Посмотреть сообщение
Поэтому Вам не нравятся ответы.
Бгггг!

Цитата:
Сообщение от Zabr Посмотреть сообщение
Попробуйте переформулировать вопрос.
Зачем?
Я хотел бы получить ответ именно на заданный вопрос

Цитата:
Сообщение от mazzy Посмотреть сообщение
И тут собственно вопрос по CodeStyle.
Какой вариант вы бы предпочли? И почему?


Цитата:
Сообщение от Zabr Посмотреть сообщение
А писать надо красиво и аккуратно.
Пишите. Не возражаю.
__________________
полезное на axForum, github, vk, coub.
Старый 30.07.2021, 23:13   #17  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Вообще говоря, пример с validateWrite + Write наглядный, но вводит в заблуждение относительно самой постановки вопроса.
Угу. Сознательно пошел на упрощение.
Была и другая вводная. Но я переписал на эту.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Сразу вопрос о транзакциях, разделении проверки и модификации и т.д. и т.п.
Именно-именно. О транзакциях. И о вложенных транзакциях.
О validate (который и в runbase есть) и write/update (который и в runbase есть)
Да-да. оставлены голые методы голого ядра. в которые тем не менее программист может вставить код.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если не рассматривать именно этот пример, а сосредоточится на исходной постановке

Метод возвращает true/false. Если false, то следует ли вызывать исключение вместо возврата false?

То тут проблема не столько в разовом (однократном) написании, сколько в сопровождении. Т.е. возможности внесения изменений

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

как появляются эти noThrow-метод (как я это вижу)
1. разработчики пишут обычный метод, который бросает исключение
2. а потом начинают его вызывать из другого кода, где есть своя транзакция. и...
3. опа! вложенные catch обработчики перестают работать.
Надо что-то делать!
4. из обычного метода выделяется смысловая часть в NoThrow-метод, которое возвращает какой-то результат. А выбрасывание исключения оставляется в исходном.

Давно уже один раз я видел, когда произошло немножко наоборот.
Чел заметил, что он всегда бросает исключение. Поэтому он написал OrThrow-метод. В результате получил очень чистый код в вызывающих методах.

Мне тогда очень понравилась эта техника. Чел, проявись, пожалуйста. дай наставить тебе лайков.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если у нас один метод с параметром, то просто добавим еще параметры в этот один метод. А если методов много, то во все придется делать такое добавление.
Вот да... получается, что во все... это и коробит.

если посмотреть на
https://en.cppreference.com/w/cpp/la.../noexcept_spec
https://docs.oracle.com/javase/tutor.../throwing.html
то видно, что люди думали над этой задачей. Но не сказать, что пришли к каким-то удовлетворительным решениям.

конкретно эта тема появилась здесь после плотного размышления над статьей
http://eao197.blogspot.com/2021/07/progthoughts-c.html

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

Опять же Котлин - там можно юзать именованные параметры в вызывающих методах. Что сразу делает читающему сухо и комфортно
https://kotlinlang.ru/docs/reference/functions.html

не говоря уже о контрактах и всевозможнных лямбдах и apply-методах
https://stackoverflow.com/questions/...ions-in-kotlin

ну и нормально работающих try/catch c finnaly...

и эцилопп меня не имеет права бить по ночам
...

ладно... в общем, вопрос что можно сделать в X++

Цитата:
Сообщение от mazzy Посмотреть сообщение
Какой вариант вы бы предпочли? И почему?
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Ну, и традиционно, дублирование кода получаем, что крайне не желательно. Впрочем, об этом уже говорили
ну, раз вы настаиваете,
расскажите почему вы решили что будет дублирование?

ну, хоть на примере noThrow методов в стандартной аксапте

пример в ax2009 - InventMovement::construct + InventMovement::constructNoThrow
пример в ax2012 - PcGlobalTableConstraintCellEditor::validateIntegerValue + PcGlobalTableConstraintCellEditor::validateIntegerValueNoThrow

если хотите, на примере того, что я выложил публично
https://github.com/mazzy-ax/SysUtil/....xpp#L496-L519

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Т.е. я за один общий метод с параметрами.
т.е. вы предпочитаете видеть в вызывающем методе подобный код:
X++:
buf.validateAndWrite(false)
ну, ооок...
а вы предпочитете видеть true или false для обозначения с исключением или без?
или стоит создавать специальный enum?
какой стиль лучше на ваш взгляд?

особенно для нескольких параметров.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Насчет того, что придется смотреть, что этот метод делает и что это за параметры, так это в любом случае придется делать. Даже если это будет в исходной постановке с кучей специализированных методов. По многим причинам
это да. в X++ да.
поэтому и вопрос - а какие другие причины могут делать тот или иной способ удобнее для читающего?

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
То же самое и по поводу сокращения написания кода.
Тю-тю-тю-тю... Стопэ!
у меня ничего про "сокращение написания кода" не было.
если вы считаете, что было - прошу цитату.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Ну очень сомнительный аргумент. Далеко не факт, что такое сокращение вообще получится. А в общем случае, основное время разработчик тратит вовсе не на первичное написание кода, а на его отладку.
с этим никто не спорит.
__________________
полезное на axForum, github, vk, coub.
Старый 31.07.2021, 19:20   #18  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от mazzy
расскажите почему вы решили что будет дублирование?
Пример с validateWrite + Write явно надуманный. Именно так сильно сомнительно что кто-то будет делать. Ну очень много вопросов именно по этой связке. Значит, речь идет о некоем собственном методе внутри которого выполняется некая проверка и, возможно, модификация данных

Ну, написал разработчик метод. Ну, перестал он корректно работать при определенных способах вызова. И что разработчик будет делать?

Нет, чисто теоретически, возможно, что разработчик выполнит рефакторинг кода, выделит отдельные методы и организует их вызов, чтобы исключить дублирование кода, но практически будет реализован один из 2 вариантов

1. Будет добавлен параметр в существующий метод
2. Будет создан метод дубликат, где вместо false вызовут исключение. Или наоборот, вместо исключения вернут false. Смотря по тому, что было изначально

Поскольку в данной теме речь идет именно о создании методов, то и получим дублирование кода

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

Цитата:
Сообщение от Владимир Максимов
Т.е. я за один общий метод с параметрами.
Цитата:
Сообщение от mazzy
ну, ооок...
а вы предпочитете видеть true или false для обозначения с исключением или без?
или стоит создавать специальный enum?
какой стиль лучше на ваш взгляд?

особенно для нескольких параметров.
Сама постановка вопроса не корректная. Как правило, подобные методы редко продумываются на этапе создания архитектуры проекта. Они возникают "естественным путем" по мере возникновения в них необходимости. Соответственно и варианты реализации также возникают "по месту". Вот что в данном случае покажется более уместным, то и делают

Т.е. у меня в данном вопросе нет предпочтений. "Как получится"

Цитата:
Сообщение от mazzy
это да. в X++ да.
поэтому и вопрос - а какие другие причины могут делать тот или иной способ удобнее для читающего?
Принятые правила. Best Practices. "Закон". "Пусть безобразно, зато единообразно" (с)

Нет и не может быть вариантов, делающих что-то "удобнее" кроме привычки. Тех самых "правил".

Этот вопрос многократно и по разным поводам поднимался. То, что удобно (читай "привычно") для одного будет неудобно (не привычно) для другого.

Я наблюдаю странные синтаксические конструкции, когда разработчик, привыкший работать в другом языке программирования тащит свои привычки в X++. Иногда что-то получается. Только вот я долго "туплю" над таким кодом, пытаясь понять, а что вообще хотели сделать-то? Именно по той причине, что "не привычно".

Цитата:
Сообщение от mazzy
Тю-тю-тю-тю... Стопэ!
у меня ничего про "сокращение написания кода" не было.
если вы считаете, что было - прошу цитату.
Да. Тут я не прав. Фразу "Чтобы использование было удобным." не так "расшифровал". Хотя насчет удобства - вопрос привычки
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 01.08.2021, 23:31   #19  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
В дотнете tryxxx


✔️ CONSIDER the Try-Parse Pattern for members that might throw exceptions in common scenarios to avoid performance problems related to exceptions.

✔️ DO use the prefix "Try" and Boolean return type for methods implementing this pattern.

✔️ DO provide an exception-throwing member for each member using the Try-Parse Pattern.
За это сообщение автора поблагодарили: mazzy (2).
Старый 02.08.2021, 09:58   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Пример с validateWrite + Write явно надуманный.
Да ну?!
т.е. runbase с эго validate и run - "это другое"

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Поскольку в данной теме речь идет именно о создании методов, то и получим дублирование кода
ну... блин... тут явная проблема с логикой.
создание методов вовсе НЕ приводит к дублированию кода.


Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Это просто счастье, если параметр добавляют. Обычно именно тупо дубликат делают
это проблема конкретной команды и ее конкретного team-лидера.
это НЕ проблема самого CodeStyle.

Насчет параметра.
Правильно говоришь - скорее всего параметров будет много.
вызовов метода с параметрами будет много.
т.е. вот таких конструкций будет дофига:
X++:
myObj.myMethod(voucher, inventLocationId, true, inventColorId, false, params);
и как понять этот метод выкинет исключение или нет?
и как понять допустимо ли здесь игнрорировать результат?

поэтому код будет усеян уродливыми конструкциями вида
X++:
if( myObj.myMethod(voucher, inventLocationId, true, inventColorId, false, params) )
{
    throw Error::Error
}
а можно было бы одной строкой
X++:
myObj.myMethodOrThrow(voucher, inventLocationId, true, inventColorId, params);

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Сама постановка вопроса не корректная.
какая постановка?
этого вопроса "Какой вариант вы бы предпочли? И почему?"?
как может быть такая постановка некорректной?

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Как правило, подобные методы редко продумываются на этапе создания архитектуры проекта. Они возникают "естественным путем" по мере возникновения в них необходимости. Соответственно и варианты реализации также возникают "по месту". Вот что в данном случае покажется более уместным, то и делают
генезис понятен. согласен, что именно так и происходит.
но это не повод не задавать вопросы
и это не повод не выполнять рефакторинг.
не так ли?
__________________
полезное на axForum, github, vk, coub.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
bojensen: Optional filter in SSRS | Musings by Generator Blog bot DAX Blogs 0 08.09.2014 11:11
emeadaxsupport: Manufacturing Execution in AX 2012: Issue with the "Lock employee"-parameter Blog bot DAX Blogs 0 19.09.2013 18:11
emeadaxsupport: "Parameter is missing a value" error running a customized report in Microsoft Dynamics AX 2012 Blog bot DAX Blogs 0 21.11.2012 00:12
mfp: Optional parameters in C# and X++ Blog bot DAX Blogs 0 30.01.2010 00:05
Developer notes: Null value for ADO command parameter Blog bot DAX Blogs 0 03.05.2008 08:16
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 19:21.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.