ищу программу которая стилизует исходный код

← →
Anatoly Podgoretsky © (2010-03-24 09:09) [120]

> Игорь Шевченко (24.03.2010 00:45:51) [111]

Если тебя заставить сначала на бумаге отлаживать программу, то ты тоже станешь генеем.

← →
Anatoly Podgoretsky © (2010-03-24 09:13) [121]

> Германн (24.03.2010 02:32:55) [115]

Два варианта
case I of 1 : begin sms; sms; end; 2 : sms; else sms; end; case I of 1 : begin sms; sms; end; 2 : begin sms; end; else begin sms; end end;

← →
Игорь Шевченко © (2010-03-24 11:14) [122]

Anatoly Podgoretsky © (24.03.10 09:09) [120]

Ты считаешь, причина именно в этом ? :)

← →
Anatoly Podgoretsky © (2010-03-24 11:39) [123]

Кто тут про ременную передачу говорил, вот это она и есть в действии.

← →
Bel © (2010-03-24 16:50) [124]

Лично я за написание begin на новой строке.
В каком варианте будет легче обнаружить ошибку?
if Condition1 and Condition2 and Condition3 then begin Operator1; Operator2; Operator3; .... (end где-то внизу, за пределами поля видимости)
или
if Condition1 and Condition2 and Condition3 then Operator1; Operator2; Operator3; .... (end где-то внизу, за пределами поля видимости)

← →
Bel © (2010-03-24 16:53) [125]

[124] +
А в таком стиле было бы проще обнаружить отсутствие begin:
if Condition1 and Condition2 and Condition3 then begin Operator1; Operator2; Operator3; .... (end где-то внизу, за пределами поля видимости)

← →
Юрий Зотов © (2010-03-24 18:18) [126]

> Anatoly Podgoretsky © (24.03.10 09:07) [119]

> Вирт был весьма не последователен с понятием ОПЕРАТОР,
> то у него они однострочные, то многострочные.

В Паскале нет ни однострочных, ни многострочных операторов. Есть простые и составные. Разрывы строк игнорируются (как и пробелы), а Вирт вполне последователен:

<оператор> ::= <простой оператор> | <составной оператор>
<простой оператор> :: = <оператор IF> | <оператор WHILE> | ... (и т.д.)
<составной оператор> :: = BEGIN <список операторов> END
<список операторов> := <оператор> | <оператор> ; <список операторов>

Просто, четко, однозначно и красиво. Классика! Песня!

← →
ProgRAMmer Dimonych © (2010-03-24 18:59) [127]

> [113] Eraser © (24.03.10 02:07)
> в таких спорах мне всегда интересно кто как конструкцию
> case of else пишет ;-)

Э-э-э не-е-ет... Так не пойдёт. Этого оператора вообще лучше избегать, как и with. Т.е. использовать, конечно, никто не запрещает, но чем больше дров - тем дальше от их леса.

По моей родной логике должны соблюдаться как минимум следующие требования:

1. Не должно быть разрыва операторов. Тех, которые на схемах алгоритмов представимы в виде операционного блока.
2. begin и end - выровнены по одному и тому же полю от левого края.

В программах лично я стараюсь не использовать в case составного оператора. Если действия, выполняемые в разных ветвях, довольно однородны и просты, то делаю что-то в духе:

case Operation of opPlus: C := A + B; opMinus: C := A - B; opMul: C := A * B; opDiv: C := A * B; else C := 0; end;

А после этого, красоты ради, повыравнивать вот так, например:

case Operation of opPlus : C := A + B; opMinus : C := A - B; opMul : C := A * B; opDiv : C := A * B; else C := 0; end;

В более тяжёлых случаях - процедуры. Или последовательность if"ов. При отладке и сопровождении зачтётся.

