|
19.01.2021, 14:30 | #1 |
Участник
|
Длина строки исходного кода в 2012 R3
Привет всем.
Вопрос Какая в 2012-й аксапте возможна максимальная длина строки исходного кода ? И ограничена ли она вообще ? В ax4 - максимальная длина 250 символов. Видимо поэтому в EDT SourceLine поставлена длина 250. Но в 2012-й это приводит к проблемам при использовании автоматической смены регистра в исходном коде. Класс SysSourceNameWash не трогает методы, в которых есть строки длиной больше чем 250 символов. Поднял длину EDT SourceLine до 1000 - все стало хорошо. Но пока непонятно, какие риски это влечет. Влияет ли это еще на что и какая же в 2012-й допустима длина строки исходного текста. |
|
19.01.2021, 14:34 | #2 |
Участник
|
Исправление этой и ряда других проблем.
|
|
19.01.2021, 17:09 | #3 |
Участник
|
Что же там все такое глючное то
Макросы тоже не умеет обрабатывать. Выложил еще фиксов. |
|
22.01.2021, 14:43 | #4 |
Участник
|
Подправил еще обработку форм и ускорил их обработку.
|
|
04.03.2021, 11:09 | #5 |
Участник
|
по правилам оформления исходных текстов X++ зарезервированные слова должны быть в нижнем регистре, но среда разработки в 2012-й
сама подставляет их в том регистре как определено в ветке \System Documentation\Reserved Words (а там могут быть большие символы, например ttsBegin и ttsCommit это приводило к парадоксам - редактор подставлял значения несоответствующие правилам, а потом этот класс их заменял на текст в нижнем регистре чтобы поддерживать единый стиль написания, пришлось бы постоянно запускать этот класс для исправления, поэтому проще оказалось исправить класс чтобы он вел себя как редактор кода, подставлял значения из ветки \System Documentation\Reserved Words Последний раз редактировалось Logger; 04.03.2021 в 11:20. |
|
|
За это сообщение автора поблагодарили: mazzy (10). |
04.03.2021, 12:56 | #6 |
Участник
|
а чем отличается файл USRonly от второго файла?
вернее, зачем 2 xpo-файла? |
|
04.03.2021, 13:09 | #7 |
Участник
|
|
|
04.03.2021, 13:24 | #8 |
Участник
|
Цитата:
ага. понял. спасибо. я так понимаю, что ты пытаешься улучшить стандартный класс Class_SysSourceNameWash, чтобы он чего-то умное делал. Но при этом по-прежнему используешь опасный strdel и безумный strpoke... судя по названию проекта, меняешь регистр букв в объектах. а зачем? и почему только в методах? есть ли замена и в свойствах? а главное, зачем? а может ты форматтер кода делаешь? prettier, только для Аксапты? Давно хочется Последний раз редактировалось mazzy; 04.03.2021 в 13:31. |
|
04.03.2021, 14:07 | #9 |
Участник
|
Имелись в виду классы
SysSourceNameWash SysSourceUpdate там стандартный код правил. Возможно у кого-то есть свои правки или версия отличается. Цитата:
Попутно выяснилось что инструмент содержит немного багов: 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 - просто надо учитывать и запускать обработку дважды. В целом код обработки писал параноик, перед внесением изменений делается сравнение без учета регистра - отличается ли исходный код до изменений и после и если отличается, то изменения не вносятся. Так что запускать можно безопасно - сломать ничего не должен. Цитата:
Цитата:
Просто в Legacy коде была свистопляска. методы то с большой то с маленькой буквы написаны. Имена переменных то с большой то с маленькой. Имена типов / классов / таблиц / полей таблиц в таком же стиле, т.е. отсутствии стиля. Где в лес где по дрова. Ну, а этот инструмент это все исправляет в соответствие со стандартом. Имена самих узлов в АОТ кроме имен методов он не трогает. Только исходный код правит. Из полезного - читаемость код улучшилась. Последний раз редактировалось Logger; 04.03.2021 в 14:11. |
|
04.03.2021, 14:18 | #10 |
Участник
|
Цитата:
Сообщение от mazzy
prettier, только для Аксапты? Давно хочется
Не до того. Работу работать надо. Стандартный аксаптовский преобразователь неплохо улучшает внешний вид и читаемость кода. |
|
04.03.2021, 14:41 | #11 |
Участник
|
Цитата:
Цитата:
Сообщение от Logger
В целом код обработки писал параноик, перед внесением изменений делается сравнение без учета регистра - отличается ли исходный код до изменений и после и если отличается, то изменения не вносятся. Так что запускать можно безопасно - сломать ничего не должен.
... Это не я. Это в инструменте так написано. Я там чего-то своего почти не добавлял. по-моему Wash делал не параноик, а тот, кто ни аксапту, ни джаву не знает. по-моему ощущению, какой-то человек с регистрозависимого языка жаль. очень жаль. Цитата:
Безобразие. Может все-же форматер? всё?! Цитата:
и это - хорошо! |
|
19.04.2021, 15:47 | #12 |
Участник
|
Вылезло еще пара багов.
п.10 Если объявлена переменная или параметр с типом anytype, то, если имя переменной совпадает с существующим в системе типом (EDT, etc) то обработка изменяет все обращения на заглавную букву. Например если объявить X++: anyType num; anyType salesId; этот баг исправлен. п.11 Все обращения к стандартным именам классов (classFactory, versionControl) теперь исправлены на camel-style, чтобы работа IDE и обработки приводило к одному результату. |
|
|
За это сообщение автора поблагодарили: mazzy (5), sukhanchik (6). |
19.04.2021, 18:23 | #13 |
Участник
|
А можно попросить тебя сделать 3 вещи:
Да, главное - опубликуй на github под своим именем, чтобы авторство осталось за тобой. Дальше мы сможем форкать, предлагать изменения, творить историю и т.п. Но первый вариант будет твоим. Примерно вот так: Последний раз редактировалось mazzy; 19.04.2021 в 18:27. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
19.04.2021, 19:14 | #14 |
Участник
|
Цитата:
Потом нашел еще багов... И еще... И лучше вник в код и все стало понятно. Теперь можно и переписать, но... Пока не нашел на это время. Кстати, по опыту использования 2009-й - TextBuffer работает намного быстрее. Видимо из-за накладных расходов на маршаллинг в случае с StringBuilder Цитата:
Чем тебя так напрягают постфиксы ? Если на проекте смешивается разный код (из разных источников), то возможны пересечения в именах. Постфиксы это как бы замена отсутствующим пространствам имен в аксапте. |
|
19.04.2021, 19:41 | #15 |
Участник
|
Цитата:
Сообщение от Logger
Я на такое не замахивался. Изначально, думал, что подправлю пару найденных багов и все (переписывать я его не планировал). Поскольку суть алгоритма с первого раза была не вполне ясна, решил ограничиваться минимумом вмешательств со своей стороны.
Потом нашел еще багов... И еще... И лучше вник в код и все стало понятно. Теперь можно и переписать, но... Пока не нашел на это время. Цитата:
X++ исполняется в X++ быстрее, чем .net X++ исполняется в CLR медленне, чем .net для 2009 второго варианта нет для 2012 может быть оба варианта. для ax7+ только второй вариант. мне они читать чужой код мешают. особенно, если в нашем проекте в одном методе встречаются суффиксы _MER и _MRC у идентификаторов на 30-40 букв - вынос мозга гарантирован. Считаю, что ничего хорошего суффиксы в код не привносят, кроме почёсывания ЧСВ автора. Другим читателям суффиксы только затуманивают смысл происходящего. Хуже только префиксы с логином автора кода. Но в данной ветке речь то не обо мне, а о всех читателях кода, который ты делаешь публичным. Цитата:
Во-первых, у людей могут быть свои правила наименования. Свои запреты. Свои правила определения ответственного по суффиксу. Так же как и _MRC тоже был важен когда-то. Во-вторых, это как грязное нижнее белье выставлять - фу-фу. ну или как strPoke использовать. Публично то зачем? Последний раз редактировалось mazzy; 19.04.2021 в 19:52. |
|
19.04.2021, 19:55 | #16 |
Участник
|
Я еще погоняю этот код и сделаю как ты рекомендовал.
Надо убедиться что не вылезет что-нибудь еще. Но по всем признакам все уже хорошо. Последний раз редактировалось Logger; 19.04.2021 в 20:21. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
03.06.2021, 13:37 | #17 |
Участник
|
1. Подправил оформление кода (убраны постфиксы в именах)
2. Добавил изменение подстрок X++: " if(" " for(" " while(" " switch(" " catch(" т.е. в коде становится так X++: " if (" " for (" " while (" " switch (" " catch (" Последний раз редактировалось Logger; 03.06.2021 в 13:40. |
|
|
За это сообщение автора поблагодарили: mazzy (15), sukhanchik (15), dech (10). |
02.06.2022, 13:10 | #18 |
Участник
|
Похоже не все.
Следующая версия: 1. Добавлена обработка форм. а. Если контрол назван по схеме ИмяДатасорса_ИмяПоля (а именно так среда и дает название когда drag/drop-ишь поля датасорса) то исправляет регистр в имени, Например sAlesTablE_saleSid --> SalesTable_SalesId б. В коде форм исправляет имена датасорсов и таблиц датасорсов а также их поля(раньше не понимал ссылки на датасорс и не исправлял. Понимал только таблички объявленные явно как локальные переменные). Например sAlesTablE --> salesTable sAlesTablE_DS --> salesTable_ds sAlesTablE.saleSid --> salesTable.SalesId в. В коде форм исправляет имена Autodeclarated контролов. Например sAlesTablE_saleSid --> salesTable_SalesId |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
Теги |
sourceline |
|
|