freepascal.ru

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

У Паскаля есть операторы begin и end, у языка Си и С++ есть скобки { }.

Когда в тексте много этих операторов, то не понятно, с каким begin ассоциирован end, точно также со скобками.

Так вот, я хочу, чтобы операторы имели запись типа begin(имя) end(имя), чтобы компилятор ассоциировал конкретный begin с конкретным end. Таким образом я считаю повыситься читабельность, надёжонсть программ. Меньше надо будет держать в памяти ассоцииации между begin и end, т.к. будет очевидно, с кем они ассоциированы. Т.е. процесс программирования будет чуток строже.

Может даже было бы не плохо выставить у компиялтора флажёк, чтобы писал варнинги, а в перспективе ошибки на begin и end без имён.

а) Учитесь писать красивый код. Если в коде много begin\end в которых вы начинаете путаться - делайте рефакторинг кода, применяя метод KISS или же подобные. Для этого поищите на хабрахабре посты о написании большого кода, там есть отличный пример с исходниками Quake.
б) Сейчас практически во всех IDE есть функция подсветки скобок\операторов блоков.
в) Применяйте сворачивание кода.

Лично я применяю такой стиль оформления кода:

yantux писал(а):Так вот, я хочу, чтобы операторы имели запись типа begin(имя) end(имя), чтобы компилятор ассоциировал конкретный begin с конкретным end. Таким образом я считаю повыситься читабельность, надёжонсть программ. Меньше надо будет держать в памяти ассоцииации между begin и end, т.к. будет очевидно, с кем они ассоциированы. Т.е. процесс программирования будет чуток строже.

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

Лекс Айрин писал(а):Да и кто мешает добавить комментарий, если уж так хочется, хоть после каждого оператора?

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

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

for i:=0 to Flist.Count-1 do begin
...
end; {for}

Все здорово, когда это читаешь, но когда начинаешь допиливать.. да когда каждый метод класса тоже снабжен подобным коментом, а IDE при автозавершении и автосоздании методов их раскидывает по всему тексту и ты ищешь и копипастишь на их место.. В гробу я видел подобный стиль. Сам использую стиль оформления, как и evb87ar. Если в делфи, то еще и cnWizards помогают, там есть прелестный менеджер, который все вложенные begin-end отрисовывает другим цветом и показывает между ними связь.
Никакой путаницы даже в корявой простыне на пару pgDown-ов.

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

evb87ar писал(а):а) Учитесь писать красивый код. Если в коде много beginend в которых вы начинаете путаться - делайте рефакторинг кода, применяя метод KISS или же подобные. Для этого поищите на хабрахабре посты о написании большого кода, там есть отличный пример с исходниками Quake.
б) Сейчас практически во всех IDE есть функция подсветки скобокоператоров блоков.
в) Применяйте сворачивание кода.

Лично я применяю такой стиль оформления кода:

а) этому отчасти должен способствовать или определять сам язык и среда разработки, на KISS посмотрю, спасибо за совет
б) редактор не заменяет компилятор
в) что это?

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

Лекс Айрин писал(а): Не повысится читабельность. Да и кто мешает добавить комментарий, если уж так хочется, хоть после каждого оператора?

Я ожидаю повышения читабельности, улучшения качества поддержки кода и т.д.
Если begin и end, о в процессе изменения кода, все комменты придётся править. Т.е. брать отслеживание на себя. А я хочу, чтобы за меня это делал компилятор. Чтобы на этапе компиляции он тыркнул мне, где я не обеспечил соответсвие между begin и end.

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

B4rr4cuda писал(а):Если в делфи, то еще и cnWizards помогают, там есть прелестный менеджер, который все вложенные begin-end отрисовывает другим цветом и показывает между ними связь.
Никакой путаницы даже в корявой простыне на пару pgDown-ов.

Поддерживаю, допустим изначально:

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

begin // func1
   код
     begin // func2
       код
          begin // func3

          end; // func3
      код
    end; // func2
   код
end; // func1


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

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

          begin // func2

          end; // func5


Как через год вспомнить этот код? Как этот код поймт сторонний человек? Как поддерживать такой код?

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

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

Лекс Айрин писал(а):B4rr4cuda, о приблемах допиливания я тоже думал, вот только не решился написать. Причем, если реализовать подобно описанному в заглавном посте, то их будет еще больше. Почему, думаю, не стоит озвучивать.

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

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

б) редактор не заменяет компилятор

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

в) что это?

Сворачивание кода - функция редактора IDE, где можно свернуть какой-либо блок в одну строку, что сильно упрощает наблюдение и работу с большими исходниками.

Поддерживаю, допустим изначально:

В примере много вложений begin\end, это зачастую происходит с вложенными циклами. Как вариант - используйте вложенные функции (кажется так называется). Это когда вы объявляете функции в самой функции\процедуре, а не в основной части кода. И заменяйте этими функциями те вложения в цикл, которые там есть.

