Люди, которые пишут begin..end вокруг одного оператора

← →
Котик Б (2012-12-13 20:31) [80]

А мне вообще ни
begin ... end
ни
{ ... }
не нравятся.

Повбьівав бьі...

Каждьій фрагмент кода должен иметь явное начало и явное окончание:
IF ... ENDIF
DO ... ENDDO
LOOP ... ENDLOOP
SELECT ... ENDSELECT

← →
Игорь Шевченко © (2012-12-13 20:47) [81]

O"ShinW © (13.12.12 19:32) [79]

Ты сам предложил убить тебя, потому что тебе непонятна конструкция +=

Тебя никто не принуждал :)

← →
Rouse_ © (2012-12-13 21:02) [82]

> O"ShinW © (13.12.12 17:49) [74]
> ь :)
>
> чем это s += j лучше, чем s = s + j - непонятно

Ну например тем, что можно написать вот так i += ++i+i++; и оно даже скомпилится :)

← →
Игорь Шевченко © (2012-12-13 21:46) [83]

Rouse_ © (13.12.12 21:02) [82]

Я начинаю всерьез думать о создании движения за лишение гражданских свобод программистов, пишущих подобный код :)

← →
Rouse_ © (2012-12-13 21:52) [84]

> Игорь Шевченко © (13.12.12 21:46) [83]

- Ведьму сжечь!
- Но она же такая красивая...
- Ну хорошо, но потом - сжечь!!!

В принципе это еще не так страшно (хоть и будет давать различный результат в зависимости от компилера) но вот что делать с индусским и китайским кодом? :))

← →
TUser © (2012-12-13 22:08) [85]

Надо эту ветку в СК отнести, на предмет проверки по 282 статье.

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

%)

← →
Inovet © (2012-12-13 22:09) [86]

> [74] O"ShinW © (13.12.12 17:49)
> непонятно. Вообще. И никогда не будет, хоть убейте.

Тем, что понятнее.

← →
O'ShinW © (2012-12-13 22:24) [87]

> i += ++i+i++

ёёё..

> Игорь Шевченко
вот теперь - пора :)

← →
TUser © (2012-12-13 22:35) [88]

> i += ++i+i++

Если не ошибаюсь, в брейнфаке символа i нет.

← →
Inovet © (2012-12-13 23:04) [89]

> [82] Rouse_ © (13.12.12 21:02)
> i += ++i+i++;

Во-первых пробелы лишние, так читабелнее
i+=++i+i++;
Во-вторых мало действий - некомпактно, читай [0]. Надо как можно больше в один оператор вкладывать.
*i+++=--*i+++*i--+*--i-*i++;

← →
Inovet © (2012-12-13 23:15) [90]

> [89] Inovet © (13.12.12 23:04)
> *i+++=--*i+++*i--+*--i-*i++;

Ну и, чтобы огород не городит из скобок и строк литшних, ещё вот так
*i---=*i---=*i+++=*i+++=--*i+++*i--+*--i-*i++;

← →
Дмитрий С © (2012-12-13 23:46) [91]

\
> ++i+i++

Это все равно что в скриптовых языках:
if ( !condition1 && condition2)

← →
Inovet © (2012-12-13 23:56) [92]

> [91] Дмитрий С © (13.12.12 23:46)
> if ( !condition1 && condition2)

А что не так с этим выражением? Последовательность вычисления неопределена?

← →
KilkennyCat © (2012-12-14 00:18) [93]

скоро будут спецпсихиатры. для программистов ;)

← →
Дмитрий С © (2012-12-14 03:56) [94]

> А что не так с этим выражением? Последовательность вычисления
> неопределена?

Однозначно нельзя сказать к чему ! относится.

← →
Inovet © (2012-12-14 04:21) [95]

> [94] Дмитрий С © (14.12.12 03:56)
> Однозначно нельзя сказать к чему ! относится.

А как же приоритеты операций?

← →
RWolf © (2012-12-14 09:29) [96]

> [94]

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

← →
Игорь Шевченко © (2012-12-14 10:33) [97]

RWolf © (14.12.12 09:29) [96]

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

Если бы ты работал у меня, был бы хороший повод для увольнения.

← →
Компромисс1 (2012-12-14 11:49) [98]

For example : if a = 7 then do Inc(b, a); Is better written : if a = 7 then do begin Inc(b, a); end; for maintenance purposes.

http://www.delphibasics.co.uk/RTL.asp?Name=Begin

← →
Компромисс1 (2012-12-14 11:53) [99]

