Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Delphi Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 9 [10] 11   вперед  Ctrl      все
 Re: Флейм про оформление и begin-end  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 62803
YuRock> Ну да, я живу в такой реальности

Перечитай ещё раз внимательно, что и на что ты отвечал.
Но да, проще продолжать упорствовать и вещать про уровни.

Posted via ActualForum NNTP Server 1.5

1 май 21, 11:03    [22317164]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
JayDi
Member

Откуда: Сызрань, Россия
Сообщений: 4193
Откровенно говоря волосы на голове шевелились, когда читал этот топик. Есть же стандарт форматирования делфи-кода (что от самой эмбаркадеры, что от каких-нибудь jvcl -- разница минимальна). Но народ все-равно упорно отказывается его соблюдать, и каждый придумывает свой собственный стиль. Зачем?
1 май 21, 12:39    [22317188]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
asutp2
Member

Откуда: Тюмень
Сообщений: 852
JayDi,

если было бы всё так просто. В так называемом стандарте форматирования кода от самой эмбы нет ни слова об использовании допустим тех же {$REGION} или той же XML-документации. Хотя сама же Эмба в новых модулях их использует, причем одни модули оформлены в одном стиле, в других в другом и т.д.
1 май 21, 12:44    [22317189]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
rgreat
Member

Откуда:
Сообщений: 6709
JayDi
каждый придумывает свой собственный стиль. Зачем?

Потому что это вкусовщина.
1 май 21, 12:57    [22317193]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
asutp2
Member

Откуда: Тюмень
Сообщений: 852
вот пример требования из Object Pascal Style Guide от Эмбы:
автор
The exception to the Hungarian notation rule is in enumerated types.

TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp,
bkYes, bkNo, bkClose, bkAbort, bkRetry,
bkIgnore, bkAll);

In this case the letters bk are inserted before each element of this enumeration. bk stands for ButtonKind.
Устаревшее требование, сейчас как раз никаких добавлений вида bk быть не должно принципиально
1 май 21, 12:58    [22317194]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 62803
JayDi> Зачем?

1. Стандартов может быть (и есть) больше одного.
2. Стандарт оформления - это, как правило, рекомендация, а не догма.
3. Кому-то какой-то стандарт может не нравиться/быть неудобным.

Posted via ActualForum NNTP Server 1.5

1 май 21, 12:59    [22317195]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 62803
> 1. Стандартов может быть (и есть) больше одного.

1.1. Стандарт (даже одного авторства) может меняться со временем.

Posted via ActualForum NNTP Server 1.5

1 май 21, 13:00    [22317197]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
alekcvp
Member

Откуда:
Сообщений: 2870
asutp2
Устаревшее требование, сейчас как раз никаких добавлений вида bk быть не должно принципиально

Добавлений не должно быть при $SCOPEDENUMS ON, не?..
1 май 21, 14:49    [22317222]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4653
JayDi
Откровенно говоря волосы на голове шевелились, когда читал этот топик. Есть же стандарт форматирования делфи-кода (что от самой эмбаркадеры, что от каких-нибудь jvcl -- разница минимальна). Но народ все-равно упорно отказывается его соблюдать, и каждый придумывает свой собственный стиль. Зачем?
Я на паскале начинал так писать, как сейчас пишу, когда даже не знал еще, что такое интернет.
А когда узнал - у меня еще его не было много-много лет.
О каких таких стандартах тогда могла речь идти? Я придумал свои, и меня они устраивают полностью.
А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями?
Это риторический вопрос.
1 май 21, 15:56    [22317245]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
JayDi
Member

Откуда: Сызрань, Россия
Сообщений: 4193
YuRock
А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями?
Это риторический вопрос.

Нет. Это не риторический вопрос. Это банальные требования к любому разработчику в организации -- соблюдать стандарты форматирования и стиля. И это довольно серьезные вещи.

К сожалению, инфраструктура делфи-разработки долгое время игнорировала подобные требования, в результате получили то, что получили (каждый делает так, как ему нравится). Настройки и форматирование кода появилось относительно недавно; про умное форматирование при написании/вставки, видимо, можно забыть. Делаю ставку на то, что во всём виноват кривой код инсайт, который не позволял долгое время хоть что-то сделать при работе с кодом.
1 май 21, 20:43    [22317300]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
defecator
Member

Откуда:
Сообщений: 39784
JayDi
YuRock
А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями?
Это риторический вопрос.

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


в другой будет другой стиль

Сообщение было отредактировано: 1 май 21, 20:49
1 май 21, 20:57    [22317302]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
JayDi
Member

Откуда: Сызрань, Россия
Сообщений: 4193
defecator
в другой будет другой стиль

В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода").
1 май 21, 21:58    [22317312]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
defecator
Member

Откуда:
Сообщений: 39784
JayDi
defecator
в другой будет другой стиль

В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода").

как раз таки вовсе нет
1 май 21, 22:01    [22317313]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4653
JayDi
defecator
в другой будет другой стиль

