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

← →
azatsh (2010-03-22 21:32) [0]

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

← →
Eraser © (2010-03-22 21:41) [1]

> [0] azatsh (22.03.10 21:32)

у меня в Делфи ctrl + D нажимаешь и все стилизуется само ;-)

← →
DVM © (2010-03-22 21:43) [2]

> azatsh

DelForEx

← →
iZEN (2010-03-22 21:47) [3]

Ctrl + Shift + F в Eclipse.

← →
Andy BitOff © (2010-03-22 21:52) [4]

> DVM © (22.03.10 21:43) [2]

Прекрасная весч! У меня настроено все было, а она в 2010 не стала работать почему-то =(

← →
Игорь Шевченко © (2010-03-22 21:54) [5]

Jedi Code Formatter,
Delphi 2010, Ctrl+D

на выбор

← →
Дмитрий Белькевич (2010-03-22 22:19) [6]

Использую JCF. Раньше пользовал DelForEx.

← →
Правильный$Вася (2010-03-22 22:57) [7]

> стилизует исходный код

мне под ренессанс, пожалуйста
а то под готику задолбало уже

← →
Petr V. Abramov © (2010-03-22 23:55) [8]

> Либо сам ленишься делать нужные отступы и соблюдать красивый
> стиль написания.

http://lurkmore.ru/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:Design
:)

← →
Кто б сомневался © (2010-03-23 00:10) [9]

> Либо сам ленишься делать нужные отступы и соблюдать красивый
> стиль написания.

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

A := b лучше читается чем
A:=b
Почитай в нете правила стилизациии кода delphi .

← →
Юрий Зотов © (2010-03-23 00:38) [10]

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

← →
turbouser © (2010-03-23 00:52) [11]

> Andy BitOff © (22.03.10 21:52) [4]

в 2010 уже есть. по тому же Ctrl+D
+ delforex совсем не развивается уже давно. под 2007 сам допиливал форматирование выделенного текста..

← →
Германн © (2010-03-23 01:35) [12]

> Юрий Зотов © (23.03.10 00:38) [10]
>
> Форматирую ручками, сразу по ходу написания

Дык речь не об этом. Речь о "чужом исходнике". Например моём. Для других он может оказаться "непривычным".
Он грамотно отформатирован, но "непривычно" для некоторых. :)

← →
test © (2010-03-23 01:38) [13]

Германн © (23.03.10 01:35) [12]
Значит твой код "непривычно" читать, при прочтении такого кода чаще хочется выкинуть его и написать заново.

← →
Германн © (2010-03-23 02:18) [14]

> test © (23.03.10 01:38) [13]
>
> Германн © (23.03.10 01:35) [12]
> Значит твой код "непривычно" читать, при прочтении такого
> кода чаще хочется выкинуть его и написать заново.
>

Смотря для кого!
Мой принцип форматирования заключается только лишь в том, что я begin не выношу в новую строку, а оставляю его на "основной строке". Например:
if smts then begin end; with smts do begin end;

← →
Petr V. Abramov © (2010-03-23 02:21) [15]

> Германн © (23.03.10 02:18) [14]
>
>

см [8]

← →
Германн © (2010-03-23 02:22) [16]

> Германн © (23.03.10 02:18) [14]

К этому меня приучили ребята из Turbo Power Software. Не все конечно. Они уже тогда (очень давно ещё во времена ДОС) разделились на два лагеря.

← →
Германн © (2010-03-23 02:23) [17]

> Petr V. Abramov © (23.03.10 02:21) [15]
>
>
> > Германн © (23.03.10 02:18) [14]
> >
> >
>
> см [8]
> <Цитата>
>
>

см. [14]

← →
Petr V. Abramov © (2010-03-23 02:28) [18]

> см. [14]

http://lurkmore.ru/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:Design
:)

← →
Petr V. Abramov © (2010-03-23 02:35) [19]

> Германн © (23.03.10 02:18) [14]

если между begin и end что-нить поместить, будет удобочитаемо, сам так делаю остальные чудаки.

← →
test © (2010-03-23 02:43) [20]

Германн © (23.03.10 02:18) [14]
Вот откуда ноги растут! В свое время из за такого стиля искал DelForEx.

← →
Германн © (2010-03-23 02:46) [21]

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

← →
Германн © (2010-03-23 02:49) [22]

> test © (23.03.10 02:43) [20]
>
> Германн © (23.03.10 02:18) [14]
> Вот откуда ноги растут! В свое время из за такого стиля
> искал DelForEx.
>

А зачем искал?
Чем не устроил сей стиль?
Имхо очень понятный стиль.

← →
Кто б сомневался © (2010-03-23 02:53) [23]

> Чем не устроил сей стиль?
> Имхо очень понятный стиль.

Стиль не устраивает тем, что
лучше

asdasd
begin
//...
end

чем :

asdasd
qweewq begin
..//
end

Т.к. в первом случае сразу видно блок кода, во втором его надо найти.

← →
Германн © (2010-03-23 02:59) [24]

> Кто б сомневался © (23.03.10 02:53) [23]
>
>

Пример не понял.

← →
Petr V. Abramov © (2010-03-23 03:01) [25]

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

← →
test © (2010-03-23 03:02) [26]

Германн © (23.03.10 02:49) [22]
Привычка читать/перечитывать VCL во время написания вместо справки, после этого стиля "на 14 сантиметров шире", читать VCL сходу не получается. В чем выгода то этого стиля? Кроме "чтобы шире на 14 сантиметров"?

← →
test © (2010-03-23 03:06) [27]

Германн © (23.03.10 02:59) [24]

if false then begin
if true then begin
else if true then begin
end
end

Правда прелестно?

← →
Кто б сомневался © (2010-03-23 03:08) [28]

> Пример не понял.

begin // ............. begin asdasdasd begin end; end; end

Блоки видны сразу. С тем методом такого нет, причем если if будет длинный, то begin уедет далеко.

end;

← →
Германн © (2010-03-23 03:16) [29]

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

