Удобство чтения кода - залог и определенная гарантия его работоспособности

[sukhanchik]

Сообщения выделены из темы добавить поле в dialog класса //oip

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

А между прочим - удобство чтения кода - залог и определенная гарантия его работоспособности.

[oip]

Цитата:

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

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

А между прочим - удобство чтения кода - залог и определенная гарантия его работоспособности.

Ага, я когда-то давно сопровождал вот примерно такой код (все на макросах, 1000+строк в методе) Получил много незабываемого удовольствия при модификации и отладке.

...
    #localmacro.attrFilter
        %1
    #endMacro
...
   #localmacro.table
        tableMapping=new IntegrTableMapping_Master(tableNum(#tableName), '%1');
        ret.add(tableMapping,'%2');
    #endmacro

    #localmacro.field
        tableMapping.add(
            new IntegrFieldMapping(
                #attrFilter(IntegrTableFieldAttribute::construct(
                    tableNum(#tableName), fieldNum(#tableName, %1)
                ))
            )
        );
    #endmacro

    #localmacro.GUIDField
        tableMapping.add(
            new IntegrFieldMapping_Guid(
                #attrFilter(IntegrTableFieldAttribute::construct(
                    tableNum(#tableName), fieldNum(#tableName, %1)
                ))
                , tableNum(%2), fieldNum(%2, %3) #ifnot.empty(%4), %4 #endif
            )
        );
    #endmacro
// ...
// еще десяток подобных макросов на все случаи жизни, но зато дальше весь код был "простой и удобный" :)
// ...
    #define.tableName(InventJournalTable)

    #table(inventJournalTable)
    #field(GUID)
    #field(journalId)
    #field(JournalType)
    #field(JournalNameId)
    #field(JournalDate)
    #GUIDField(fromInventLocation, InventLocation, inventLocationID)
    #GUIDField(toInventLocation,  InventLocation, inventLocationID)
    #method(department)
//...

P.S. Кстати, автор кода - действительно ОЧЕНЬ сильный программист. Прошу его на меня не обижаться.

[belugin]

Цитата:

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

Кстати, автор кода - действительно ОЧЕНЬ сильный программист. Прошу его на меня не обижаться.

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

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

В следующий раз подумаю о кодогенерации с сохранением результата в виде исходников.

[sukhanchik]

Цитата:

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

но зато код было легко модифицировать.

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

Кто против использования макросов? Я против? Я только за - но при этом за принцип - "пусть безобразно, но единообразно". Пусть автоматизация написания кода будет заключаться в том, что после написания макросов - работает лексер на Х++. Но после чтения кода - у нового специалиста (который может быть совсем не новым, но просто "свежепришедшем") будет возможность читать привычный код, написанный боле-менее едином стиле. И отладчик будет стоять на строке кода, какая бы она не была, а не понятно на чем в случае макроса (согласен на допилку отладчика )

[belugin]

Цитата:

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

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

Любой код несет в себе что-то новое, вопрос в том, насколько долго принимать это новое. В описанном случае макросы маленькие а классы большие. Почему изучить малеьнике макросы эта проблема, а большие классы - нет?

[sukhanchik]

Цитата:

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

Почему изучить малеьнике макросы эта проблема, а большие классы - нет?

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

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

Опять-таки - вопрос отладки. В тех случаях - когда замена макросом усложняет процесс отладки (=проверки орфографии) - очень сложно отлаживать

[lev]

При всем моем уважении, сам факт наличия метода с 1000+ строк - это уже "удовольствие для прочтения"....

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

[oip]

Цитата:

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

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

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

Ты красиво макросами запрограммировал механизм интеграции. Добавить новую таблицу в механизм - да, просто и удобно. А вот поменять при необходимости сам "движок"... Я видел, как каждый новый разработчик на проекте тратил время чтобы понять, что тут и как работает. Брейкпоинты и перекрестные ссылки - тоже были проблемой. И точно помню, что после того, как алгоритм интеграции немного поменялся, модифицировать его было совсем не хорошо. Не, я конечно допускаю, что мне тогда просто квалификации не хватало (а это было 6+ лет назад), чтобы быстро разобраться, но мне и сейчас не нравится разбираться в способе написания кода, а не в самом коде. Я хочу чтобы код в системе был по возможности написан в едином стиле.