В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода").
В моей организации стандартом является мой стиль.
Хотя в некоторые куски я не лезу, там бывает другой, но если мне приходится рефакторить - переделываю под свой, иначе ничего не вижу в этих конченых end else begin в три строки.
1 май 21, 22:28    [22317317]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
white_nigger
Member

Откуда: Тула
Сообщений: 2569
YuRock
А когда узнал - у меня еще его не было много-много лет.
О каких таких стандартах тогда могла речь идти? Я придумал свои, и меня они устраивают полностью.
А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями?
Работа в команде требует выработки code rules
defecator
JayDi
пропущено...
В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода").

как раз таки вовсе нет
В большинстве крупных вендоров все же ближе к Ембаркадеровскому
2 май 21, 00:02    [22317341]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6366
YuRock, white_nigger
я думаю если компания хочет платить за такие глупости, то почему бы и нет
4 май 21, 08:59    [22318115]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
Wlr-l
Member

Откуда:
Сообщений: 563
Это обсуждение перенесло меня в 80 годы прошлого столетия. Тогда очень много спорили у кого программа более структурная. Учитывая интерес к этой теме я решил немного написать. Постараюсь сделать это небольшими сообщениями.

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

Из трех конструкций, необходимых и достаточных, для реализации любой программы, сначала рассмотрим линейную последовательность операторов. Очевидной записью последовательности операторов является O1; O2; ...; Оn. Но эту последовательность операторов решили назвать "блоком операторов" и обрамить её специальными словами: begin O1; O2; ...; Оn end. Точка с запятой разделяют операторы, а не завершают их. Конструкция O1;; O2 равносильна O1, пустой оператор, O2. Это позволяет добиться эффекта завершения команды символом ; (как исключение, К; else запрещена).

Теперь возник вопрос "как удобно расставлять begin'ы?!", который я свел бы к вопросу "Как расставить begin'ы, чтобы нагляднее отразить структуру программы?". А этот вопрос, в свою очередь, приводит к структурному программированию, основной смысл которого заключается в уменьшении вероятности появления ошибок программиста в разрабатываемых им программах.
Как только ОП доходит до реализации метода оно заканчивается и начинается СП.