← →
Petr V. Abramov © (2010-03-23 03:21) [30]

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

← →
Германн © (2010-03-23 03:33) [31]

> test © (23.03.10 03:06) [27]

Ты не в теме. Двухсимвольный отступ мною весьма приветствуется.

> Кто б сомневался © (23.03.10 03:08) [28]

if ... then begin
...
end;
Те же блоки. Вид сверху.

← →
Германн © (2010-03-23 03:39) [32]

Уже не рад, что ввязался в "дурной спор".
Давайте вернёмся к сабжу!

← →
TUser © (2010-03-23 07:24) [33]

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

var i: integer; s: string;

вместо

var i: integer; s: string;

Это также означает, что элементы, которые вовсе необязательно видеть, совсем не надо выделять. Так, не надо писать

var i: integer ; s: string ;

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

Выделенные в отдельную строку элементы, не требуемые для удобопонимания, это мусор. Будучи выделенными они только отвлекают внимание от действительно важных участков кода.

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

Посмотрите, как оформлен псевдокод в книгах Кормена (только отступы, вообще без скобок) и Ахо, Хопкрофта, Ульмана (begin не выносится в отдельную строку). Это - псевдокод, откуда специально убирается все, мешающее пониманию идеи. Оставляется только важное. У Вирта в первом издании - begin в новой строке, но в этой же строке идет код (что имхо, хуже всего, строки одного блока получаются с разным отступом). В Модуле он вообще убрал открывающие скобки из синтаксиса, аналогично сделано в VB. В Питоне, который сейчас резко набирает популярность, вообще - только отступы. Что приучает к хорошему стилю (ставить их) и не мозолит глаза лишними бегинами.

--

имхо

← →
brother © (2010-03-23 08:49) [34]

Ну, и мой оффтоп:
http://www.citforum.ru/programming/delphi/style_delphi/

← →
test © (2010-03-23 08:51) [35]

Германн © (23.03.10 03:33) [31]

>>Ты не в теме. Двухсимвольный отступ мною весьма приветствуется.

То есть чужой "стиль" ты не терпишь? Просто лень было, пробелы расставлять.

TUser © (23.03.10 07:24) [33]
Так уж вышло что VCL стиль пошел еще со времен Turbo Pascal.

← →
12 © (2010-03-23 08:55) [36]

http://jedicodeformat.sourceforge.net/index.html

A human can always produce better formatting than a program, but in many cases they don"t.

+ я не согласен с некоторыми вещами в jedicodeformat :)
хотя их можно и попальцам посчитать. Даже одной руки, даже инвалидной

← →
Дмитрий Белькевич (2010-03-23 10:52) [37]

> причем если if будет длинный, то begin уедет далеко.

Лечится модульностью.

> + я не согласен с некоторыми вещами в jedicodeformat :)

Там опций реально много. Настраивай как хочешь. В крайнем случае - даже сырцы есть. Напильник в руки...

← →
Rouse_ © (2010-03-23 12:40) [38]

Самая правильная ссылка :)
http://edn.embarcadero.com/article/10280

← →
Омлет © (2010-03-23 12:43) [39]

Где взять правильный JCFSettings.cfg для jedicodeformat?

← →
Кто б сомневался © (2010-03-23 13:00) [40]

> Те же блоки. Вид сверху.

Не те же.

if A = B then begin qweqwe asdasd if B=A and A=B then begin qweqwe if A-b then begin //.. end; asdasd end; asdasd qweqwe end; if A = B then begin qweqwe asdasd if B=A and A=B then begin qweqwe if A-b then begin //.. end; asdasd end; asdasd qweqwe end;

← →
Кто б сомневался © (2010-03-23 13:01) [41]

Второй код читается намного быстрее.

← →
Кто б сомневался © (2010-03-23 13:07) [42]

Когда Begin и End на одном уровне, сразу видишь блок, в отличии если begin и end на разных уровнях по горизонтали. нужно найти сначала Begin потом искать ближайший end - больше времени уходит на анализ.

← →
RWolf © (2010-03-23 13:17) [43]

блок и так видно, без поиска begin и end — он выделен отступом.
и да, первый вариант читабельнее. имхо, конечно.

← →
Кто б сомневался © (2010-03-23 13:17) [44]

Последние годы я в целом взял за правило писать код, который требует меньше анализа, не в ущерб оптимизации конечно же. N/к. отпимизация на первом месте.
К примеру я пишут приват и протектед переменные с маленькой буквой f.
fMyVar - это лучше чем с большой.
Все локальные переменные метода отмечаю прописной буквой - v. переменные в параметрах метода, с большой буквой A. Все это здорово помогает.

← →
Кто б сомневался © (2010-03-23 13:19) [45]

> и да, первый вариант читабельнее. имхо, конечно.

Менее читабельный, не надо спорить, я в свое время тоже также писал, потом перестал так делать, по этой же причине. дайте почитать человеку далекому от программирования, и спросите какой проще воспринимается.

← →
Кто б сомневался © (2010-03-23 13:23) [46]

> RWolf © (23.03.10 13:17) [43]

Мы читаем слева направо. Поэтому нам сначала надо найти слово begin. т.к. оно идет после выражения, то сначала приходится пробегать все выражение.
А если begin идет отдельной строкой, то это происходит быстрее.
Еще сложнее в плане парсинга языки в которых блок определяется скобкой (С - php итд ), все время напрягаешь зрение в поисках микроскобки.

← →
Anatoly Podgoretsky © (2010-03-23 14:03) [47]

> Кто б сомневался (23.03.2010 13:19:45) [45]

И ответ будет одинаковый, в обеих какая то абракадабра написана.

← →
Petr V. Abramov © (2010-03-23 14:10) [48]

> Мы читаем слева направо. Поэтому нам сначала надо найти
> слово begin. т.к. оно идет после выражения, то сначала
> приходится пробегать все выражение.

а слово begin искать нафик не надо, все отступами выделено.
тот же вариант без потери смысла на pl/sql:

if A = B then qweqwe; asdasd; if B=A and A=B then qweqwe; if A-b then //.. end if; asdasd; end if; asdasd; qweqwe; end if;

← →
TUser © (2010-03-23 14:11) [49]

А зачем человеку находить слово begin? Пусть компилятор ищет.

← →
test © (2010-03-23 15:25) [50]

TUser © (23.03.10 14:11) [49]
Человеку надо дописать/исправить код, тут одно из двух либо непривычно читать VCL и множество исходников Гугл, либо тяжело читать творения автора имярек. Он начинает читать, неудобно хотя автор как бы против все удобно и видно сразу, надо только на шкаф залезть. Еврит читаем в другую сторону, китайский сверху вниз, это тоже неудобства для тех кто читает по другому. Но подобные извороты в программировании, это мой стиль!

← →
Игорь Шевченко © (2010-03-23 16:05) [51]

> А зачем человеку находить слово begin? Пусть компилятор
> ищет.

Золотые слова. Пусть, гад, ищет:

procedure TApplication.WndProc (var Message: TMessage); type TInitTestLibrary = function(Size: DWord; PAutoClassInfo:Pointer ): Boolean; stdcall; var I: Integer; SaveFocus, TopWindow: HWnd; InitTestLibrary: TInitTestLibrary; procedure Default ; begin with Message do Result := DefWindowProc(FHandle,Msg, WParam, LParam);end; procedure DrawAppIcon; var DC :HDC; PS :TPaintStruct; begin with Message do begin DC := BeginPaint(FHandle, PS); DrawIcon(DC, 0, 0 , GetIconHandle) ; EndPaint ( FHandle, PS);end ; end ; begin try Message.Result := 0 ; for I := 0 to FWindowHooks. Count - 1 do if TWindowHook(FWindowHooks[I]^)(Message) then Exit ; CheckIniChange( Message); with Message do case Msg of WM_SYSCOMMAND: case WParam and $FFF0 of SC_MINIMIZE:Minimize;SC_RESTORE: Restore; else Default;end; WM_CLOSE: if MainForm<>nil then MainForm.Close;WM_PAINT: if IsIconic (FHandle ) then DrawAppIcon else Default ; WM_ERASEBKGND : begin Message.Msg := WM_ICONERASEBKGND; Default; end ; WM_QUERYDRAGICON : Result:= GetIconHandle; WM_SETFOCUS: begin PostMessage( FHandle , CM_ENTER,0,0);Default;end;WM_ACTIVATEAPP:begin Default; FActive := TWMActivateApp(Message).Active; if TWMActivateApp(Message ). Active then begin RestoreTopMosts; PostMessage(FHandle, CM_ACTIVATE, 0, 0) end else begin NormalizeTopMosts; PostMessage(FHandle,CM_DEACTIVATE, 0, 0); end; end; WM_ENABLE: if TWMEnable(Message).Enabled then begin if not DisablingWindows then begin RestoreTopMosts; if FWindowList<> nil then begin EnableTaskWindows(FWindowList);FWindowList:= nil;end; end;Default;end else begin Default; if (FWindowList = nil ) and not DisablingWindows then FWindowList :=DisableTaskWindows ( Handle); NormalizeAllTopMosts ; end; WM_CTLCOLORMSGBOX .. WM_CTLCOLORSTATIC: Result:=SendMessage(LParam,CN_BASE+Msg,WParam,LParam);WM_ENDSESSION: if TWMEndSession(Message).EndSession then begin CallTerminateProcs; Halt; end; WM_QUERYENDSESSION: Message.Result := 1; WM_COPYDATA: if (PCopyDataStruct(Message. lParam)^.dwData = DWORD ($DE534454 ) )and (FAllowTesting) then if FTestLib = 0 then begin {$IFDEF MSWINDOWS}FTestLib:=SafeLoadLibrary("vcltest3.dll");{$ENDIF} if FTestLib <> 0 then begin Result := 0; @InitTestLibrary := GetProcAddress(FTestLib, "RegisterAutomation"); if @InitTestLibrary <> nil then InitTestLibrary(PCopyDataStruct(Message.lParam)^.cbData, PCopyDataStruct(Message.lParam)^.lpData); end else begin Result := GetLastError ; FTestLib := 0 ;end ;end else Result := 0; CM_ACTIONEXECUTE , CM_ACTIONUPDATE : Message. Result := Ord ( DispatchAction( Message.Msg, TBasicAction ( Message. LParam ) )); CM_APPKEYDOWN: if IsShortCut( TWMKey(Message)) then Result := 1; CM_APPSYSCOMMAND:if MainForm<>nil then with MainForm do if(Handle <> 0) and IsWindowEnabled(Handle) and IsWindowVisible( Handle )then begin FocusMessages := False ; SaveFocus := GetFocus ;Windows. SetFocus(Handle); Perform(WM_SYSCOMMAND, WParam, LParam) ;Windows. SetFocus(SaveFocus); FocusMessages := True ;Result := 1 ;end; CM_ACTIVATE: if Assigned (FOnActivate )then FOnActivate(Self); WM_THEMECHANGED :ThemeServices. ApplyThemeChange ; WM_NULL: CheckSynchronize; else Default; end; except HandleException (Self); end; end;

← →
Jeer © (2010-03-23 16:25) [52]

Привык к такому стилю давно.

Поскольку на самом-то деле такой блок - это выделение if или if else,
то мне так удобнее визуально их просматривать.
Мой код никто кроме меня не читает, поэтому мне пофигу, кто и что об этом думает :)

if ( A = B) then begin
...
end; // if

if ( A = B ) then begin
...
end
else begin
..
end; // if

← →
test © (2010-03-23 16:43) [53]

Игорь Шевченко © (23.03.10 16:05) [51]
А какая экономия по стране в целом! А в мире!

Jeer © (23.03.10 16:25) [52]
Сейчас да, а потом?

← →
TUser © (2010-03-23 16:48) [54]

> Игорь Шевченко

Интересно, как народ на питонах пишет?

