MSElang : обсуждение фишек

[alexey38]

которая без скобок :не компилируется.

Зачем что-то менять, если компилятор и так не давал сделать неоднозначность?

Да это понятно, что любые претензии к неоднозначности - надуманы. Называется "учи нюансы и переливы, делай зарубки, закрепляй ежесекундной практикой практикой"

Мне кажется, что Вы и другие наши коллеги путаете понятие неоднозначности и понятие формализма.

Во всех приведенных Вами примерах из Оберона вообще не было ни одной неоднозначности, т.к. неоднозначность - это не вариации написания одного и того же. Неоднозначность - это когда одинаковый или похожий код работает совсем не так, как кажется на первый взгляд. Наличие или отсутствие символа ";" ни как не влияет на неоднозначность. А вот пример из С/С++, когда компилятор дает скомпилировать конструкцию типа if(i=0) - это и есть пример неоднозначности.

В тоже время Вы пытаетесь нам навязать формализм в написании кода, мол нужно переписать все существующие формальные правила, и заставить всех ставить или удалять символы ";", и прочие. Это все бред и лишнее. Формализм - это зло. Ничего полезного в нем нет. Вы занимаетесь надуманными проблемами про удобность и эстетичность.

В отличие от Вас, Мартин предлагая после if ... then обязательно требовать END - как раз ликвидирует неоднозначность, т.к. некоторые пишут несколько операторов, выполнив отступы (форматирование текста), но забыв указать begin/end.

[debi12345]

then обязательно требовать END

Это значит что в циклах и ветвлениях больше _нельзя_ будет использовать выражения без ";" в конце. И по ходу, так как теперь имеем как бы всегда "тело" из нескольких выражений - отпадает необходимость в BEGIN (как в отличителе режима "несколько выражений").

Добавлено спустя 3 минуты 47 секунд:

Наличие или отсутствие символа ";" ни как не влияет на неоднозначность

Удивительно, что Вы до сих пор на эту неоднозначность (приводящую к логической кривизне) не нарывались Компилятор ругается фиг знает на что, указывая на самый конец программы

[alexey38]

Удивительно, что Вы до сих пор на эту неоднозначность (приводящую к логической кривизне) не нарывались Компилятор ругается фиг знает на что, указывая на самый конец программы

Это не "неоднозначность" - компилятор ругается и это уже достаточно. Собственно если компилятор не умеет показывать ошибку - то это недостатки компилятора, а не языка. При любом синтаксисе можно найти способ, чтобы компилятор ругался недостаточно ясно.

В любом случае - это не повод менять синтаксис. Опять же хорошие RAD очень наглядно иллюстрируют подобные ошибки. И то, что Вы на них наталкиваетесь - это исключительно Ваше упрямство.

Это значит что в циклах и ветвлениях больше _нельзя_ будет использовать выражения без ";" в конце. И по ходу, так как теперь имеем как бы всегда "тело" из нескольких выражений - отпадает необходимость в BEGIN (как в отличителе режима "несколько выражений").

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

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

[Mikhail]

Компилятор ругается фиг знает на что, указывая на самый конец программы

Это ошибка в компиляторе.

[debi12345]

Это не "неоднозначность" - компилятор ругается и это уже достаточно. Собственно если компилятор не умеет показывать ошибку

Вы сами с этой ошибкой сталкивались ? Трассировали ее, да еще в большом юните ? Вот то-то

Добавлено спустя 5 минут 14 секунд:

Это ошибка в компиляторе.