А если вложенность обусловлена не циклом, то, возможно, условиями. В таком случае что-то делайте с if...if...if..if...else...else...else...else, заменяя, например, на case, или делая линейные условия, а не вложенные. (if...else...end; if...else...end;). Это получается не совсем красиво с точки зрения компилятора, но намного удобнее для разбора кода.
Один раз я разбирал чужой код с 15ю вложениями if...then...else...end. Это был какой-то маленький филиал ада, честное слово. Хотя сам код просто проверял строки. Парсер там был строковый для SMS-аналитики. Переписал на линейную проверку с использованием оператора goto (для перехода к завершению, стало намного удобнее и легче вносить изменения и дополнять действия. Так же на скорости работы это никак не сказалось.

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

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

Так вот, я хочу, чтобы операторы имели запись типа begin(имя) end(имя),

Переходите на FORTRAN
PS. А кто мешает коменты писать у бегинов и эндов?

yantux писал(а):Мне не очевидно, что проблем будет больше. Я считаю, что проблем будет меньше, код будет понятнее и надёжнее.

Допустим, вы объединяете два условных перехода в один и, совершенно случайно, оставили/стерли лишний "end;" Откуда компилятор может догадаться как стоит маркировать его? Скорее всего, он промаркирует его по цепочке контекстов и, обнаружив лишний "end", прекратит компиляцию с ошибкой, только Вы до посинения будете искать ее, ибо операторные скобки съехали , а значит надписям верить нельзя.
Рассмотрим другой вариант, когда операторные скобки удаляются синхронно. Тогда, в зависимости от логики программы, Вам либо придется переписывать удаленный редактором код заново, либо искать место откуда исчезла вторая часть скобки и копипастить туда нужный фрагмент кода, не забыв при этом затереть оригинальное место.

yantux писал(а): операторы имели запись типа begin(имя) end(имя)

Можно начинать блоки begin/end не с новой строки, а с названия функции(условия):

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

if
then begin
       ...
        end
else begin
       ...
       end;


B4rr4cuda писал(а):но когда начинаешь допиливать

+100500, в одном таком проекте все такие комментарии в скобочках просто вычистил. Просто потому, что отвлекают от процесса.

vada писал(а):

Так вот, я хочу, чтобы операторы имели запись типа begin(имя) end(имя),

Переходите на FORTRAN
PS. А кто мешает коменты писать у бегинов и эндов?

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

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

Лекс Айрин писал(а):

yantux писал(а):Мне не очевидно, что проблем будет больше. Я считаю, что проблем будет меньше, код будет понятнее и надёжнее.

Допустим, вы объединяете два условных перехода в один и, совершенно случайно, оставили/стерли лишний "end;" Откуда компилятор может догадаться как стоит маркировать его? Скорее всего, он промаркирует его по цепочке контекстов и, обнаружив лишний "end", прекратит компиляцию с ошибкой, только Вы до посинения будете искать ее, ибо операторные скобки съехали , а значит надписям верить нельзя.
Рассмотрим другой вариант, когда операторные скобки удаляются синхронно. Тогда, в зависимости от логики программы, Вам либо придется переписывать удаленный редактором код заново, либо искать место откуда исчезла вторая часть скобки и копипастить туда нужный фрагмент кода, не забыв при этом затереть оригинальное место.

На эту тему не могу рассуждать. Со своей стороны я вижу проблему, что операторы begin и end не ассоциированы между собой на языковом уровне. Я считаю, что это проблема. Средства редактирования, комменты, оформления не решают проблемы. Т.к. я должен держать в своей голове ассоциации между begin и end. При 'том не факт, что я не ошибаюсь. Этот фактор своей ошибки я хотел бы исключить средствами компилятора.

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

stanilar писал(а):

yantux писал(а): операторы имели запись типа begin(имя) end(имя)

Можно начинать блоки begin/end не с новой строки, а с названия функции(условия):

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

if
then begin
       ...
        end
else begin
       ...
       end;


B4rr4cuda писал(а):но когда начинаешь допиливать

+100500, в одном таком проекте все такие комментарии в скобочках просто вычистил. Просто потому, что отвлекают от процесса.

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

Padre_Mortius писал(а):yantux, ваши проблемы связаны фактически с тем, что вы не используете стандарты оформления кода.

На одной из бывших работ был внутренний документ coding standart для языков Си и С++. По существу этот документ превращал программирование на этих языках в программирование на паскале. Т.к. очень многие сишные фичи типа i++ были запрещены к использованию. При чём тут же в документе было обоснование зачем и почему. Американская фирма делает авиационные приборы. Так что, если есть стандарт оформления, то необходимо задаться вопросом, не стоит ли его сделать частью языка?

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

evb87ar писал(а):В примере много вложений begin\end, это зачастую происходит с вложенными циклами. Как вариант - используйте вложенные функции (кажется так называется). Это когда вы объявляете функции в самой функции\процедуре, а не в основной части кода. И заменяйте этими функциями те вложения в цикл, которые там есть.

Надо задуматься над этим. Хотя это не решение.

P.S. Во всяком случае именованный begin() end() будет мешать программистам создавать плохо читабельный и поддерживаемый код.

Проблема искусственная. Из серии создам сам себе трудности - а потом буду преодолевать их.

Первое правило оформление кода - текст процедуры должен целиком помещаться на экране без перелистывания! Если процедура больше - рефакторинг кода просто необходим. Если придерживаться этого стандарта - не будет проблем с большим количеством блоков кода.
Ну и естественно - не стоит писать весь код в одну строку . А то сразу предвижу примеры из этой области.
1 логическая операция - 1 строка.

yantux_netbook писал(а):На эту тему не могу рассуждать.

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

yantux_netbook писал(а):Этот фактор своей ошибки я хотел бы исключить средствами компилятора.

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

yantux_netbook писал(а):P.S. Во всяком случае именованный begin() end() будет мешать программистам создавать плохо читабельный и поддерживаемый код.

Нет предела совершенству. К тому же, есть код читаемый, а есть код редактируемый (поддерщиваемый).
ЗЫ: наверняка многие думали как оформить код так, чтобы он стал легко набираемым, редактируемым и читаемым. Тем не менее, со времен турбопаскаля в этом плане мало что поменялось...

Это можно сделать на уровне IDE, добавляя комментарии где надо, во время анализа кода. Не обязательно компилятор дербанить, уменьшая совместимость.
Хотя в IDE блоки обычно хорошо подсвечиваются, связываются линиями и т.п. Короче, видно к чему что относится, если конечно блоки не на десять страниц. В этом случае поможет только блокнот вместо IDE на пару месяцев.