← →
test © (2010-03-23 16:53) [55]

TUser © (23.03.10 16:48) [54]
Видимо так же, вот на С свабода, только замшелые Pascal программисты единый стиль соблюдают и то не все. ))
Что делать когда часть книг по С, Python посвящены стилю, игнорировать и придумавать единственный и свой?

← →
TUser © (2010-03-23 16:55) [56]

> Видимо так же, вот на С свабода, только замшелые Pascal
> программисты единый стиль соблюдают и то не все. ))

Попробуйте в стиле [51] написать на питоне.

← →
test © (2010-03-23 16:57) [57]

TUser © (23.03.10 16:55) [56]
Там 3 == слово можно сравнивать думаешь мешанину покруче представленной там сложно изобразить?

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

TUser © (23.03.10 16:48) [54]

> Интересно, как народ на питонах пишет?

Руками

← →
TUser © (2010-03-23 17:12) [59]

> Там 3 == слово можно сравнивать

Мы про язык говорим или про оформление кода?

Желаю увидеть мешанину на питоне, круче, чем в 51. В смысле оформления, всяких там отступой и прочей красивости.

Не нравится питон, можете показать мешанину на VB, там нельзя 3==слово.

← →
TUser © (2010-03-23 17:12) [60]

> Игорь Шевченко

Наверное, несчастные, слезами обливаются, никак бегина в отдельной строчке найти не могут. :)

← →
test © (2010-03-23 17:16) [61]

TUser © (23.03.10 17:12) [59]
Вроде бы не раз уже обсуждали, пишешь для мамы на коленке пиши как хочешь, если пишется код который будут использовать коллеги, уважай коллег пиши как принято.

← →
Игорь Шевченко © (2010-03-23 17:21) [62]

TUser © (23.03.10 17:12) [60]

У каждого языка свой синтаксис, как тебе известно. Пишущие на APL или TCL тоже не могут найти begin, однако им это не мешает. Пишущие на С/С++/С#/Java тоже не могут найти begin, хотя там есть явные операторые скобки

← →
test © (2010-03-23 17:24) [63]

Игорь Шевченко © (23.03.10 17:21) [62]
И у каждого языка есть общепринятый стиль, в отношении С их даже несколько.

← →
TUser © (2010-03-23 17:39) [64]

> test © (23.03.10 17:16) [61]
>
> TUser © (23.03.10 17:12) [59]
> Вроде бы не раз уже обсуждали, пишешь для мамы на коленке
> пиши как хочешь, если пишется код который будут использовать
> коллеги, уважай коллег пиши как принято.

Собственно, против этого я не выступал. Стандарт, конечно, надо соблюдать, каков бы он ни был. А вот когда говорят "при прочтении такого кода чаще хочется выкинуть его" ([13]), то тут уже речь о том, что стандарт А лучше стандарта Б. В частности, вынесенный в отдельную строчку begin якобы лучше (удобнее, понятнее, как увидел begin, так сразу и понятно, что новый блок). Вот это мне кажется неверным - см. [33]. Могу повторить - глазами блок кода выделяется по отступам, а не по операторным скобкам. Вы же, читая код, мысленно дерево разбора не строите. Ну вот. А тогда лишняя строчка - просто лишняя информация, она отвлекает внимание от более важных вещей (да и занимает место на экране, между прочим).

> Игорь Шевченко

Довольно странно, что в [33] кто-то вообще видит призыв писать в стиле [51].

← →
test © (2010-03-23 17:46) [65]

TUser © (23.03.10 17:39) [64]
Тебе повезло не работать с этими супер кодерами со своим стилем, мне наоборот, поймешь когда встретишь. [51] тоже стиль автор художник он так видет.

← →
test © (2010-03-23 17:51) [66]

TUser © (23.03.10 17:39) [64]
Кстате переменные и функции матом звать тоже стиль!

← →
ProgRAMmer Dimonych © (2010-03-23 17:52) [67]

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

Если упрощённо, то вот так:

if <Условие> then <Оператор>[ else <Оператор>];

Конструкция состоит из ключевых слов if, then, else. Оператором может быть как простой, так и составной. Следовательно, операторная скобка begin синтаксически привязана к составному оператору, а не к оператору if. Да и по смыслу, вообще говоря, тоже: "Если выполняется условие <Такое-то>, то выполнить действие <ОченьСложное>, иначе выполнить действие <ДругоеСложное>". Блочный подход, если хотите. Есть подзадача, которую мы решаем по ветви then, и подзадача, решаемая по else. Эти подзадачи могут использоваться в любом другом месте программа. С минимальными изменениями, которые будут связаны с областью видимости переменных и т.п. вещами. С сам условные оператор - это более сложная подзадача - подзадача, связанная с принятием решения. Идёт в голову древовидная структура.

| Оператор_if_then_else / \ Оператор_по_then Оператор_по_else / \ / \

Аналогично для while и for:

while <Условие_входа> do <Оператор>; for <Переменная>:=<Значение1> [down]to <Значение2> do <Оператор>;

Иначе дело обстоит с repeat-until"ом:

repeat <Оператор1>; <Оператор2>; ... <ОператорN> until <Условие_выхода>;

Вот здесь уже действительно работает только отступ.

=====

Кстати, в bash"е, например, за отсутствием слова begin на отдельную строку выносят слово then:

if <Условие> then else fi

Можно и так, конечно:

if <Условие>; then else fi

Но здесь уже вмешивается точка с запятой, которая отделяет then от if. Т.е. это обходной путь, не более того. Так что для приведённых примеров, где упоминаются языки без операторных скобок, есть альтернативный вариант.

=====

Кстати, интересно, если мы решаем всё же писать begin в предыдущей строке, то теперь так писать, что ли?

procedure Foo; begin end;

Если нет, то почему?

← →
TUser © (2010-03-23 17:54) [68]

> [51] тоже стиль автор художник он так видет.

Любую идею можно довести до состояния абсолютного идиотизма. И хорошую тоже.