> чем это s += j лучше, чем s = s + j - непонятно

А так?

myReallyLongArray[calculateArrayIndex(i,j,k)] += getTargetIndex(user) - getFirstIndex(page);

← →
RWolf © (2012-12-14 13:25) [100]

> [97]

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

← →
Игорь Шевченко © (2012-12-14 13:44) [101]

RWolf © (14.12.12 13:25) [100]

Ясность лучше мастерства.

"Поскольку обслуживание является важным и дорогостоящим, следует писать такие программы, как если бы обмен наиболее важной информацией, осуществляемый программой, был связан не с компьютером, выполняющим данную программу, а с людьми, которые будут читать и поддерживать исходный код в будущем"

Эрик Реймонд, "Искусство программирования для UNIX"

← →
Игорь Шевченко © (2012-12-14 13:45) [102]

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

Месье эксперт в кадровой политике ? Могу взять online-уроки ?

← →
RWolf © (2012-12-14 14:01) [103]

> [101]

ни в коей мере не навязывая своё мнение относительно кадровой политики, настаиваю, тем не менее, что выражение !a && b читается лучше, чем (!a) && b.
если у гипотетического кодера, поддерживающего некий код, возникают затруднения при чтении таких выражений, значит, он прогуливал арифметику и булеву алгебру, вот и всё.

← →
TUser © (2012-12-14 14:06) [104]

> если у гипотетического кодера, поддерживающего некий код,
> возникают затруднения при чтении таких выражений, значит,
> он прогуливал арифметику и булеву алгебру, вот и всё.

угу, а если он не понимает, почему дельфя ругается на
a = b and c = d
значит паскаль прогуливал, и вообще, кодер должен помнить приоритет операций во всех языках на свете, а то кому-то скобки поставить лень

← →
RWolf © (2012-12-14 14:13) [105]

> [104]
> угу, а если он не понимает, почему дельфя ругается на a = b and c = d
> значит паскаль прогуливал,

это очевидно.

> и вообще, кодер должен помнить приоритет операций во всех языках на свете,

не всех, а тех, на которых пишет.
и не помнить, а знать — это в подсознании должно сидеть.
чтобы даже мыслей вроде «а какая операция в 2+2*2 выполнится раньше» не возникало.

> а то кому-то скобки поставить лень

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

← →
Игорь Шевченко © (2012-12-14 14:33) [106]

RWolf © (14.12.12 14:13) [105]

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

так в том и вопрос, как отличить одно от другого :)

вот пример (PL/SQL)

If vRow.BARFOO_NR <> 0 and vRow.S_A_NR <> (v_A_NR+vt_A_NR) Or vRow.S_B_NR <> (v_B_NR+vt_B_NR) Or vRow.S_C_NR <> (v_C_NR+vt_C_NR) Or vRow.S_Foo <> (v_Foo + vt_FOO ) Or vRow.S_BAR <> (v_BAR + vt_BAR ) Or vRow.S_FOOBAR <> (v_FOOBAR + vt_FOOBAR ) Or vRow.S_BARFOO <> (v_BARFOO+ vt_BARFOO) then

Я без скобок при первом прочтении не могу понять смысл (не приоритет, а смысл) условного оператора, несмотря на то, что с PL/SQL общаюсь больше 20 лет.

← →
Аббат Пиккола (2012-12-14 14:59) [107]

2 Игорь Шевченко © (14.12.12 14:33) [106]

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

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

Те, кто использует множество языков, предпочитает, к примеру, сразу заключать логическое выражения после if целком в скобки:

if () then.

А тот, кто использует в основном один язык постоянно, к примеру, Pascal, не видит никакого смысла в этом.

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

← →
RWolf © (2012-12-14 15:07) [108]

> [106]

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

← →
Аббат Пиккола (2012-12-14 15:23) [109]

Операторы and, or, not в паскале позволяют работать как с логическими выражениями так и с множествами. В языках, не имеющих типа "множество" этого применения для логических операторов не предусмотрено. Еще в паскале можно использовать эти операторы для побитовых операций над целыми байтами и словами. Это может вызвать затруднения при зрительной интерпретации выражений, в которых мы еще не знаем типов переменных, но которые уже попались нам на глаза.

Что же касается лишних begin end...

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

Знаю по себе.

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

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

← →
Аббат Пиккола (2012-12-14 15:25) [110]

RWolf © (14.12.12 15:07) [108]

> бессмысленные названия идентификаторов, подчёркивания в
> именах тоже добавляют шума