lev, 1000+ строк - это по большей части перечисление таблиц и полей для выгрузки.

P.S. Наверное зря я все это начал. Максим, извини.

[belugin]

Цитата:

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

Ты красиво макросами запрограммировал механизм интеграции.

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

Цитата:

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

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

Тут хотелось бы примера, если помнишь. По идее перерестные ссылки должны работать.

Цитата:

И точно помню, что после того, как алгоритм интеграции немного поменялся, модифицировать его было совсем не хорошо.

Цитата:

Было ли это из за макросов или из-за классов?
Какое изменение и почему не влезло?

Не, я конечно допускаю, что мне тогда просто квалификации не хватало (а это было 5+ лет назад), чтобы быстро разобраться, но мне и сейчас не нравится разбираться в способе написания кода, а не в самом коде.

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

[oip]

Цитата:

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

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

Если не лезть в детали, то да, только маппинг.

Цитата:

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

Тут хотелось бы примера, если помнишь. По идее перекрестные ссылки должны работать.

Уже не помню. Очень уж давно это было.

Цитата:

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

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

Нет, способ написания кода - это нечто другое. В теме "Вернуть this из класса" это как раз и обсуждалось. Мне по-прежнему кажется, что задача была проще, чем выбранный способ реализации. Но может и правда рано мне тогда было твой код читать.

Может ну его, это обсуждение? А то о чем речь до конца понимаем только мы с тобой. Я уже сто раз пожалел, что начал.

[belugin]

>>>если код "мутный", а модифицировать его нужно, то код такой трут

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

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

[driller]

По поводу поиска отличия в исходниках, пробовали Araxis Merge?
Если да, то чем он не устроил?

[belugin]

Цитата:

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

По поводу поиска отличия в исходниках, пробовали Araxis Merge?
Если да, то чем он не устроил?

Еще http://winmerge.org/

Ну я имел ввиду чтобы вместо

- создать два файла
- добавить туда два уска кода
- вызвать мёрож

просто выделить два куска и вызвать пункт меню

[imir]

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

[pitersky]

Цитата:

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

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

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

[RVS]

Пять копеек:

- налицо уход от темы, КМК. Макросы - это, конечно, здорово, "принцип разумной достаточности" при их применении - безусловно, должен соблюдаться. И InventDimJoin и код, построенный целиком на макросах, приведенный выше, безусловно, все же разные вещи , но речь изначально была не о том.
- "Программы пишутся для людей" (откуда? ). В этом смысле код, написанный "в стиле системы", безусловно, предпочтителен. Как в армии - "безобразно, но единообразно". Иначе (в пределе) получается вариант бессмертных "лебедя, рака и щуки".
- В принципе, все уже сказано в заголовке темы. Думаю, мало кому захочется это оспаривать, и еще меньше тех, у кого это получится.

[imir]

Цитата:

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

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

Его легко переделать на query, динамически собираемый в коде, просто кто-то один раз связался с этой конструкцией и тащится она с 2.5-й версии

[pitersky]

Цитата:

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

Его легко переделать на query, динамически собираемый в коде, просто кто-то один раз связался с этой конструкцией и тащится она с 2.5-й версии

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

[Zabr]

Цитата:

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

мне лично #InventDimJoin читать намного удобнее, чем многоэтажный прямой джойн инвентдима.

Если в этом запросе должна была быть другая табличная переменная для InventDim, а InventDim тоже есть но используется в другом месте, а кто-то по привычке зафигачил в запрос #InventDimJoin, то результат представить не трудно. Причем замучаетесь искать, в чем проблема. Так что макросы лучше только для констант использовать.

[ice]

Цитата:

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

Если в этом запросе должна была быть другая табличная переменная для InventDim, а InventDim тоже есть но используется в другом месте, а кто-то по привычке зафигачил в запрос #InventDimJoin, то результат представить не трудно. Причем замучаетесь искать, в чем проблема. Так что макросы лучше только для констант использовать.

вообще-то в макрос передаются имена переменных