← →
Игорь Шевченко © (2010-03-23 18:04) [69]

TUser © (23.03.10 17:39) [64]

Я много лет писал в стиле K&R - отчасти от того, что первые 6 лет после железной машины только на С. Потом, когда стал писать одновременно и на паскале и на С, оставил за собой стиль K&R и в паскале. А с переходом на D2006 перешел на стиль Borland по одной простой причине - среда сама при code completion ставит операторыне скобки в стиле Borland. Ну не переформатировать же.

← →
TUser © (2010-03-23 18:19) [70]

> Операторные скобки - это часть составного оператора, а не
> синтаксическая конструкция условного оператора или операторов
> цикла.

Это так. Но пишут же

while (Result <> nil) and not Result.ShowHint do Result := Result.Parent;

и ничё.

> Кстати, интересно, если мы решаем всё же писать begin в
> предыдущей строке, то теперь так писать, что ли?
>
> procedure Foo; begin
> end;
>
> Если нет, то почему?

Я так не пишу. Почему - хз. Наверное, begin будет мешать разглядеть тип у функции (сразу в конце заголовка) :-)

← →
test © (2010-03-23 18:28) [71]

TUser © (23.03.10 17:54) [68]
Я уже задавал вопрос, в чем выгоды от if then begin where repeat end на одной строке, так и не ответили, в чем выгоды?

← →
TUser © (2010-03-23 18:31) [72]

> test © (23.03.10 18:28) [71]

> Поэтому, лишняя строка с одним словом begin только мешается, > прыгает в глаза, не сообщая никакой ценной (для человека) > информации.

← →
test © (2010-03-23 18:36) [73]

TUser © (23.03.10 18:31) [72]
Уже три или четыре отзыва по ветке что не видно где блок. Выгода для них в чем? Может это скрытие каких то особенностей?
Обфускация кода работает еще более эффективно.
Может просто обфускацию после написания проводить?

← →
Кто б сомневался © (2010-03-23 18:38) [74]

> Это так. Но пишут же
>
> while (Result <> nil) and not Result.ShowHint do Result
> := Result.Parent;
>
> и ничё.

Тут причина в другом, здесь будут проблемы при отладке этого кода.

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

if A=b then begin //код end

Равнозначно
if A=b then ------------- //код -------------

← →
ProgRAMmer Dimonych © (2010-03-23 18:48) [75]

> [74] Кто б сомневался © (23.03.10 18:38)

Не думаю, что это удачный аргумент. Всё-таки Pascal и его разновидности - это не только Delphi. И отображение исходника во время его редактирования - штука некросссредовая :)

А в приведённом примере есть одна особенность:

while (Result <> nil) and not Result.ShowHint do Result := Result.Parent;

Имеем целиком весь оператор в одной строке с "обрамляющим" его if"ом. Т.е. если заменять составным оператором, то эквивалентным кодом будет:

while <Условие> do begin OperatorPreved; OperatorMedved; OperatorEsche; OperatorHvatit; end;

Именно так, в одну строку. Т.к. иначе разрывается цельность составного оператора и, возвращаясь к одиночному оператору, получим что-то в духе:

while (Result <> nil) and not Result.ShowHint do Result := Result.Parent;

← →
Sergey Masloff (2010-03-23 18:50) [76]

Я на Delphi (если это не противоречило правилам команды) всегда писал

if something then begin

end

Розыч мне за пивом тыкал в нос руководством от тогда еще Борланда но я не внял. Все же на строчку меньше а ничему не мешает (в отличие от
if something then foo else bar;)

← →
TUser © (2010-03-23 18:56) [77]

Отлаживать, конечно, проще

while (Result <> nil) and not Result.ShowHint do
Result := Result.Parent;

а еще проще, наверное,

while Result <> nil do
with Result do
if ShowHint then
break
else Result := Parent;

// :)

← →
Игорь Шевченко © (2010-03-23 18:59) [78]

while Result<>nil do with Result do if ShowHint then break else Result:=Parent;

Так всяко лучше

← →
test © (2010-03-23 19:01) [79]

Авторы неповторимых стилей, продолжайте писать, мое отношение к такому коду выкинуть к чертовой матери.

← →
TUser © (2010-03-23 19:04) [80]

> Игорь Шевченко © (23.03.10 18:59) [78]

Убедили, буду писать так.

← →
Игорь Шевченко © (2010-03-23 19:06) [81]

TUser © (23.03.10 19:04) [80]

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

Он не хочет затянуть
Туже поясок.
Для него твои стихи -
Хлебушка кусок.

Ты пиши и мой призыв
Не сочти за лесть,
Потому что пародист
Тоже хочет есть!"

Александр Иванов

← →
Anatoly Podgoretsky © (2010-03-23 19:10) [82]

> Jeer (23.03.2010 16:25:52) [52]

Наш кадр!

← →
ProgRAMmer Dimonych © (2010-03-23 19:14) [83]

> [77] TUser © (23.03.10 18:56)
> while Result <> nil do
> with Result do
> if ShowHint then
> break
> else Result := Parent;
>
> // :)

Голосование проводить не будем, но, думается мне, всё же если уж одно пишется в строку (else Result:=Parent), то и другое тоже в строку гнать. Из соображений единства.

while Result <> nil do with Result do if ShowHint then break else Result := Parent;

Или наоборот: каждый с новой строки:

while Result <> nil do with Result do if ShowHint then break else Result := Parent;

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

while Result <> nil do with Result do if ShowHint then break else Result := Parent;

С точки зрения отступов логики нет никакой, но блоки then и else начинаются по одной границе (подчёркиваем их равноправие в смысле уровня вложенности в дереве кода). При этом, по-прежнему, не разрываются операторные блоки.

=====

Хотя в этом случае есть не менее красивое решение:

while Result <> nil do with Result do begin if ShowHint then break; Result := Parent; end;

Появление begin-end погоды не сделает, а с читаемостью этого конкретного фрагмента кода станет попроще.

Или вариант, который я сам часто использую. Такой "if с аппендицитом".