Идентификаторы осмысленные, имена намерено искажены
Подчеркивание - это культура PL/SQL
Скажу сразу, что со скобками мне было бы проще понять.

Аббат Пиккола (14.12.12 14:59) [107]

Мне трудно сказать о трудностях переключения, я легко переключаюсь с C на Pascal на C# на PL/SQL

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

← →
Аббат Пиккола (2012-12-14 15:43) [112]

2 Игорь Шевченко © (14.12.12 15:36) [111]

Не очень понял, о чем речь про пустые ().

Вот это код чем-то некультурный?

function TCustomForm.HandleCreateException: Boolean;
begin
Application.HandleException(Self);
Result := True;
end;

Или Вы о чем-то ином?

← →
Аббат Пиккола (2012-12-14 15:44) [113]

Пардон, наоборот понял

← →
Аббат Пиккола (2012-12-14 15:47) [114]

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

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

возможно, это
> If vRow.BARFOO_NR <> 0 and
> vRow.S_A_NR <> (v_A_NR+vt_A_NR) Or
> vRow.S_B_NR <> (v_B_NR+vt_B_NR) Or
> vRow.S_C_NR <> (v_C_NR+vt_C_NR) Or
> vRow.S_Foo <> (v_Foo + vt_FOO ) Or
> vRow.S_BAR <> (v_BAR + vt_BAR ) Or
> vRow.S_FOOBAR <> (v_FOOBAR + vt_FOOBAR
> ) Or
> vRow.S_BARFOO <> (v_BARFOO+ vt_BARFOO)
>
> then

я бы так написал

If 1=0 or vRow.BARFOO_NR <> 0 and vRow.S_A_NR <> (v_A_NR+vt_A_NR) or vRow.S_B_NR <> (v_B_NR+vt_B_NR) or vRow.S_C_NR <> (v_C_NR+vt_C_NR) or vRow.S_Foo <> (v_Foo + vt_FOO ) or ... then

мне кажется, так понятнее:
или это и это
или это
или это
или это

ну и "1=0" - что бы было единообразно.
и как писал как-то, любую строчку комментируем при отладке
и все продолжает работать. Без дополнительных телодвижений

← →
Аббат Пиккола (2012-12-14 15:55) [116]

2 O"ShinW © (14.12.12 15:51) [115]

Я так и пишу, только если мне нужна именно возможность закомментировать любую строчку.
Если такая возможность не нужна, пишу оператор в конце строки и никаких 1=0.

> Аббат Пиккола (14.12.12 15:55) [116]

когда что -то напишешь, потом пару дней преследует чувство, что лажа :)
Особенно когда начинается.. позвонят/прибегут с выпученными глазами "все неправильно!"
Потом, когда оно заработает - да, лучше убрать

Вот прямо только что нашел у себя

case EdgeType of etIncluded: begin end; etContacted: begin if Contact is TSheetSheetContact then with TSheetSheetContact (Contact) do result := result + GetSideDescript (Sides[i], FirstIndexInContact <> i) + GetSideDescript (Sides[1-i], FirstIndexInContact = i) else // if Contact is TSheetSheetContact then with TSheetHelixesContact (Contact) do result := result + GetSideDescript (Side, FirstIndexInContact <> i) + GetSideDescript (sideUnknown, FirstIndexInContact = i); if Contact.WeakOrStrong then result := result + " style = dashed "; end; else result := result + GetSideDescript (sideUnknown, true); end;

> я бы так написал
>
> If 1=0

Не позорься

Rouse_ © (13.12.12 21:02) [82]

> O"ShinW © (13.12.12 17:49) [74]
> ь :)
>
> чем это s += j лучше, чем s = s + j - непонятно

Ну например тем, что можно написать вот так i += ++i+i++; и оно даже скомпилится :)

Жуть какая! Это не Вам, а тем, кто так пишет.

Игорь Шевченко © (13.12.12 21:46) [83]

Я начинаю всерьез думать о создании движения за лишение гражданских свобод программистов, пишущих подобный код :)

Игорь, ты стал очень категоричным в своих утверждениях. :) А как же "овощь..."?

RWolf © (14.12.12 09:29) [96]

> [94]

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

Дело не в том, сколько кодер тратит времени на чтение конструкции. Дело в том, что эту конструкцию за время жизни кода прочитает еще "мульюн" кодеров. Конструкция должна читаться, а не пониматься.

Игорь Шевченко © (14.12.12 15:36) [111]

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

Хорошо и понятно сказано. Аналогия - общение с неносителем языка.

Люди, которые пишут begin..end вокруг одного оператора Найти похожие ветки