Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock> Ну да, я живу в такой реальности Перечитай ещё раз внимательно, что и на что ты отвечал. Но да, проще продолжать упорствовать и вещать про уровни. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 11:03 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Откровенно говоря волосы на голове шевелились, когда читал этот топик. Есть же стандарт форматирования делфи-кода (что от самой эмбаркадеры, что от каких-нибудь jvcl -- разница минимальна). Но народ все-равно упорно отказывается его соблюдать, и каждый придумывает свой собственный стиль. Зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 12:39 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi, если было бы всё так просто. В так называемом стандарте форматирования кода от самой эмбы нет ни слова об использовании допустим тех же {$REGION} или той же XML-документации. Хотя сама же Эмба в новых модулях их использует, причем одни модули оформлены в одном стиле, в других в другом и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 12:44 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi каждый придумывает свой собственный стиль. Зачем? Потому что это вкусовщина. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 12:57 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
вот пример требования из 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 быть не должно принципиально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 12:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi> Зачем? 1. Стандартов может быть (и есть) больше одного. 2. Стандарт оформления - это, как правило, рекомендация, а не догма. 3. Кому-то какой-то стандарт может не нравиться/быть неудобным. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 12:59 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
> 1. Стандартов может быть (и есть) больше одного. 1.1. Стандарт (даже одного авторства) может меняться со временем. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 13:00 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
asutp2 Устаревшее требование, сейчас как раз никаких добавлений вида bk быть не должно принципиально Добавлений не должно быть при $SCOPEDENUMS ON, не?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 14:49 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi Откровенно говоря волосы на голове шевелились, когда читал этот топик. Есть же стандарт форматирования делфи-кода (что от самой эмбаркадеры, что от каких-нибудь jvcl -- разница минимальна). Но народ все-равно упорно отказывается его соблюдать, и каждый придумывает свой собственный стиль. Зачем? А когда узнал - у меня еще его не было много-много лет. О каких таких стандартах тогда могла речь идти? Я придумал свои, и меня они устраивают полностью. А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями? Это риторический вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 15:56 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями? Это риторический вопрос. Нет. Это не риторический вопрос. Это банальные требования к любому разработчику в организации -- соблюдать стандарты форматирования и стиля. И это довольно серьезные вещи. К сожалению, инфраструктура делфи-разработки долгое время игнорировала подобные требования, в результате получили то, что получили (каждый делает так, как ему нравится). Настройки и форматирование кода появилось относительно недавно; про умное форматирование при написании/вставки, видимо, можно забыть. Делаю ставку на то, что во всём виноват кривой код инсайт, который не позволял долгое время хоть что-то сделать при работе с кодом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 20:43 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi YuRock А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями? Это риторический вопрос. Нет. Это не риторический вопрос. Это банальные требования к любому разработчику в организации -- соблюдать стандарты форматирования и стиля принятые вот в этой конкретной организации в другой будет другой стиль ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 20:57 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator в другой будет другой стиль В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 21:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi defecator в другой будет другой стиль В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода"). как раз таки вовсе нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 22:01 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi defecator в другой будет другой стиль В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода"). Хотя в некоторые куски я не лезу, там бывает другой, но если мне приходится рефакторить - переделываю под свой, иначе ничего не вижу в этих конченых end else begin в три строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2021, 22:28 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock А когда узнал - у меня еще его не было много-много лет. О каких таких стандартах тогда могла речь идти? Я придумал свои, и меня они устраивают полностью. А сейчас кто-то там что-то придумал, и я должен ломать привычки, которые нарабатывал десятилетиями? defecator JayDi пропущено... В 95% случаев это будет стиль, созданный на основе официального (ака из интернетов по запросу "delphi оформление кода"). как раз таки вовсе нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2021, 00:02 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock, white_nigger я думаю если компания хочет платить за такие глупости, то почему бы и нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2021, 08:59 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Это обсуждение перенесло меня в 80 годы прошлого столетия. Тогда очень много спорили у кого программа более структурная. Учитывая интерес к этой теме я решил немного написать. Постараюсь сделать это небольшими сообщениями. Настоящие программисты меряются длиной своих программ в строчках. Поэтому для таких ключевых слов, которые слабо влияют на функциональные возможности программы: uses, const, var, begin выделяют отдельную строку. Возможно, это осталось с тех времен, когда программистов оценивали по количеству строк их программ. Из трех конструкций, необходимых и достаточных, для реализации любой программы, сначала рассмотрим линейную последовательность операторов. Очевидной записью последовательности операторов является O1; O2; ...; Оn. Но эту последовательность операторов решили назвать "блоком операторов" и обрамить её специальными словами: begin O1; O2; ...; Оn end. Точка с запятой разделяют операторы, а не завершают их. Конструкция O1;; O2 равносильна O1, пустой оператор, O2. Это позволяет добиться эффекта завершения команды символом ; (как исключение, К; else запрещена). Теперь возник вопрос "как удобно расставлять begin'ы?!", который я свел бы к вопросу "Как расставить begin'ы, чтобы нагляднее отразить структуру программы?". А этот вопрос, в свою очередь, приводит к структурному программированию, основной смысл которого заключается в уменьшении вероятности появления ошибок программиста в разрабатываемых им программах. Как только ОП доходит до реализации метода оно заканчивается и начинается СП. В некоторых ЯП слово begin заменили на скобку { и преподали это как преимущество одного языка перед другим. Но есть и языки, в которых обрамление последовательности операторов убрали совсем. В результате вопрос "Как расставить begin'ы?" стал бессмысленным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2021, 23:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Теперь перейдем к второй конструкции, ветвлению. Здесь используются ключевые слова if, then и else. Причем, else является необязательным элементом. Отметим, что части then и else являются альтернативными частями одной конструкции, т.е. в зависимости от условия выполняется только одна часть этой конструкции. В следующих двух примерах однозначно указано, что части else нет. Так же begin не затеняет сути оператора, а end четко указывает, какой if закончился. Код: pascal 1. 2. 3. 4. 5. 6. В следующих трех примерах однозначно видно, что есть обе части then и else, и хорошо видна их альтернативность. Обрамление последовательности операторов не сильно загромождает смысл всей конструкции. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Запись оператора ветвления, когда if и else записаны с одинаковым отступом, if ... else является неудачной, так как можно понять, что независимо от условия всегда выполняется часть else. Из этих примеров видно, что ключевые слова then и else вполне могут быть обрамлением последовательности операторов, но будет нужен символ завершения всей конструкции. Нельзя одновременно выиграть в силе и в расстоянии. В языках программирования это могут быть end, end if или fi. В этом случае также однозначно решается вопрос "К какому if относится вот этот else?". Сейчас else во вложенных условных операторах является потенциальным источником трудноуловимых ошибок. Т.е. оператор ветвления может выглядеть так: Код: pascal 1. 2. 3. 4. 5. 6. Если нужно иметь более двух альтернатив, то можно так: Код: pascal 1. 2. 3. 4. 5. Для case уже есть хорошее предложение. Только зачем для всего лишь одного слова else выделять отдельную строку? Да, хорошо, что break после каждой альтернативы писать не нужно. Можно было бы использовать в качестве обрамления последовательности операторов : и какой-нибудь символ, например, #. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 00:02 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Осталась третья конструкция: повторение. Известное число повторений: Код: pascal 1. 2. 3. 4. 5. 6. В одном из сообщений ( 22309969 ) был приведен пример досрочного выхода из цикла for. Досрочный выход из цикла for я бы запретил на уровне языка. Если сказали, что от 1 до N, то до N и не раньше. Если без раньше никак, то есть две другие возможности. Неизвестное число повторений. Здесь не обсуждаем, чем while отличается от until. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. В языке не хватает оператора повторения с выходом из середины цикла: Код: pascal 1. 2. 3. 4. 5. Это избавило бы от такой искусственной конструкции while true do или, что еще хуже while условие do … break… . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 00:06 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Теперь применим написанное выше к некоторым примерам из этого обсуждения. На странице 2 ( 22309826 ) предложили такое упрощение: Код: pascal 1. 2. Key не может быть одновременно VK_DELETE и VK_RETURN, поэтому лучше написать так: Код: pascal 1. 2. Но, если не вдаваться в смысл, то тогда так: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Пример из 22309924 Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. можно записать так Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. Конечно, можно говорить о рудиментах структурного программирования, но конструкция Код: pascal 1. 2. 3. 4. 5. 6. 7. явно неудачная. По сути дела, exit ничем не отличается от goto, что было показано в 22310217 . Т.е. ни goto, ни exit сами по себе не плохие, даже эффективнее других по быстродействию. Одно но… их бесконтрольное использование плохо. Фрагмент из примера 22310137 Код: pascal 1. 2. 3. 4. 5. редуцируется к Код: pascal 1. 2. 3. 4. Все, пора остановиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 00:19 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Wlr-l begin не затеняет сути оператора, а end четко указывает, какой if закончился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 00:29 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Wlr-l Запись оператора ветвления, когда if и else записаны с одинаковым отступом, if ... else является неудачной, так как можно понять, что независимо от условия всегда выполняется часть else. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 00:31 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Wlr-l Досрочный выход из цикла for я бы запретил на уровне языка. Если сказали, что от 1 до N, то до N и не раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 00:33 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Сорри, ниасилил)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 00:37 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Wlr-l, Код: pascal 1. хорошая компактная запись, но у таких конструкций есть одно плохое свойство: на срабатывание их условия очень тяжело поставить точку останова Код: pascal 1. 2. - здесь и тут: Код: pascal 1. 2. 3. это гораздо проще ещё таких же вещей добавил итератор Код: pascal 1. 2. если поставить точку остановки на DoSomething, то она будет срабатывать и на завершение цикла эстетика конечно хорошо, читаем мы много, но и отладка тоже немалая часть работы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2021, 09:07 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=40069502&tid=2037285]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
178ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
| others: | 277ms |
| total: | 573ms |

| 0 / 0 |