P.S. Так и не смог добиться, чтобы после opMul и opDiv двоеточия шли наравне с вышестоящими. Если добавляю ещё один пробел - их сносит сразу на 2 :(

← →
ProgRAMmer Dimonych © (2010-03-24 18:59) [128]

P.P.S. Эм-м-м... Предпросмотр в моём DMClient"е оставляет желать лучшего :)

← →
Игорь Шевченко © (2010-03-24 19:22) [129]

> Этого оператора вообще лучше избегать, как и with

Это еще почему ?

← →
ProgRAMmer Dimonych © (2010-03-24 19:51) [130]

> [129] Игорь Шевченко © (24.03.10 19:22)
>
> > Этого оператора вообще лучше избегать, как и with
>
> Это еще почему ?

Про with, помню, было здесь когда-то обсуждение. О том, что его крайне осторожно следует применять.

В случае с case - тут начиная с чисто синтаксической громоздкости (не зря с нас запросили пример оформления именно этого оператора) и заканчивая тем, что (пусть это звучит предельно субъективно, но) использование case во многом схоже с использованием GOTO. Которое, как мы знаем, тоже не рекомендуется.

В Basic"е был в своё время такой оператор:

60 ON Vasya GOTO 120, 160, 230, 580 ... 120 PRINT "Vasya wants to plus it!" ... 160 PRINT "Vasya wants to minus it!" ... 230 PRINT "Vasya wants to multiply it!" ... 580 PRINT "Vasya wants to divide it!" ...

В языках Pascal-ветки это записывается как-то так:

Label 120, 160, 230, 580; ... case Vasya of 1 : goto 120; 2 : goto 160; 3 : goto 230; 4 : goto 580; end; ... 120: writeln("Vasya wants to plus it!"); ... 160: writeln("Vasya wants to minus it!"); ... 230: writeln("Vasya wants to multiply it!"); ... 580: writeln("Vasya wants to divide it!"); ...

Пахнет макаронами, не так ли?

Хорошо, можно было те же writeln"ы записать прямо в case: синтаксис позволяет, да и в упомянутом Basic"е чуть позже появился аналогичный оператор. Но это возможно, если у нас выполнятся 1-2 элементарных действия по каждой ветви. Для бОльшего количества приходится от греха подальше заводить процедуру. Обозвать которую более или менее разумно не всегда представляется возможным. Другие способы решения создают другие проблемы. И т.д., и т.п. Проще обойтись без case, чем искать оптимальный вариант. Который для каждого конкретного случая будет своим. А это означает, что единого стиля в коде не будет.

Не утверждаю, что от case надо отказаться (есть задачи, куда они просто напрашиваются), но избегать имеет смысл. Благо это всегда возможно.

← →
Anatoly Podgoretsky © (2010-03-24 19:58) [131]

> Юрий Зотов (24.03.2010 18:18:06) [126]

Не забудь про REPEAT (цикл с постусловием) и сравни с WHILE (цикл с предусловием)
Про последователей в лице Борланд я не говорю.

← →
Anatoly Podgoretsky © (2010-03-24 19:58) [132]

Удалено модератором

← →
Игорь Шевченко © (2010-03-24 20:43) [133]

ProgRAMmer Dimonych © (24.03.10 19:51) [130]

> В случае с case - тут начиная с чисто синтаксической громоздкости

менее громоздко, чем использование

if .. then
else if ... then
else if ... then
else

> и заканчивая тем, что (пусть это звучит предельно субъективно,
> но) использование case во многом схоже с использованием
> GOTO.

Ничуть не схоже.

> В языках Pascal-ветки это записывается как-то так:
>
> Label 120, 160, 230, 580;
> ...
> case Vasya of
> 1 : goto 120;
> 2 : goto 160;
> 3 : goto 230;
> 4 : goto 580;
> end;
> ...
> 120:
> writeln("Vasya wants to plus it!");
> ...
> 160:
> writeln("Vasya wants to minus it!");
> ...
> 230:
> writeln("Vasya wants to multiply it!");
> ...
> 580:
> writeln("Vasya wants to divide it!");
> ...

нет, это записывается так:

case Vasya of 1 : begin writeln("Vasya wants to plus it!"); .... end; 2 : begin writeln("Vasya wants to minus it!"); .... end; 3 : goto 230; begin writeln("Vasya wants to multiply it!"); .... end; 4 : goto 580; begin writeln("Vasya wants to divide it!"); .... end; end;

Вроде никакого криминала.

> Про with, помню, было здесь когда-то обсуждение. О том,
> что его крайне осторожно следует применять.

Все надо осторожно применять. Даже оператор присваивания.

> Но это возможно, если у нас выполнятся 1-2 элементарных
> действия по каждой ветви. Для бОльшего количества приходится
> от греха подальше заводить процедуру. Обозвать которую более
> или менее разумно не всегда представляется возможным. Другие
> способы решения создают другие проблемы. И т.д., и т.п.
> Проще обойтись без case, чем искать оптимальный вариант.
> Который для каждого конкретного случая будет своим. А это
> означает, что единого стиля в коде не будет.

Глупость или фанатизм

← →
ProgRAMmer Dimonych © (2010-03-24 21:32) [134]

> [133] Игорь Шевченко © (24.03.10 20:43)
> менее громоздко, чем использование
>
> if .. then
> else if ... then
> else if ... then
> else

Эм-м-м... Чаще всего можно обойтись и без многоifов. Если заранее продумать, что пишем.

> Ничуть не схоже.

Даже и не рассчитывал, что Вы оцените эту аналогию. Но, думаю, есть здесь и те, кто увидит в синтаксисе отдельных ветвей слабозамаскированные "метки".

> case Vasya of
> 1 :
> begin
> writeln("Vasya wants to plus it!");
> ....
> end;
> 2 :
> begin
> writeln("Vasya wants to minus it!");
> ....
> end;
> 3 : goto 230;
> begin
> writeln("Vasya wants to multiply it!");
> ....
> end;
> 4 : goto 580;
> begin
> writeln("Vasya wants to divide it!");
> ....
> end;
> end;
>
> Вроде никакого криминала.

Искренне верую, что Вы так не пишете. Потому что достаточно хотя бы по 10 строк в каждую ветвь - и case разрастается до неимоверных размеров. Большой экран спасёт от проблем с отладкой, а вот от икоты - вряд ли, если у читающего не окажется такого же большого экрана. Не зря советуют умещать процедуры в 1 экран. Классически это около 25 строк.

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

Интересно, почему Borland"овцы решили расширить синтаксис добавлением директивы message? Хочу увидеть оконную процедуру окна для хоть сколько-нибудь сложной программы!.. Это ведь то самое классическое место для применения case, так ведь? Очень сомневаюсь, что там будет одновременно много-много операторов в каждой ветви и запредельная читабельность, признаваемая большинством.

Второй случай: какая-нибудь более или менее сложная обработка ввода с клавиатуры. Для парочки десятков клавиш с различным назначением. Там уж точно ужимать case придётся как-то.

← →
Игорь Шевченко © (2010-03-24 22:12) [135]

ProgRAMmer Dimonych © (24.03.10 21:32) [134]

> Хочу увидеть оконную процедуру окна для хоть сколько-нибудь
> сложной программы!.. Это ведь то самое классическое место
> для применения case, так ведь?

Forms.pas, TApplication.WndProc;
Controls.pas: TDragObject.WndProc, TControl.WndProc, TWinControl.WndProc

> Эм-м-м... Чаще всего можно обойтись и без многоifов. Если
> заранее продумать, что пишем.

Если заранее продумать, то и case не страшен.

> Искренне верую, что Вы так не пишете. Потому что достаточно
> хотя бы по 10 строк в каждую ветвь - и case разрастается
> до неимоверных размеров

Не вижу криминала и прочего греха. С процедурами на каждую ветку общий объем кода увеличится, а скакать между case/if, где процедура используется и самим кодом процедуры куда как меньшее удовольствие, чем смотреть на case в одном месте.

> Интересно, почему Borland"овцы решили расширить синтаксис
> добавлением директивы message?

Затем, чтобы в наследниках обрабатывать непредусмотренные предком сообщения, не переписывая его методы Dispatch и DefaultHandler.

Как резюме, хочу сказать одно: Фаулер и Бек - это не догма, а руководство к действию.

← →
ProgRAMmer Dimonych © (2010-03-24 22:33) [136]

> Forms.pas, TApplication.WndProc;
> Controls.pas: TDragObject.WndProc, TControl.WndProc, TWinControl.WndProc

Действительно, для очень сложной программы. Ну да ладно. Даже в указанных оконных процедурах наблюдаем сведение к минимуму кода, записываемго в самой ветке явно, не так ли? Из всех приведённых больше одного развёрнутого окна кода в Delphi 7 только у Application. Но там, вообще говоря, предельно общие действия выполняются. Вот из WinAPI-only-программы бы. Хотя даже эти, немногим сложнее закрытия окна по нажатию Esc, уже содержат 1-2 оператора в каждой ветви и активно применяют процедуры.

> С процедурами на каждую ветку общий объем кода увеличится,
> а скакать между case/if, где процедура используется и самим
> кодом процедуры куда как меньшее удовольствие, чем смотреть
> на case в одном месте.

Пару if"ов и небольшой цикл Вам в каждую ветку :) Небольшой - всм такой, чтобы выносить в отдельную процедуру жалко было, а место занимал.

> Фаулер и Бек - это не догма, а руководство к действию.

Читал их "Рефакторинг <...>". Красиво, но более чем как руководство к действию и не воспринимал. Как, впрочем, и "Экстремальное программирование". Там довольно общие идеи. А при выработке для себя каких-то правил руководствуюсь в первую очередь опытом бессонных последних ночей и тем, где находилась гадкая ошибка. Возможно, в случае с case это программистозависимо, не знаю...

← →
Игорь Шевченко © (2010-03-24 23:10) [137]

ProgRAMmer Dimonych © (24.03.10 22:33) [136]

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

Я при выработке для себя правил руководствуюсь высказыванием:
"Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время".
и правилом номер 2 Эрика Реймонда: "Ясность лучше чем мастерство".

case в оправданном применении предельно ясная конструкция, вне зависимости от размера оператора - при (опять же) оправданном применении никогда нет нужды охватывать весь case как единое целое, а следует сосредотачиваться на его отдельных частях.

к with и goto все вышесказанное относится точно так же.

Кстати, если case можно заменить массивом указателей на функции - он будет заменен массивом указателей на функции ;)

