Mikhail писал(а):Я считаю что у каждой конструкции должна быть четко выраженная семантика.
while - структурный цикл с предусловием.
repeat - структурный цикл с постусловием.
for - структурный цикл с фиксированным числом повторений.
loop - неструктурный цикл общего вида.
Использование операторов досрочного выхода разрушает семантику структурных циклов и сводит их ценность почти к нулю.
Вы слишком увлекаетесь формальным подходом. Вместо дела, Вы радеете за абстрактную красоту кода. Такой код будет красив, но неприменим в реальных задачах.
debi12345 писал(а):Ессно, имелся ввиду перескок уровней (shift >0).
Я, например, считаю это признаком плохого алгоритма. Такое лучше не применять. А там, где все таки очень нужно, там нужно применять Exit, т.е. ясность кода обеспечивается правильной структуризацией.
Мне кажется, что все Ваши предложения и предложения Михаила вызваны тем, Вам в Вашей практике мало приходилось работать с чужим кодом (написанным не Вами), либо с Вашим кодом, написанным лет 10-20 назад.
Хорошо написанный чужой код Вы должны понять сходу, на читая документации, и даже не зная заранее, что вообще выполняет этот код (какую он решает задачу). Хороший код, он как хорошая книга, читаешь и понимаешь все сходу.
Так вот, перескоки через уровни - они вводят в ступор. Приходится притормаживаться и разбираться куда конкретно перепрыгиваем, и почему мы перепрыгиваем.
Цель хорошего языка программирования - это не ускорение процесса первичного кодирования. Т.к. профессионал набивает текст в несколько тысяч знаков в минуту. И код в 1000 строк пишется за час, вместе с первичной отладкой. Смысла нет ускорять этот процесс, я например, пишу программу быстрее, чем успеваю думать (разрабатывать).
Цель хорошего языка программирования - это кардинальное упрощение процесса отладки (особенно комплексной), и сокращение трудозатрат в десятки или сотни раз на сопровождение проекта. У нас например, считается, что баг в чужой программе (которую практически не знаешь) нужно исправить не более, чем за 1 час. Плохо написанный код при сопровождении требует огромных трудозатрат, и любой такой проект умирает, т.к. ни один заказчик не может (не будет) платить огромные деньги (программист тоже хочет кушать) за бесконечную отладку и за глюки.
Добавлено спустя 10 минут 3 секунды:debi12345 писал(а):Чтобы не ставить на рутер GIT-сервер. Вы бы своему нетворк-админу это разрешили бы ? Вот то-то
И даже в случае GIT-клиента на рутере... Толку собирать и тестировать на локальной машине если у рутера свои настройки доступа в сеть (недоступные локальной машине) ?
Но Вы же смогли соединиться с удаленной машиной? Значить и пакеты ходят в обе стороны. А раз пакеты ходят в обе стороны, то и доступ к Вашему GIT или SVN серверу есть с удаленной машины. Прописывайте маршрут (если с удаленной машины инет не виден) и в путь. А если на удаленной машине есть инет, то вообще нет проблем (все работает само по себе). В любом случае, удаленная машина - это не случайный комп, это комп, где Вы внедряете задачу. А если Вы еще и там собираете, то там в любом случае стоят куча Вашего софта (компилятор, библиотеки и т.п.).
На своей машине можно не тестить, а компиляция - это как минимум проверка синтаксиса, да и собрать на своей тоже хорошо. Своя машина - это полноценный набор инструментов для разработки. Вы же сами указываете, что не можете запускать полноценные RAD на удаленной машине.
Вы похоже сами выдумали себе мазохистские проблемы, которые затем героически решаете.
debi12345 писал(а):Исключительно для обслуживания процедур (RETUEN без значения) ? Тогда точно в топку
В классическом паскале есть EXIT, а не RETURN. А для функций есть Result.
Не нужно без необходимости ломать паскалевский диалект. EXIT и Result - прекрасно работают. Вообще без нареканий.