while Result <> nil do with Result do if not(ShowHint) then Result:=Parent else break;

К else break привыкнуть не особенно сложно, а при просмотре кода этот кусочек кода уже не отвлекает от основной логики программы. Этакий "ненужный аппендикс".

← →
Игорь Шевченко © (2010-03-23 20:17) [84]

> Голосование проводить не будем

Каждый пишет, как он хочет. Если нет корпоративных стандартов. Если они есть, каждый тоже может писать, как он хочет. Но недолго.

← →
Кто б сомневался © (2010-03-23 20:22) [85]

Насчет писать в одну строку, тут надо руководствоваться здравомыслием.
Но, там где отладка не нужна, (break, exit, contrinue) - т.к. без нее видно куда пойдет трасса.
CodeGear тоже так делают , не раз встречал.

if A> B then break; (или exit\abort итп) - часто так делаю.

А вот такое
if not(ShowHint) then Result:= Parent else break;

Понятно что так только нубы (новички) пишут. С отладкой здесь будут большие проблемы

← →
TUser © (2010-03-23 20:53) [86]

> С отладкой здесь будут большие проблемы

С другой стороны, если уверен на 99,9%, что проблем с отладкой именно в этом месте не будет, то в чем трудность? А если вдруг очень захочется (что вряд ли), то и лишний энтер вставить не долго.

← →
ProgRAMmer Dimonych © (2010-03-23 20:58) [87]

> Насчет писать в одну строку, тут надо руководствоваться
> здравомыслием.

Золотые слова. Именно поэтому:
>если суть выполняемого действия очевидна и читается из контекста

> Понятно что так только нубы (новички) пишут. С отладкой
> здесь будут большие проблемы

Разве что с точки зрения пошагового выполнения. Код, поверх которого пришлось мастерить этот пример, не самый удачный случай применения этого приёма. Хотя бы из-за того, что используется with. Скажу по секрету, я даже в какой-то момент вообще упустил его из виду и подумал было, что цикл имеет шанс бесконечно выполняться, т.к. Parent, вроде бы нигде не меняется. К тому же, постоянную проверку ShowHint из цикла в том конкретном случае вообще лучше вынести наружу. Если же в такой if много логики не вкладывается, то свернуть в одну строку, чтобы перед глазами не путалось, вполне можно.

i:=0; while i<100 do if VasyaPupkinStillAlive[i] then Inc(i) else break;

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

Хотя, конечно, приём далеко не для повсеместного использования.

← →
Anatoly Podgoretsky © (2010-03-23 21:09) [88]

> ProgRAMmer Dimonych (23.03.2010 20:58:27) [87]

> Человек - он не по буквам читает, а слово целиком

Учись читать по странично

← →
ProgRAMmer Dimonych © (2010-03-23 21:21) [89]

> [88] Anatoly Podgoretsky © (23.03.10 21:09)
> Учись читать по странично

Хотите об этом поговорить?

При чтении текста заучивания наизусть не происходит (ну, разве что кроме очень запущенных случаев). Посему слова пропускаются через т.н. кратковременную память. Имеющую ограниченную ёмкость. «Волшебное число 7±2» сие называлось, в исполнении Джорджа Миллера. Реально - от 3 до 7 в завимости от тренированности памяти. Это касательно того, сколько различных однородных объектов может удержать человек в кратковременной памяти без многократного повторения. Слов, например...

В приведённом примере 6-7 понятий более чем достаточно, чтобы уловить смысл:

Если Васяжив, То Увеличить, Иначе "Бряк"

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

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

А речь ведь шла только о том, чтобы не читать побуквенно.

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

ProgRAMmer Dimonych © (23.03.10 21:21) [89]

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

> При чтении текста заучивания наизусть не происходит (ну,
> разве что кроме очень запущенных случаев).

Ты код учишь наизусть ?

← →
ProgRAMmer Dimonych © (2010-03-23 21:34) [91]

> [90] Игорь Шевченко © (23.03.10 21:25)

> Я код по словам не читаю. Ну то есть совсем. Я, если так
> можно сказать, читаю конструкциями.

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

> И для подобного чтения стиль довольно важен, так как на
> непривычном стиле чтение спотыкается.

Вижу неприятное противоречие.

> Каждый пишет, как он хочет. Если нет корпоративных стандартов.

Получается, когда стандарт диктует непривычный стиль, то чтение будет спотыкаться. Так что это, увы, бывает и приходится мириться. Если брать ныне обсасываемый приём, то здесь действительно можно спотыкаться с непривычки. При повальном применении где ни попадя. В остальных случаях это будет ощущение из разряда "вроде всё как обычно, но почему-то чувствую, что этот код не мною писан".

> > При чтении текста заучивания наизусть не происходит (ну,
> > разве что кроме очень запущенных случаев).
> Ты код учишь наизусть ?

Хде это я такое написал?

← →
Кто б сомневался © (2010-03-23 21:41) [92]

> TUser © (23.03.10 20:53) [86]
>
>
> > С отладкой здесь будут большие проблемы
>
> С другой стороны, если уверен на 99,9%, что проблем с отладкой
> именно в этом месте не будет, то в чем трудность? А если
> вдруг очень захочется (что вряд ли), то и лишний энтер вставить
> не долго.

Ты не понял. Дело не в логической ошибке.
А к примеру нужно просмотреть переменную на этом этапе.

← →
ProgRAMmer Dimonych © (2010-03-23 21:44) [93]

> [92] Кто б сомневался © (23.03.10 21:41)

> TUser © (23.03.10 20:53) [86]
> если уверен на 99,9%, что проблем с отладкой
> именно в этом месте не будет

Никто не заставляет пользоваться этим на каждом шагу.

← →
Игорь Шевченко © (2010-03-23 21:54) [94]

ProgRAMmer Dimonych © (23.03.10 21:34) [91]

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

Не надо проводить такие параллели, совершенно разные вещи.

> Вижу неприятное противоречие.

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

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