← →
ProgRAMmer Dimonych © (2010-03-24 23:25) [138]

> [137] Игорь Шевченко © (24.03.10 23:10)
> case в оправданном применении предельно ясная конструкция,
> вне зависимости от размера оператора - при (опять же) оправданном
> применении никогда нет нужды охватывать весь case как единое
> целое, а следует сосредотачиваться на его отдельных частях.
>
> к with и goto все вышесказанное относится точно так же.

Тысяча чертей, а ведь об одном и том же говорим :) Правда, мне надо научиться основную мысль выражать яснее, чем побочные:

> [127] ProgRAMmer Dimonych © (24.03.10 18:59)
> чем больше дров - тем дальше от их леса

> [137] Игорь Шевченко © (24.03.10 23:10)
> Кстати, если case можно заменить массивом указателей на
> функции - он будет заменен массивом указателей на функции
> ;)

Приём красивый, но, кстати, этим Intel увлекаться не советует. Ибо "if the target destination is not predictable, performance can
degrade quickly". Опять приходим к границам применимости :(

← →
Игорь Шевченко © (2010-03-25 00:25) [139]

ProgRAMmer Dimonych © (24.03.10 23:25) [138]

> Приём красивый, но, кстати, этим Intel увлекаться не советует.
> Ибо "if the target destination is not predictable, performance
> can
> degrade quickly". Опять приходим к границам применимости
> :(

Не совсем unpredictable :)