В некоторых ЯП слово begin заменили на скобку { и преподали это как преимущество одного языка перед другим.

Но есть и языки, в которых обрамление последовательности операторов убрали совсем. В результате вопрос "Как расставить begin'ы?" стал бессмысленным.
11 май 21, 23:58    [22320696]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
Wlr-l
Member

Откуда:
Сообщений: 563
Теперь перейдем к второй конструкции, ветвлению. Здесь используются ключевые слова if, then и else. Причем, else является необязательным элементом. Отметим, что части then и else являются альтернативными частями одной конструкции, т.е. в зависимости от условия выполняется только одна часть этой конструкции.

В следующих двух примерах однозначно указано, что части else нет. Так же begin не затеняет сути оператора, а end четко указывает, какой if закончился.
 if a<b then b:=a;

 if a<b then begin
    b:=a;
    c:=b
 end;

В следующих трех примерах однозначно видно, что есть обе части then и else, и хорошо видна их альтернативность. Обрамление последовательности операторов не сильно загромождает смысл всей конструкции.
 if a<b
  then a:=b
  else b:=a;

 if a<b
  then begin
        b:=a;
        c:=a
       end
  else a:=c;

 if a<b
  then begin
        b:=a;
        c:=a
       end
  else begin
        a:=c;
        b:=0
       end;

Запись оператора ветвления, когда if и else записаны с одинаковым отступом,
if
...
else
является неудачной, так как можно понять, что независимо от условия всегда выполняется часть else.

Из этих примеров видно, что ключевые слова then и else вполне могут быть обрамлением последовательности операторов, но будет нужен символ завершения всей конструкции. Нельзя одновременно выиграть в силе и в расстоянии. В языках программирования это могут быть end, end if или fi.
В этом случае также однозначно решается вопрос "К какому if относится вот этот else?". Сейчас else во вложенных условных операторах является потенциальным источником трудноуловимых ошибок.

Т.е. оператор ветвления может выглядеть так:
 if a<b
  then b:=a;
       c:=a
  else a:=c;
       b:=0
 end;


Если нужно иметь более двух альтернатив, то можно так:
 if       a<b then b:=a
  else if a>b then a:=b // в языке не хватает ключевого слова elsif
  else if a>с then a:=с
  // ...
  else             b:=c;

Для case уже есть хорошее предложение. Только зачем для всего лишь одного слова else выделять отдельную строку? Да, хорошо, что break после каждой альтернативы писать не нужно. Можно было бы использовать в качестве обрамления последовательности операторов : и какой-нибудь символ, например, #.
case x of
  csStart,
  csStart1  :j := UpdateValue;
  csBegin   :x := j;
  csTimeOut :begin
               j := x;
               x := UpdateValue;
             end;
  else       j := x+1;
end;
12 май 21, 00:02    [22320699]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
Wlr-l
Member

Откуда:
Сообщений: 563
Осталась третья конструкция: повторение.

Известное число повторений:

for j:=1 to N do a[j]:=0;

for j:=1 to N do begin
    a[j]:=j;
    ...
end;

В одном из сообщений (22309969) был приведен пример досрочного выхода из цикла for. Досрочный выход из цикла for я бы запретил на уровне языка. Если сказали, что от 1 до N, то до N и не раньше. Если без раньше никак, то есть две другие возможности.

Неизвестное число повторений. Здесь не обсуждаем, чем while отличается от until.
while i<iMax do a[i]:=i;

i:=1;
while i<iMax do begin
      a[i]:=i;
      b[i]:=2*i;
end;

i:=1;
repeat //Спасибо, что не заставили писать begin end
  a[i]:=i;
  b[i]:=2*i;
until i=iMax;

В языке не хватает оператора повторения с выходом из середины цикла:
loop
 ..
 if .. then break;
 ..
end;


Это избавило бы от такой искусственной конструкции while true do или, что еще хуже while условие do … break… .
12 май 21, 00:06    [22320700]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
Wlr-l
Member

Откуда:
Сообщений: 563
Теперь применим написанное выше к некоторым примерам из этого обсуждения.

На странице 2 (22309826) предложили такое упрощение:
  if Key = VK_DELETE then DeleteSomething(FSelRow);
  if Key = VK_RETURN then ReturnSomething(FSelRow);

Key не может быть одновременно VK_DELETE и VK_RETURN, поэтому лучше написать так:
  if       Key = VK_DELETE then DeleteSomething(FSelRow)
   else if Key = VK_RETURN then ReturnSomething(FSelRow);

Но, если не вдаваться в смысл, то тогда так:
begin
  if (Not Key in [VK_DELETE, VK_RETURN]) then Exit;
  if       (Key=VK_RETURN) then case FSelRow of
                                   0    :if not FInProcess then ...
                                   8    :if     FInProcess then FStopFlag:= true
                                   else  Generate;
                                end
   else if (Key=VK_DELETE) and not FInProcess
                           then case FSelRow of
                                   0 :begin
                                      end;
                                   1 :begin
                                      end;
                                   ...
                                   7 :begin
                                       FFileName := c_NotSpecify;
                                       ...
                                      end;
                                end;
        end;
end;


Пример из 22309924
begin
  if () then
  begin
    while () do
    begin
      try
      except
      end
    end
  end
end

можно записать так
begin
  if () then begin
     while () do begin
           try
           except
          end
     end
  end
end

Конечно, можно говорить о рудиментах структурного программирования, но конструкция
begin
  if not () then exit;
  while () do
  try
  except
  end;
end;

явно неудачная. По сути дела, exit ничем не отличается от goto, что было показано в 22310217. Т.е. ни goto, ни exit сами по себе не плохие, даже эффективнее других по быстродействию. Одно но… их бесконтрольное использование плохо.

Фрагмент из примера 22310137
  if not Fro then begin // если документ открыт не в режиме "Только для чтения"
    if CheckKolZero then begin // если есть позиции с кол=0
       ... 
    end;//if
  end;//if

редуцируется к
  if    not Fro      // если документ открыт не в режиме "Только для чтения"
    and CheckKolZero // и есть позиции с кол=0
    ...
  end;


Все, пора остановиться.
12 май 21, 00:19    [22320704]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4653
Wlr-l
begin не затеняет сути оператора, а end четко указывает, какой if закончился.
+1
12 май 21, 00:29    [22320707]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4653
Wlr-l
Запись оператора ветвления, когда if и else записаны с одинаковым отступом,
if
...
else
является неудачной, так как можно понять, что независимо от условия всегда выполняется часть else.
Тут я не вижу логики. Ничего такого нельзя понять, это абсурд.
12 май 21, 00:31    [22320708]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4653
Wlr-l
Досрочный выход из цикла for я бы запретил на уровне языка. Если сказали, что от 1 до N, то до N и не раньше.
Это уже маразм.
12 май 21, 00:33    [22320709]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
white_nigger
Member

Откуда: Тула
Сообщений: 2569
Сорри, ниасилил))
12 май 21, 00:37    [22320710]     Ответить | Цитировать Сообщить модератору
 Re: Флейм про оформление и begin-end  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6366
Wlr-l,

if a<b then b:=a;
хорошая компактная запись, но у таких конструкций есть одно плохое свойство: на срабатывание их условия очень тяжело поставить точку останова
if a<b then 
  b:=a;
- здесь и тут:
if a<b then begin
  b:=a;
end;

это гораздо проще

ещё таких же вещей добавил итератор
for s in Strings do
  DoSomething(s);
если поставить точку остановки на DoSomething, то она будет срабатывать и на завершение цикла

эстетика конечно хорошо, читаем мы много, но и отладка тоже немалая часть работы
12 май 21, 09:07    [22320758]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 9 [10] 11   вперед  Ctrl      все
Все форумы / Delphi Ответить