Длина строки исходного кода в 2012 R3

[Logger]

Привет всем.

Вопрос
Какая в 2012-й аксапте возможна максимальная длина строки исходного кода ?
И ограничена ли она вообще ?

В ax4 - максимальная длина 250 символов.
Видимо поэтому в EDT SourceLine поставлена длина 250.

Но в 2012-й это приводит к проблемам при использовании автоматической смены регистра в исходном коде. Класс SysSourceNameWash не трогает методы, в которых есть строки длиной больше чем 250 символов.

Поднял длину EDT SourceLine до 1000 - все стало хорошо.

Но пока непонятно, какие риски это влечет.
Влияет ли это еще на что и какая же в 2012-й допустима длина строки исходного текста.

[Logger]

Исправление этой и ряда других проблем.

[Logger]

Что же там все такое глючное то
Макросы тоже не умеет обрабатывать.

Выложил еще фиксов.

[Logger]

Подправил еще обработку форм и ускорил их обработку.

[Logger]

по правилам оформления исходных текстов X++ зарезервированные слова должны быть в нижнем регистре, но среда разработки в 2012-й
сама подставляет их в том регистре как определено в ветке \System Documentation\Reserved Words
(а там могут быть большие символы, например ttsBegin и ttsCommit
это приводило к парадоксам - редактор подставлял значения несоответствующие правилам, а потом этот класс их заменял на текст в нижнем регистре
чтобы поддерживать единый стиль написания, пришлось бы постоянно запускать этот класс для исправления, поэтому проще оказалось исправить класс чтобы
он вел себя как редактор кода, подставлял значения из ветки \System Documentation\Reserved Words

[mazzy]

а чем отличается файл USRonly от второго файла?
вернее, зачем 2 xpo-файла?

[Logger]

Цитата:

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

а чем отличается файл USRonly от второго файла?
вернее, зачем 2 xpo-файла?

2-й файл - выгружен весь проект целиком.
USRonly - выгружен только usr слой. - Кому-то возможно удобнее будет себе merge делать.

[mazzy]

Цитата:

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

2-й файл - выгружен весь проект целиком.
USRonly - выгружен только usr слой. - Кому-то возможно удобнее будет себе merge делать.

merge? с объектами, которые имеют "чужой" суффикс _MRC?! Оптимист

ага. понял. спасибо.

я так понимаю, что ты пытаешься улучшить стандартный класс Class_SysSourceNameWash, чтобы он чего-то умное делал. Но при этом по-прежнему используешь опасный strdel и безумный strpoke...

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

а может ты форматтер кода делаешь?
prettier, только для Аксапты? Давно хочется

[Logger]

Цитата:

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

merge? с объектами, которые имеют суффикс _MRC?! Оптимист

Имелись в виду классы
SysSourceNameWash
SysSourceUpdate

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

Цитата:

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

я так понимаю, что ты пытаешься улучшить стандартный класс Class_SysSourceNameWash, чтобы он чего-то умное делал.

Не только. У нас на проекте есть много Legacy кода, который написан без соблюдения требований по регистру символов. Компилятору все равно - он регистронезависимый. Но выглядит некрасиво. Я попробовал применить этот стандартный инструмент, чтобы выправить ситуацию в старом коде, чтобы не резало глаз.

Попутно выяснилось что инструмент содержит немного багов:

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

2. Ошибочно преобразует ссылки в коде на имена полей таблиц у которых в начале более 2 заглавных символов (например someTable.ISOcode испохабил - привел к нижнему региструsomeTable.isOcode, хотя не надо было трогать, т.е. не везде корректно учитывал область применения - преобразовывал первые символы к нижнему регистру там где не надо)

3. Финальное сохранение было сделано через методы xUtilElements:: которые обращались к тормозной вьюхе UtilElements (по 1 секунде на запрос) что при массовой обработке думало по полдня.

4. Кажется (точно уже не помню) некорректно обрабатывались методы на формах (лукапы, методы датасорсов итп) - (вроде бы они то ли вообще не обрабатывались то ли ссылки на них не обрабатывались)

5. Правильно обрабатывались стандартные зарезервированные слова, для которых в ветке \System Documentation\Reserved Words
почему-то были заданы большие буквы в camel стиле (ttsBegin ttsCommit ttsAbort forUpdate итп) - преобразовывались в нижний регистр, но сам редактор при вводе подставлял их неверно - как в AOT. Редактор исправить невозможно, пришлось править класс, чтобы было безобразно, но единообразно.

6. Из-за баги некорректно шла обработка методов содержащих макросы, так что исходный код всего метода оставался неизменным.

7. Не умеет корректно обрабатывать макросы. - Не меняет их содержимое.

и фич:

8. Обрабатывает все подряд, вместо конкретного слоя. (я не хотел править стандартный код, только то что на usr мы сами наваяли)

9. Запускать его надо 2 раза подряд (при 1-м запуске изменяет имена методов и переменных, при втором ссылки на методы)

пп 1-6 исправил.
п. 7 непонятно как исправлять, но это некритично.

п.8 исправил.
п.9 - просто надо учитывать и запускать обработку дважды.

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

Цитата:

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

...Но при этом по-прежнему используешь опасный strdel и безумный strpoke...

Это не я. Это в инструменте так написано. Я там чего-то своего почти не добавлял. - Исправил баги и все.

Цитата:

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

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

а может ты форматтер кода делаешь?

форматтер кода не делаю.
Просто в Legacy коде была свистопляска.
методы то с большой то с маленькой буквы написаны. Имена переменных то с большой то с маленькой. Имена типов / классов / таблиц / полей таблиц в таком же стиле, т.е. отсутствии стиля. Где в лес где по дрова.

Ну, а этот инструмент это все исправляет в соответствие со стандартом. Имена самих узлов в АОТ кроме имен методов он не трогает. Только исходный код правит.

Из полезного - читаемость код улучшилась.

[Logger]

Цитата:

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

prettier, только для Аксапты? Давно хочется

На такое я не замахивался.
Не до того.
Работу работать надо.

Стандартный аксаптовский преобразователь неплохо улучшает внешний вид и читаемость кода.

[mazzy]

Цитата:

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

пп 1-6 исправил.
п. 7 непонятно как исправлять, но это некритично.

п.8 исправил.
п.9 - просто надо учитывать и запускать обработку дважды.

а... понятно.

Цитата:

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

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

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

Цитата:

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

форматтер кода не делаю.

жаль. очень жаль.

Цитата:

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

Просто в Legacy коде была свистопляска.
методы то с большой то с маленькой буквы написаны. Имена переменных то с большой то с маленькой. Имена типов / классов / таблиц / полей таблиц в таком же стиле, т.е. отсутствии стиля. Где в лес где по дрова.

ну да, ну да. точку с запятой после объявления не ставят, параметры метода на новую строку не переводят, фигурные скобки после if пропускают, пробелы ставят после скобок, а не до...
Безобразие.
Может все-же форматер?

Цитата:

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

Ну, а этот инструмент это все исправляет в соответствие со стандартом.

всё?!

Цитата:

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

Имена самих узлов в АОТ кроме имен методов он не трогает. Только исходный код правит.

Я не про имена узлов в AOT, а значения в свойствах объектов - название типа, название menuItem, используемая таблица и т.п.

Цитата:

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

Из полезного - читаемость код улучшилась.
...
Стандартный аксаптовский преобразователь неплохо улучшает внешний вид и читаемость кода.

и это - хорошо!

[Logger]

Цитата:

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

Я не про имена узлов в AOT, а значения в свойствах объектов - название типа, название menuItem, используемая таблица и т.п.

Не делает.
Можно дописать, но я не стал. Мне кажется, что это некритично. Главное в исходном коде поправить. Именно исходники читаем бОльшую часть времени.

[Logger]

Цитата:

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

всё?!

Ну, не вообще все, а перечисленное, то что относится к регистру символов. Он же даже в меню назван "Смена регистра в исходном коде". Так что все честно, без обмана.

[Logger]

Цитата:

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

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

Вообще с регистронезависимостью беда.
У многих программистов проявляется инерция мышления и они пытаются с регистронезависимым языком обращаться как с регистрозависимым.

Например, знаменитый инструмент
JAEE.AX.EditorExtensions.HighlightWord
написан как будто X++ это регистрозависимый язык!

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

Я не поленился, нагуглил все форки этого инструмента.
Ни в одном нет регистронезависимого сравнения.
Editor extensions и регистр символов

Написал одному из авторов с просьбой поменять, так он в ответ сказал что не видит проблемы, надо, мол, просто исходный текст в аксапте поменять и все ок, т.е. проявил инерцию мышления, по привычке пытается работать с X++ как с регистрозависимым языком.
https://github.com/jaestevan/AX2012-...sions/issues/1

В итоге, сам перекомпилял dll-ку чтобы регистр не учитывался.
https://axforum.info/forums/attachme...7&d=1557923693

Спасибо Martin Dráb за подсказки по исправлению.

[mazzy]

Цитата:

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

Например, знаменитый инструмент
JAEE.AX.EditorExtensions.HighlightWord
написан как будто X++ это регистрозависимый язык!

А... ты выделение одинаковых слов в редакторе пытаешься заставить работать...
Понятно. Дело хорошее.

[Logger]

Цитата:

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

А... ты выделение одинаковых слов в редакторе пытаешься заставить работать...
Понятно. Дело хорошее.

Не, это я уже победил раньше тем, что пересобрал dll-ку, отключив регистрозависимость сравнения.

Я улучшаю читаемость кода.
Реально удобнее стало.
И приятнее для восприятия.

[Logger]

Вылезло еще пара багов.

п.10 Если объявлена переменная или параметр с типом anytype, то, если имя переменной совпадает с существующим в системе типом (EDT, etc) то обработка изменяет все обращения на заглавную букву.
Например если объявить

anyType    num;
anyType    salesId;

то везде в коде обращения к ним будут сделаны как Num и SalesId

этот баг исправлен.

п.11 Все обращения к стандартным именам классов (classFactory, versionControl) теперь исправлены на camel-style, чтобы работа IDE и обработки приводило к одному результату.

[mazzy]

А можно попросить тебя сделать 3 вещи:

1. убрать безумные суффиксы '_MRC'. С ними проект бесполезен - в здравом уме мало кто будет использовать объекты с суффиксами с чужого проекта. ничего, кроме расчёсывания ЧСВ автора, эти суффиксы не дают.
2. все-таки переделать эти strpoke, strdel на нормальный StringBuilder или TextBuffer.
3. опубликовать проект в gitHub - там гораздо удобнее следить за изменениями и предлагать правки в проект. Причем на gitHub предлагаю выложить и машинно-читаемый xpo, и человеком-читаемые xpp. xpp-файлы генерируются автоматически из xpo скриптом на powerShell. приложил образец (обязательно замени ссылки и автора). выглядит примерно так https://github.com/mazzy-ax/SysStopwatch

Да, главное - опубликуй на github под своим именем, чтобы авторство осталось за тобой. Дальше мы сможем форкать, предлагать изменения, творить историю и т.п. Но первый вариант будет твоим. Примерно вот так:

[Logger]

Цитата:

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

1. все-таки переделать эти strpoke, strdel на нормальный StringBuilder или TextBuffer.

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

Кстати, по опыту использования 2009-й - TextBuffer работает намного быстрее. Видимо из-за накладных расходов на маршаллинг в случае с StringBuilder

Цитата:

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

Да, главное - опубликуй на github под своим именем, чтобы авторство осталось за тобой. Дальше мы сможем форкать, предлагать изменения, творить историю и т.п. Но первый вариант будет твоим. Примерно вот так:

Попробую.

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

Кстати, по опыту использования 2009-й - TextBuffer работает намного быстрее. Видимо из-за накладных расходов на маршаллинг в случае с StringBuilder

тут дело такое...
X++ исполняется в X++ быстрее, чем .net
X++ исполняется в CLR медленне, чем .net

для 2009 второго варианта нет
для 2012 может быть оба варианта.
для ax7+ только второй вариант.

Цитата:

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

Чем тебя так напрягают постфиксы ?

мне они читать чужой код мешают.
особенно, если в нашем проекте в одном методе встречаются суффиксы _MER и _MRC у идентификаторов на 30-40 букв - вынос мозга гарантирован. Считаю, что ничего хорошего суффиксы в код не привносят, кроме почёсывания ЧСВ автора. Другим читателям суффиксы только затуманивают смысл происходящего. Хуже только префиксы с логином автора кода.

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

Цитата:

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

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

Ты выкладываешь проект. В котором используются суффиксы какого-то левого для людей проекта.

Во-первых, у людей могут быть свои правила наименования. Свои запреты. Свои правила определения ответственного по суффиксу. Так же как и _MRC тоже был важен когда-то.

Во-вторых, это как грязное нижнее белье выставлять - фу-фу. ну или как strPoke использовать. Публично то зачем?