Во что разворачивается типовой case (когда его case-ы идут более или менее подряд):

mov eax,case_variable cmp eax,max_case_value ja default jmp cases[4*eax]

в случае с массивом функций примерно то же самое, только вместо
jmp cases[4*eax]
будет
call cases[4*eax]

Впрочем, говорить о Delphi и производительности с точки зрения оптимальности генерируемого кода - это большой вопрос, сишный компилятор MS генерирует более оптимальный код, а с учетом приемов MS по оптимизации размещения кода по страницам по частоте вызовов, так и вовсе большой вопрос.

Честно не анализировал код, сгенерированный Intel-овским компилятором С - может, он еще более оптимален.

← →
ProgRAMmer Dimonych © (2010-03-25 01:16) [140]

> [139] Игорь Шевченко © (25.03.10 00:25)

Набросал тестовый примерчик. Моя Delphi 7 преобразует вот это:

procedure TForm1.FormClick(Sender: TObject); var i : DWORD; begin i := GetLastError; case i of 1 : i:=5; 2 : i:=64; 3 : i:=15; else i:=80; end; Form1.Caption:=IntToStr(i); end;

в такое:

... call 00405E40 ; GetLastError mov ebx, eax dec ebx je 0044C892 dec ebx je 0044C899 dec ebx je 0044C8A0 jmp 0044C8A7 0044C892: mov ebx, 00000005 jmp 0044C8AC 0044C899: mov ebx, 00000040 jmp 0044C8AC 0044C8A0: mov ebx, 0000000F jmp 0044C8AC 0044C8A7: mov ebx, 00000050 0044C8AC: ...