Его можно понять - он недосчитался END-ов (и с ".'', и с ";"), а где они забыты (или сглючены из-за неоднозначности ";") - знают только Юзер и Бог

[alexey38]

Вы сами с этой ошибкой сталкивались ?

Из-за символа ";" у меня никогда не было проблем в части понимания того, где ошибка. Ни разу не вспомнил ситуации, где это бы отвлекло более, чем на 1-2 сек.

Из-за отсутствующего или лишнего END проблемы бывают исключительно, если работать в блокноте, а не в RAD. Ваше упорное нежелание использовать нормальные оболочки Вы пытаетесь компенсировать изменением синтаксиса языка. Но это в любом случае не поможет, т.к. проблема ни как не снимется отсутствием BEGIN. Она только усугубится тем, что существующие RAD не сумеют показать такую ошибку, т.к. они заточены на наличие BEGIN.

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

[debi12345]

Ни разу не вспомнил ситуации, где это бы отвлекло более, чем на 1-2 сек.

А у меня было долгое рвание и метания После нескольких таких "залетов" перестал пользоваться без";"-конструкциями вообще - от греха подальше.

END проблемы бывают исключительно, если работать в блокноте, а не в RAD.

Вы хотите сказать никогда сами не впечатываете и не удаляете ENDы ? Не вписываете встроенные функции ?

то Вам в любом случае придется работать и с ранее существовавшими проектами

У меня наоборот на MSEgui - только новые проекты. А зачем переделывать работающие старые ? Пусть работают, каши за казуальную подшлифовку они не просят Уверен что и у 99% остальных такая же ситуация

[alexey38]

Вы хотите сказать никогда сами не впечатываете и не удаляете ENDы ? Не вписываете встроенные функции ?

RAD - это не только и не сколько автоматическое завершение конструкций. Это еще и подсветка. У меня вложенные begin/end подсвечиваются разными цветами. Соответственно лишний или забытый END видно еще без компиляции.

Добавлено спустя 3 минуты 36 секунд:

У меня наоборот на MSEgui - только новые проекты. А зачем переделывать работающие старые ? Пусть работают, каши за казуальную подшлифовку они не просят Уверен что и у 99% остальных такая же ситуация

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

[Лекс Айрин]

Соответственно лишний или забытый END видно еще без компиляции.

Если правильно пользоваться отступами, то забытый begin/end видно даже в блокноте без всякой подсветки.

А вообще, взял себе за правило сначала печатать операторные скобки, а потом уже их содержимое.

[alexey38]

Если правильно пользоваться отступами, то забытый begin/end видно даже в блокноте без всякой подсветки.

Совершенно верно. Но при копировании блоков кода, или глубоком рефакторинге иногда возникают ошибки.

Но RAD с соответствующими плагинами позволяет об этом не задумываться. Причем плагин открытый.
http://code.google.com/p/cnpack/wiki/CnWizardsIntroduction

[debi12345]

Но RAD с соответствующими плагинами позволяет об этом не задумываться. Причем плагин открытый.

Алекс! Вспомните удаленную сборку веб-роботов, демон-сервисов и т.п. на рутерах ! Какой тут (в текстовой консоли) RAD, чесслово Да еще с плагинами Ха!

Добавлено спустя 5 минут 50 секунд:

забытый begin/end

Проблемы создают без-END-овые однолинейные конструкции:

Код: Выделить всё

IF ... THEN BEGIN
  act1a; act1b;
END ELSE
  act2;

Их и не выровняешь толком. Лично я как и Мартин - от такого полонстью отказался.

[alexey38]

Вспомните удаленную сборку

При чем здесь сборка? Какая связь между редактором кода и сборкой, тем более удаленной? Вы уже второй раз на это обращаете внимание, но я не вижу взаимосвязи. Сборка вообще не требует ни какого редактора, даже блокнот не нужен, достаточно консоли.

Проблемы создают без-END-овые однолинейные конструкции:

Вы что так пишите код? Я таких увольняю сразу, за каждую строку. У нас ни одна из приведенных Вами строк не проходит по нашему внутреннему стандарту для написания кода. Если так коряво писать, то тут кроме смены профессии ничего не поможет.

[debi12345]

У нас ни одна из приведенных Вами строк не проходит по нашему внутреннему стандарту для написания кода.

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

Сборка вообще не требует ни какого редактора, даже блокнот не нужен, достаточно консоли.

А-а, вижу что "MСEDIT" Вам не знаком. Я в нем днями сижу, сразу в нескольких сессиях

Добавлено спустя 13 минут 13 секунд:
Хм, а такой код соответствует вашим стандартам :

Код: Выделить всё

with fieldread, (dataset as tmsesqlquery) do begin
  if (fieldwrite.dataset.state in [dsBrowse,dsInactive]) then exit;
   if fieldread is tmselongintfield then begin
      if local_idx_num >= 0 then begin
         if not indexlocal[local_idx_num].find(
            [fieldwrite.asinteger],[],bm,
            false,false,true
         ) then begin
            fieldwrite.clear;
         end;
      end;
   end else if fieldread is tmsestringfield then begin
      if local_idx_num >= 0 then begin
         if not indexlocal[local_idx_num].find(
            [fieldwrite.asmsestring],[],bm,
            false,false,true
         ) then begin
            fieldwrite.clear;
         end;
      end;
   end;
end;


? Обратите внимание на бесящий "ELSE IF" который надеюсь скоро будет заменен на "ELIF"

Добавлено спустя 10 минут 28 секунд:
Навскидку в новом синтаксисе :

Код: Выделить всё

with fieldread:fr, (dataset as tmsesqlquery):ds do
  if (fieldwrite.dataset.state in [dsBrowse,dsInactive]) then
     goto end;
  end;
  if fr is tmselongintfield then
     if local_idx_num >= 0 then
        if not ds.indexlocal[local_idx_num].find(
            [fieldwrite.asinteger],[],bm,
            false,false,true
         ) then
            fieldwrite.clear;
        end;
     end;
  elif fr is tmsestringfield then
     if local_idx_num >= 0 then
        if not ds.indexlocal[local_idx_num].find(
           [fieldwrite.asmsestring],[],bm,
           false,false,true
        ) then
           fieldwrite.clear;
        end;
     end;
  end;
end;

EXIT & RETURN будут заменены на GOTO - с целью ВСЕГДА ВИДЕТЬ откуда и куда (к какой конкретно метке) идет ветвление.

[mse]

Код: Выделить всё

...
label
abort;
begin
...
with fr: fieldread, ds: dataset as tmsesqlquery do
  if fieldwrite.dataset.state in [dsBrowse,dsInactive] then
   goto abort;
  end;
  if fr is tmselongintfield then
   if local_idx_num >= 0 then
    if not ds.indexlocal[local_idx_num].find([fieldwrite.asinteger],[],bm,
                                                         false,false,true) then
     fieldwrite.clear;
    end;
   end;
  else
   if fr is tmsestringfield then
    if local_idx_num >= 0 then
     if not ds.indexlocal[local_idx_num].find( [fieldwrite.asmsestring],[],bm,
                                                         false,false,true) then
      fieldwrite.clear;
     end;
    end;
   end;
  end;
end;
abort:
end;



The BBC software does not show indention correctly, sorry. Indention is one space per level so at end of nested compound statements there is a "end-diagonal".

[alexey38]

А-а, вижу что "MСEDIT" Вам не знаком. Я в нем днями сижу, сразу в нескольких сессиях

Знаком. Но зачем в нем сидеть в процессе разработки? Я обычно работаю под виндой в FARе, примерно то же самое, и у меня открыто обычно 3-6 сеансов этого FAR. Я иногда даже открываю им паскалевские файлы. Но я не веду разработку ни в блокноте, ни в FARе, ни в MCEDITе. Глупо использовать то, что не предназначено для этого дела. Если нужна удаленная сборка, то для этого есть системы контроля версий. И на удаленном узле не нужен редактор, там ты просто собираешь проект из консоли и все.

Добавлено спустя 3 минуты 56 секунд:

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

Стандарт был принят еще лет 10-15 назад, когда и тулсов таких не было. За это время немного его адаптировали. Но стилю форматирования меня научили еще в конце 80х.

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

Добавлено спустя 14 минут 38 секунд:

Хм, а такой код соответствует вашим стандартам :

За такой увольняем сразу.

? Обратите внимание на бесящий "ELSE IF" который надеюсь скоро будет заменен на "ELIF"

За это в первую очередь - очень плохой прием. Особенно за такое "end else if fieldread is tmsestringfield then begin". В ту же секунду и без разговоров. Это уже паталогия.

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

Суть в том, что Ваш стиль требует внимательного прочтения кода, особенно когда приходится править чужой код. Цель хорошего кода заключается в том, что на исправление чужого модуля из 1000 строк тебе выделяется всего 1 час времени, но ты укладываешься за 20 минут. Аналогично, когда сопровождаешь свой модуль, но написанный лет 10-15 или даже 20 назад. И исправляешь его за 10 минут (а не за 20, как с чужым). А у Вас, как Вы сами говорите "было долгое рвание и метания".

EXIT & RETURN будут заменены на GOTO - с целью ВСЕГДА ВИДЕТЬ откуда и куда (к какой конкретно метке) идет ветвление.

Это очень глупое предложение. Оно наоборот скрывает видимость и очевидность. Никогда не пересяду на язык, в котором exit (return), break, continue - заменили на дедовские goto. И на работу не возьму таких "умников", которые думают, что самые умные, вместо того, чтобы изучить опыт предшествующих поколений.