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

[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+ строк - это уже "удовольствие для прочтения"....

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

[sukhanchik]

Цитата:

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

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

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

Помнится на одном проекте один программист (не буду его называть) все цвета делал не в виде набора макросов (хотя это вообще константы) - а в виде специального класса со статическими методами. Очень удобно было при разработке было выбирать из списка.

[lev]

Цитата:

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

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

Помнится на одном проекте один программист (не буду его называть) все цвета делал не в виде набора макросов (хотя это вообще константы) - а в виде специального класса со статическими методами. Очень удобно было при разработке было выбирать из списка.

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

З.Ы. какой то оффтоп уже для данной темы, сорри

[oip]

Цитата:

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

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

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

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

Цитата:

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

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

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

[oip]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

С моей точки зрения, выиграем, потому, что штука простая и жкономит время после изучения.

Цитата:

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

Простота понятие относительное. Для меня простота, это когда категории каторыми я см, кстати Mappers VS Packers) [/URL] на код.
Ну мне и самому интересно, что из этого всего вылилось. И были ли проблемы именно в макросах.

Цитата:

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

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

[EVGL]

Цитата:

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

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

Да нет, просто покайтесь, посыпьте голову пеплом, и все отстанут.