Для упомянутого приёма (массив указателей на функции) наподобие такого:

procedure TForm1.FormDblClick(Sender: TObject); const Funcs : array [0..3] of PFunc = (Proc0,Proc1,Proc2,Proc3); // type PFunc = function:Integer; var i : Integer; begin i := GetLastError; if i>0 then i:=Funcs[i]() else i:=Funcs[0](); Form1.Caption:=IntToStr(i); end;

на выходе имеем

... call 00405E40 ; GetLastError mov ebx, eax test ebx, ebx jle 0044C944 mov ebx, dword ptr [4*ebx+0044DD34] call ebx mov ebx, eax jmp 0044C94C 0044C944: call dword ptr [0044DD34] mov ebx, eax 0044C94C: ...

Так что код немного другой. Но, похоже, я поторопился применять общие правила, предлагаемые Intel, для кода, генерируемого Delphiйским компилятором. Ибо, если я ничего не упускаю из виду, то в первом случае имеем для else-ветки 100%-ную правильность статического предсказания, для остальных остаётся непредсказанным выполняемый условный переход. Тогда как для второго случая 100%-ное статическое предсказание работает для 3 из 4 случаев (кроме else). И, наверное, не всё здесь будет так однозначно, как хотелось бы.

Хотя случай, когда можно заменить case массивом указателей, наверное, следует признать достаточно редким. Да и сдаётся мне, что применить это можно красиво в той части кода, которая обеспечивает пользовательский интерфейс. А там скорость выполнения не слишком критична.

Насчёт качества кода Сишным компиляторов - тоже не копался. Говорят, лучше. Верить не хочу :)

← →
TUser © (2010-03-25 10:03) [141]

> Bel © (24.03.10 16:50) [124]
>
> Лично я за написание begin на новой строке.
> В каком варианте будет легче обнаружить ошибку?

В любом. Компилтор просто не скомпилирует, потому что далее снизу где-то встретит procedure .... когда statement expected. В обнаружении, где нет begin"а сильно помогает подкраска при наведении мышки.

← →
Bel © (2010-03-25 13:09) [142]

TUser © (25.03.10 10:03) [141]

> Bel © (24.03.10 16:50) [124]
>
> Лично я за написание begin на новой строке.
> В каком варианте будет легче обнаружить ошибку?

В любом. Компилтор просто не скомпилирует, потому что далее снизу где-то встретит procedure .... когда statement expected. В обнаружении, где нет begin"а сильно помогает подкраска при наведении мышки.
Имелось ввиду, что с парностью begin-end все в порядке. Просто в первом случае все последующие операторы выполняются по условию if, а во втором - только первый оператор по if"у, а у остальных просто отступ неправильно сделан. Здесь беглым взглядом будет не очень заметно begin в конце строки с условием.

← →
oldman © (2010-03-25 13:30) [143]

> Bel © (25.03.10 13:09) [142]

if (нечто длинное) then begin
делаем 1;
делаем 2;
делаем 3;
end;
if (нечто короткое) then
делаем 4;
делаем 5;
делаем 6;
делаем 7;

