mfp: What's up with this semicolon?

[oip]

Цитата:

Сообщение от Blog bot

This change will not make it into AX 2009; but I'm confident those of us writing X++ code at Microsoft will enjoy this very soon. The rest of you will have to wait for AX6.0.

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

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

[somebody]

Лишь бы "висячая" точка с запятой не вызывала ошибки, это действительно удобно (и привычно) для разделения объявлений и кода.

P. S. Более умный компилятор == более медленный??

[gl00mie]

Цитата:

Сообщение от Blog bot

The most visual idiosyncrasy in X++ is the dangling semicolon separating the variable declarations from the actual code. If it was made a priority to get rid of dangling semicolons, what could be done?

1. X++ could be made case sensitive. This would likely break all customizations and solutions available; unless it is accompanied with a code "beautifier".
2. The compiler could be made more intelligent by looking one more token ahead before giving up. The compiler should be able to do so too. I guess the developer solving this issue would kudos in AX-land.

Уж не этим ли прельстило Понтоппидана решение "сделать компилятор более умным"?
А по мне так лучше было бы сделать X++ регистрозависимым как та же Java, которая вроде как вдохновила некогда праотцов из Дамгаарда.

Цитата:

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

Ой! По-моему, точка с запятой меньшее зло

Это еще почему? С точки зрения поддержки старого кода, косячно-корявого в плане регистрозависимости и соблюдения Best Practices? Дык, натравить на него один раз beautifier, а потом - руки отрубать (образно говоря, т.е. компилить код с ошибками) неряшливым кодерам, пришедшим из бейсика, которым по барабану и Best Practices, и рЕгисТР БУкв
Собственно, Понтоппидан лукавит, говоря об автоматическом "причесывателе" кода как о неком мифическом существе. Смотрим в Best Practices (давнишний, еще от 3-шки), раздел «X++ layout», подраздел «Upper/lower case»:

Цитата:

• System functions are treated like other methods (initial lowercase). Intermediate words may start with uppercase.
• true, false, null are all lowercase.
• Basic types are all lowercase, for example: str, date, int, real, void, boolean.
• Reserved word are all lowercase (for example see the System Documentation>Reserved Words list). Intermediate words may start with uppercase. Example: if, while, for, select, ttsCommit.

Не знаю, как на счет «intermediate words may start with uppercase», но в самом ядре все системные функции и ключевые слова прописаны сугубо в нижнем регистре - любой желающий может в этом убедиться. А теперь смотрим в стандартное приложение DAX4, сравниваем с AX3 и ищем десять различий (в тех местах, где код не менялся из-за введения нового функционала, всяких Code Access Security и проч.): сразу видно, что код "причесали": привели все ключевые слова и системные функции к нижнему регистру, привели упоминания элементов перечислений к тому виду, в каком они представлены в AOT, etc (я уже как-то писал об этом). Т.е. явно видно, что код приложения 4-ки прошерстили неким инструментом, зачатки которого уже давно живут в самом приложении, см. Add-ins\Смена регистра в исходном коде (класс SysSourceNameWash).
Так что в плане перевода Х++ в регистрозависимые языки нужна по большому счету лишь политическая воля - вместо желания "прославиться в AX-сообществе".

Цитата:

Сообщение от Blog bot

This morning I have created a package with my findings and sent it to the X++ team for evaluation. This change will not make it into AX 2009; but I'm confident those of us writing X++ code at Microsoft will enjoy this very soon. The rest of you will have to wait for AX6.0.

И эти люди еще хотят скрестить DAX с VS и .Net'ом...

Цитата:

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

Более умный компилятор == более медленный??

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

Цитата:

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

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

А по мне - лучше бы докрутили среду разработки до уровня VS, где редактор понимает, где тип, а где переменная типа, и подсвечивает их по-разному. Тогда и "костыли" в виде висячей точки с запятой не понадобятся...

[Михаил Андреев]

Цитата:

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

А по мне - лучше бы докрутили среду разработки до уровня VS, где редактор понимает, где тип, а где переменная типа, и подсвечивает их по-разному.

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