← →
Leonid Troyanovsky © (2010-03-23 22:04) [95]

> ProgRAMmer Dimonych © (23.03.10 19:14) [83]

> Хотя в этом случае есть не менее красивое решение:
>
> while Result <> nil do
> with Result do
> begin
> if ShowHint then break;
> Result := Parent;
> end;

while Result <> nil do with Result do begin if ShowHint then break else begin DoSomethingAlso; Exit; end; Result := Parent; end;
--
Regards, LVT.

← →
ProgRAMmer Dimonych © (2010-03-23 22:12) [96]

> [94] Игорь Шевченко © (23.03.10 21:54)
> Не надо проводить такие параллели, совершенно разные вещи.

А нейроны-то и не знают.

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

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

← →
ProgRAMmer Dimonych © (2010-03-23 22:15) [97]

> [95] Leonid Troyanovsky © (23.03.10 22:04)

Эм-м-м... Шутка? Result := Parent не выполнится ведь, кажется...

← →
Игорь Шевченко © (2010-03-23 22:17) [98]

ProgRAMmer Dimonych © (23.03.10 22:12) [96]

> А нейроны-то и не знают.

Нейроны и не читают текст программы как текст на естественном языке.

> Просто есть ведь случаи, когда просто идёт условно-опасное
> сворачивание кода

Еще что-то успели объявить considered harmful, а я пропустил ?

> А есть случаи, когда имеется (никого из присутствующих не
> хочу задеть) код, демонстрирующий недостаточное осознание
> идей, лежащих в основе синтаксиса

А если зайти в "Начинающие", там столько случаев, демонстрирующих...

← →
Leonid Troyanovsky © (2010-03-23 22:21) [99]

> Leonid Troyanovsky © (23.03.10 22:04) [95]

Ну, это в смысле 2 пробелов, бо правила передачи оных форумом
я до сих пор не заучил.

Т.е., надеюсь, что основную мысль передал:
блоки размещаем также, как и одиночные операторы,
(+ учет уровня begin-end).

Хотя, сразу проявляется эстетический косяк if,
бо ему не хватает endif.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2010-03-23 22:29) [100]

> ProgRAMmer Dimonych © (23.03.10 22:15) [97]

А в чем сомнения? Вроде бы, двоеточия нет.

Хотя, конечно, пишу прям здесь, т.е.,
бумага из дерева, а машина - железная.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2010-03-23 22:34) [101]

> Leonid Troyanovsky © (23.03.10 22:29) [100]
>
> > ProgRAMmer Dimonych © (23.03.10 22:15) [97]

А.., понял-понял. Где Break, там и Exit ;)
Думал лишь про иллюстрацию.
Sorry.

--
Regards, LVT.

← →
ProgRAMmer Dimonych © (2010-03-23 22:46) [102]

> [99] Leonid Troyanovsky © (23.03.10 22:21)
> Т.е., надеюсь, что основную мысль передал:
> блоки размещаем также, как и одиночные операторы,
> (+ учет уровня begin-end).
>
> Хотя, сразу проявляется эстетический косяк if,
> бо ему не хватает endif.

Ну, переучиваться-то уж точно неприятно будет, если надумаются добавить. :)

Кстати, если уж об отступах, то здесь предпочитаю begin-end отдельно не сносить. Чтобы само содержимое составного блока не уподоблять операторным скобкам. Т.е. фактически отступу у меня обычно подвергаются только простые операторы, входящие в составной, но не сам составной. Из плюсов лично для меня (т.е. IMHO) даёт то, что программа не уезжает далеко вправо. Хотя при правильном разбиении на процедуры/модули это и некритично.

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

← →
Германн © (2010-03-23 23:00) [103]

> Ну, переучиваться-то уж точно неприятно будет, если надумаются
> добавить. :)
>

Ничего подобного! Мне пары дней хватило, чтобы привыкнуть. :)

← →
ProgRAMmer Dimonych © (2010-03-23 23:12) [104]

> [103] Германн © (23.03.10 23:00)

Я не в теме :(

← →
Leonid Troyanovsky © (2010-03-23 23:25) [105]

> ProgRAMmer Dimonych © (23.03.10 22:46) [102]

> и в пользу предложенного Вами варианта. Познание альтернативы
> ещё никому не вредило,

На особые аргументы сослаться не могу.

Лет несколько назад за написанием мной кода наблюдал один уважаемый
(мной) сишник и обратил мое внимание на несогласованность написания некторых языковых конструкций.

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

Хотя, они и не всегда соответствуют пожеланиям, скажем C.Calvert,
хотя я его сильно уважаю.

И еще.
Не помню, кто первый это отметил, но более важным является
не применяемое правило, а пунктуальность в его применении.
Бо, я легко читаю коды by C.Calvert or P.Below, хотя они и отличны
от моего написания.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2010-03-23 23:36) [106]

> ProgRAMmer Dimonych © (23.03.10 22:46) [102]

> для меня (т.е. IMHO) даёт то, что программа не уезжает далеко
> вправо. Хотя при правильном разбиении на процедуры/модули
> это и некритично.

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

- Что-то не сложилось, подумал Штирлиц...

--
Regards, LVT.

← →
ProgRAMmer Dimonych © (2010-03-23 23:48) [107]

> [106] Leonid Troyanovsky © (23.03.10 23:36)
> Если уезжает далеко и я не могу оное исправить известными
> мне легальными способами, то я начинаю думать об
> ошибке поектирования.

Ну вот как раз это я и имел в виду, когда упоминал про процедуры/модули.

← →
Германн © (2010-03-23 23:55) [108]

> ProgRAMmer Dimonych © (23.03.10 23:12) [104]
>
> > [103] Германн © (23.03.10 23:00)
>
> Я не в теме :(
>

http://www.3s-software.com/index.shtml?ru_ru_ST

← →
Leonid Troyanovsky © (2010-03-24 00:06) [109]

> ProgRAMmer Dimonych © (23.03.10 23:48) [107]

> > ошибке поектирования.

> Ну вот как раз это я и имел в виду, когда упоминал про процедуры/модули.

Вот этот феномен любопытен.
Никто же не препятствует передвинуть Right Margin на пару символов.
И нынешние мониторы это позволят.

Но, делать это западло, бо предыдущее поколение как-то умудрилось :)