Все читабельно.

> а у остальных просто отступ неправильно сделан

А вот надо правильно отступы делать, а то и отдельно стоящие begin end будут теряться...

← →
Юрий Зотов © (2010-03-25 14:14) [144]

> Anatoly Podgoretsky © (24.03.10 19:58) [131]

Не забыл. Разницу знаю. И что?

Здесь тоже все вполне логично и однозначно. Не стоит забывать, что while и until мы подсознательно переводим на русский, как "пока", но для until при этом получаем не вполне эквивалентный аналог английского толкования. Точный аналог выглядит так:

while: пока_выполняется_условие
until: до_выполнения_условия

и для англоговорящего народа все нормально, потому что для них разница между while и until очевидна.

IMHO.

← →
Bel © (2010-03-25 15:09) [145]

>oldman © (25.03.10 13:30) [143]
>А вот надо правильно отступы делать, а то и отдельно стоящие begin end будут теряться...

Дык, я же и привел эти примеры в качестве ошибочной ситуации. Из-за неправильных отступов (ну вот как-то так получилось) и стиля написания, предполагающего написание begin в конце предыдущей строки, данную логическую ошибку алгоритма будет довольно сложно обнаружить с первого взгляда. А вот если я ожидаю begin в начале новой строки и не увижу его там с первого беглого взгляда, то ошибка сразу обнаружится.

← →
ProgRAMmer Dimonych © (2010-03-25 16:00) [146]

> [145] Bel © (25.03.10 15:09)
> А вот если я ожидаю begin в начале новой строки и не увижу
> его там с первого беглого взгляда, то ошибка сразу обнаружится.

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

Своё обоснование begin"а в начале строки я уже привел выше. Видимо, идея неразбиения цельного самостоятельного блока не нашла отклика. Сейчас пришла ещё мысль о том, что, оставив begin в конце предыдущей строки, можно не найти его на экране, когда условие окажется достаточно длинным. В этом смысле begin с новой строки имеет бесконечный запас: мы можем писать хоть километры условий, но их мы будем изучать отдельно от разделения на блоки. Да, знаю, что длинное условие - прямая дорога к перекраиванию проекта, но запас есть запас.

← →
euru © (2010-03-25 16:35) [147]

> Bel © (25.03.10 15:09) [145]
Т.е. месторасположение begin"а более критично, чем наличие отступов?
Неужели
<оператор>
if <условие> then
begin
<оператор>
while <условие> do
begin
<оператор>
<оператор>
end;
<оператор>
end;
<оператор>

более понятно, чем
<оператор>
if <условие> then begin
<оператор>
while <условие> do begin
<оператор>
<оператор>
end;
<оператор>
end;
<оператор>

А отсутствие недостающего begin"а или наличие лишнего end"а обнаружится ещё при компиляции.

← →
Bel © (2010-03-25 16:35) [148]

>ProgRAMmer Dimonych © (25.03.10 16:00) [146]
>...с таким же успехом можно сказать: "А вот если я ожидаю begin в конце предыдущей строки и не увижу его там с первого беглого взгляда, то ошибка сразу обнаружится".

Беглый взгляд легче выхватит begin в начале строки (и вообще единственное слово в строке), а не в конце.
>Сейчас пришла ещё мысль о том, что, оставив begin в конце предыдущей строки, можно не найти его на экране, когда условие окажется достаточно длинным. В этом смысле begin с новой строки имеет бесконечный запас: мы можем писать хоть километры условий, но их мы будем изучать отдельно от разделения на блоки.

Вот и я про то же.

>euru © (25.03.10 16:35) [147]
>Т.е. месторасположение begin"а более критично, чем наличие отступов?
>Неужели
>...
>более понятно, чем
>...

Ну, я же не предлагал вообще отказаться от отступов. Оба варианта, с моей точки зрения, плохи для понимания кода. Я - за применение обоих методов оформления кода: и выделение отступами, и написание begin в отдельной строке.

> ProgRAMmer Dimonych © (25.03.10 16:00) [146]

> Сейчас пришла ещё мысль о том, что, оставив begin в конце
> предыдущей строки, можно не найти его на экране, когда условие
> окажется достаточно длинным.

Т.е. если условие не всё помещается на экране, то это нормально. А если begin не вместился, то налицо ошибка проектирования.

> Bel © (25.03.10 16:44) [149]
> Я - за применение обоих методов оформления кода: и выделение
> отступами, и написание begin в отдельной строке.

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

>ProgRAMmer Dimonych © (25.03.10 16:00) [146]
>Сейчас пришла ещё мысль о том, что, оставив begin в конце предыдущей строки, можно не найти его на экране, когда условие окажется достаточно длинным. В этом смысле begin с новой строки имеет бесконечный запас: мы можем писать хоть километры условий, но их мы будем изучать отдельно от разделения на блоки.

Кстати, в качестве иллюстрации этого (у нас довольно часто приходится так делать). Главное, чтобы получилось нормально с отступами...
Вариант 1:
if <часть длинного условия1> and <часть длинного условия2> and <часть длинного условия3> then begin Операторы.... end;
Вариант 2:
if <часть длинного условия1> and <часть длинного условия2> and <часть длинного условия3> then begin Операторы.... end;
Во втором варианте читабельность явно хуже...

> [150] euru © (25.03.10 16:47)
>
> > ProgRAMmer Dimonych © (25.03.10 16:00) [146]
>
> > Сейчас пришла ещё мысль о том, что, оставив begin в конце
>
> > предыдущей строки, можно не найти его на экране, когда
> условие
> > окажется достаточно длинным.
>
> Т.е. если условие не всё помещается на экране, то это нормально.
> А если begin не вместился, то налицо ошибка проектирования.

А где, интересно мне, я написал, что это ошибка проектирования? Это всегда ошибка проектирования. Но иногда просто случается, что "ну вот ни в какую". Привязка к сторонней библиотеке, например. Дебильные требования к именованию функций и переменных с включением в них всей мыслимой и немыслимой информации... Да мало ли чего. И здесь приходит решение: отдельно отмучать один раз условие и больше никогда на него не отвлекаться.
..
Да и дело-то не в том. Это как имена файлов 8.3: мне более чем достаточно, а вот людям чего-то не хватало. Да и сам я иногда всё-таки называю файл в духе GluckInc_49Dec2012_PreFinal.doc. Хорошо, когда есть запас. Ещё лучше, когда можно сделать его бесконечным, не теряя по другим показателям.

> [152] Bel © (25.03.10 16:56)
> Во втором варианте читабельность явно хуже...

"Явно" - наш злейший враг :)

А в варианте 2 проблемка наглядно показана. Отступ должен быть вроде как вправо, а получается, что операторы - на 1 символ влево. Мне ещё хотя бы 1 пробел нормально, зрение позволяет пока что пользовать и 1-пробельный отступ. А вот откат от разрекламированного "единого и нерушимого" отступа...

> if <часть длинного условия1> and
> <часть длинного условия2> and
> <часть длинного условия3> then
> begin
> Операторы....
> end;

а вот часть программистов пишет так:

if <часть длинного условия1> and <часть длинного условия2> and <часть длинного условия3> then begin Операторы.... end;

Кто прав ? :)

> Игорь Шевченко © (25.03.10 19:08) [156]

> Кто прав ? :)

Прав я, бо делаю так:
if <часть длинного условия1> and <часть длинного условия2> and <часть длинного условия3> then begin Операторы.... end;
:)
Не знаю, получится ли отобразить точно.

--
Regards, LVT.

> Leonid Troyanovsky © (25.03.10 19:13) [157]

> Не знаю, получится ли отобразить точно.

"Операторы" уехали на +1.
Ну и сложный тут механизм поедания пробелов, однако.

--
Regards, LVT.

> Игорь Шевченко © (25.03.10 19:08) [156]

> а вот часть программистов пишет так:

это программисты-староверы :)

> Leonid Troyanovsky © (25.03.10 19:13) [157]

я тоже так пишу

ищу программу которая стилизует исходный код Найти похожие ветки