--
Regards, LVT.

← →
ProgRAMmer Dimonych © (2010-03-24 00:06) [110]

> [108] Германн © (23.03.10 23:55)

Теперь понял. Интересная идея.

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

> Но, делать это западло, бо предыдущее поколение как-то умудрилось
> :)

у предыдущего поколения были перфокарты размеров в 80 колонок и алфавитно-цифровой терминал размером 80х24, а кому повезет, 80х25.
И за каждой дыркой на перфокарте приходилось идти на поклон к перфоратору, а там очередь, на 5 километров. В гору. А на алфавитно-цифровой на месяц вперед записывались. И ничего, шедевры творили, не чета нынешнему племени.

← →
Petr V. Abramov © (2010-03-24 01:31) [112]

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

да эти ваши шедевры на первом курсе проходят
:)))

← →
Eraser © (2010-03-24 02:07) [113]

в таких спорах мне всегда интересно кто как конструкцию case of else пишет ;-)

← →
Германн © (2010-03-24 02:24) [114]

> Petr V. Abramov © (24.03.10 01:31) [112]
>
>
> > Игорь Шевченко © (24.03.10 00:45) [111]
> >
> >
>
> да эти ваши шедевры на первом курсе проходят

Заметь, Петя, что написание этих шедевров стоило многих поклонов к "перфораторщицам", плюс многих очередей не только на "алфавитно-цифровой, но и на обычную ЕС с той самой колодой. И плюс пришлось многим изучить язык дырочек на перфокартах. Ибо опечатки девочек-перфораторщиц стоили очень дорого! Ибо время - самое дорогое!
:)

← →
Германн © (2010-03-24 02:32) [115]

> Eraser © (24.03.10 02:07) [113]

case I of 1 : begin sms; sms; end; 2 : sms; else sms; end;
Мой вариант.

← →
Германн © (2010-03-24 02:35) [116]

> Германн © (24.03.10 02:32) [115]

Я как и LVT до сих пор не могу освоить количество пробелов в постах на ДМ. Прошу в моём примере считать каждый пробел за два.

← →
Германн © (2010-03-24 02:54) [117]

> Германн © (24.03.10 02:32) [115]

Расширенный вариант:
case sms of 1 : begin sms; sms; end; 2 : if sms then begin sms; sms; end; 3 : if sms then sms; 4 : sms; else [begin] sms; {sms; end;]

> Германн © (24.03.10 02:54) [117]

Читать так:
case sms of 1 : begin sms; sms; end; 2 : if sms then begin sms; sms; end; 3 : if sms then sms; 4 : sms; else [begin] sms; [sms;] end;

> ProgRAMmer Dimonych (23.03.2010 22:46:42) [102]

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

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

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

> Германн (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;

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

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

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

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

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

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

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

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

> [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 :(

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

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

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

> [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 надо отказаться (есть задачи, куда они просто напрашиваются), но избегать имеет смысл. Благо это всегда возможно.

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

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

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

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, чем искать оптимальный вариант.
> Который для каждого конкретного случая будет своим. А это
> означает, что единого стиля в коде не будет.

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

> [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 придётся как-то.

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.

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

> 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 это программистозависимо, не знаю...

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

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

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

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

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

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

> [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". Опять приходим к границам применимости :(

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-овским компилятором С - может, он еще более оптимален.

> [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 массивом указателей, наверное, следует признать достаточно редким. Да и сдаётся мне, что применить это можно красиво в той части кода, которая обеспечивает пользовательский интерфейс. А там скорость выполнения не слишком критична.

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

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

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

TUser © (25.03.10 10:03) [141]

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

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

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

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

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

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

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

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

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

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

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

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

IMHO.

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

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

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

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

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

> 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"а обнаружится ещё при компиляции.

>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]

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

> тебе эта истина поведана свыше ?

Апокалипсис, блин. :)

> [161] Игорь Шевченко © (25.03.10 19:52)
> мотивируют тем, что проще добавлять/убирать условие

И в этом есть разумное зерно. IMHO. Вроде ещё пока не очень старовер :)

> Игорь Шевченко © (25.03.10 19:08) [156]
> а вот часть программистов пишет так:
> if <часть длинного условия1>
> and <часть длинного условия2>
> and <часть длинного условия3> then
> begin
> Операторы....
> end;

Кстати, я так пишу, хотя и на другом языке. Для Delphi я бы даже такой вариант предложил:
if <условие1> and <условие2> and <условие3> then begin <операторы> end else begin <операторы> end;

Преимущества:
1. легко добавляются/удаляются/комментируются условия (кроме первого);
2. begin не теряется за правым краем экрана;
3. begin не "мозолит" глаза в начале отдельной строки;
4. then находится на том же уровне, что и else;
5. трёхстрочная конструкция (у тех, кто так пишет)
end else begin
уменьшается до двух строк.

> Кстати, я так пишу, хотя и на другом языке. Для Delphi я
> бы даже такой вариант предложил:
> if <условие1>
> and <условие2>
> and <условие3>
> then begin
> <операторы>
> end
> else begin
> <операторы>
> end;
>

Недостатки (для меня лично)
1. end else восприниманию только на одной и той же строчке.
end расположенный на отдельной строке - должен полностью заканчивать любой сложный оператор.
2. Сложное булево выражение не должно иметь сдвига ни в одной своей строке. Тогда оно легко (для меня) рассматривается как именно одно.

Это моё скромное имхо.

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

> тебе эта истина поведана свыше ? :)

Наверное.
Увидел во сне :)

--
Regards, LVT.

> [165] Германн © (26.03.10 02:09)
> end расположенный на отдельной строке - должен полностью
> заканчивать любой сложный оператор

Он и заканчивает. Составной оператор.

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