Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_ Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 12:41 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Barmaley57 Тебе реально так удобно расставлять begin'ы?! а в исходниках VCL встречается всякое и симметричные begin .. end , и асимметричные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 12:46 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий дебаркадеро так ставит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 13:05 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Barmaley57 Тебе реально так удобно расставлять begin'ы?! Код: pascal 1. 2. 3. 4. Тогда каждый end соответствует конкретному оператору ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 13:52 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Barmaley57 Тебе реально так удобно расставлять begin'ы?! end else begin ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 14:28 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_ Если строка короткая. А если длинная пишу так Код: pascal 1. 2. 3. 4. только вот так Код: pascal 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 14:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_ Barmaley57 Тебе реально так удобно расставлять begin'ы?! Код: pascal 1. 2. 3. 4. Тогда каждый end соответствует конкретному оператору а я для сложных условий пишу вот так Код: pascal 1. 2. 3. 4. 5. тогда and/or не теряется в конце, условие сразу видно, чего с чем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 14:33 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_, непривычно тяжело читать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 16:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator> тогда and/or не теряется в конце Чтобы не терялись в конце - их можно писать в начале (в той же строчке, не на отдельной). Отступы делаешь, кстати? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 18:08 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам defecator> тогда and/or не теряется в конце Чтобы не терялись в конце - их можно писать в начале (в той же строчке, не на отдельной). Отступы делаешь, кстати? конечно делаю ! Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 18:17 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator> конечно делаю ! Не, отступы внутри сложных булевых выражений. А-ля (условие1) and (условие2 or условие3) итп Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 18:55 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator Код: pascal 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 19:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator Код: pascal 1. 2. А почему не ProbkaCounter?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 20:31 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Fr0sT-Brutal defecator Код: pascal 1. 2. А почему не ProbkaCounter?) считались бутылки по пробкам - стоит камера над конвейером, который ползёт весьма быстро, и надо было сосчитать количество бутылок за смену причём только оптическое распознавание, никаких магнитиков и прочей шушеры хороший заказной проект был из Казахстана, 2010-й год, тонны денег принёс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 20:35 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Barmaley57 Тебе реально так удобно расставлять begin'ы?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 23:28 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
С некоторых пор я отказался от комментариев вида {} в пользу комментариев вида // Минус фигурных скобок в том что если камент многострочный и закомментировать одну из скобок - то действие оставшейся распространяется совсем не туда куда нужно. Это ограничивает использование комментирования блока операторов в целях отладки. Теперь всегда пишу // тем более что в GExperts есть шорткат что бы такими символами закоментировать/раскомментировать сразу все выделенные строки. Так же, для удобства, после end пишу от чего этот begin. Код: pascal 1. 2. 3. 4. Код: pascal 1. 2. 3. 4. 5. 6. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 03:52 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
bk0010 читабельность ухудшается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 09:37 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Стандартный форматтер в среде согласен со мной)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 09:39 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Минус фигурных скобок в том что если камент многострочный и закомментировать одну из скобок - то действие оставшейся распространяется совсем не туда куда нужно. Это ограничивает использование комментирования блока операторов в целях отладки. Вот уж воистину - применить кривой метод, вляпаться в несуществующую проблему и отказаться от хорошей вещи ради её "решения". "Комментирование в целях отладки" - довольно кривая практика, но если уж решил этим путём - попробуй как-нибудь использовать для этого (* такие комментарии *), тебя ждёт сюрприз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 10:14 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Так же, для удобства, после end пишу от чего этот begin. И ещё венгерскую нотацию надо бы вспомнить. Дабы собрать все древние глупости в одном флаконе. Кстати, это "удобство" ярко иллюстрирует проблемы от неправильного позиционирования begin-а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 10:15 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Так же, для удобства, после end пишу от чего этот begin. Для длинных блоков тоже пишу. Вот так топик о Мак-адресе скатился в спор о стилях)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 10:19 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Египетские скобки в паскале, это капец... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 10:21 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks> Минус фигурных скобок в том что если камент fraks> многострочный и закомментировать одну из скобок - fraks> то действие оставшейся распространяется совсем fraks> не туда куда нужно. Это ограничивает использование fraks> комментирования блока операторов в целях отладки. Про комментирование в целях отладки уже отметили, но комментировать блоки надо не так Код: pascal 1. 2. 3. 4. а так Код: pascal 1. 2. 3. 4. При чём независимо от IDE и языка. fraks> Так же, для удобства, после end пишу от чего этот begin. Только если длинные блоки (что уже плохо). Отступы должны помогать, тем более щас IDE умеют подсвечивать блоки (вот раньше проблема была, да). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 11:44 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
16.04.2021 11:44, Гаджимурадов Рустам пишет: > Отступы должны помогать, тем более щас IDE умеют > подсвечивать блоки (вот раньше проблема была, да). > CnPack отлично подсвечивает и на старых версияx IDE. а писать "от чего конец" - маразм. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 11:48 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий а писать "от чего конец" - маразм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 11:59 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
16.04.2021 11:59, _Vasilisk_ пишет: > Когда в конце процедуры образовывается лесенка из 4-5 end, то не такой и маразм при наличии подсветки - маразм. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 12:02 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
МП> CnPack отлично подсвечивает и на старых версияx IDE. Угу, но им пользуются не только лишь все и бажный был он раньше. МП> а писать "от чего конец" - маразм. Это в абстрактной идеальной ситуации - маразм, да. А когда там не только лесенка, а простыня, которая по вертикали в экран не помещается - не маразм, а удобство. Надо не в догмы ударяться, а работать так, как удобно и эффективно (при чём не только тебе). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 12:05 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Только если длинные блоки (что уже плохо) Длинные блоки - это само по себе не плохо. Это нормально и где-то неизбежно, если не принимать откровенно искусственных решений. Плохо, когда у длинных блоков начинается разнообразная и непредсказуемая вложенность. И тогда уже никакие отметки на end-ах делу не помогут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 12:46 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_ Мимопроходящий а писать "от чего конец" - маразм. Когда в конце процедуры образуется лесенка из 4-5 end - это верный признак кривого нуждающегося в улучшении кода сверху от них. Я сейчас пробежал глазами страшный легаси модуль, на переделку которого точу зубы с тех пор как пришёл в этот проект - и то больше трёх end-ов подряд нигде не увидел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 12:52 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> Длинные блоки - это само по себе не плохо. softwarer> Плохо, когда у длинных блоков начинается softwarer> разнообразная и непредсказуемая вложенность. То ли я не понял, что ты пытался сказать, то ли это какая-то демагогия. "разнообразная вложенность" - понятие слишком растяжимое - скажем, наличие в одной п/п if (одного или нескольких), case и try..except является разнообразной вложенностью или нет? softwarer> И тогда уже никакие отметки на end-ах делу не помогут. Помогут увидеть блоки. Код лучше не сделают, конечно. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 13:32 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> страшный легаси модуль ... softwarer> больше трёх end-ов подряд нигде не увидел. Да ну, 3 end - это курам на смех, 3 end-a автоматически образуются в каждом втором-третьем длинном методе. Вот, для примера, расскажи мне, как рефакторить следующий г*код: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. И это простыня всего лишь на 60 строк, на экран почти помещается. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 13:40 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам 3 end-a автоматически образуются в каждом втором-третьем длинном методе. Ну в общем, да. Один end на процедуру, один на finally - то есть нормально два. Один резервный - на какую-нибудь доп. хрень. А вот когда их 4-5 - это уже наворочено. Гаджимурадов Рустам Вот, для примера, расскажи мне, как рефакторить следующий г*код: Ну для начала, очевидно Код: pascal 1. 2. 3. 4. а дальше уже надо предметно смотреть, что внутри этих case-ов. В недавнем прошлом, когда я занимался такой хренью, лучшим оказался подход Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. но это уже принципиально зависит от. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 13:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> Ну для начала, очевидно softwarer> if Key = VK_DELETE then DeleteSomething(FSelRow); softwarer> if Key = VK_RETURN then ReturnSomething(FSelRow); Ну что и ожидалось - вместо одного длинного плохого метода получить два плохих, но покороче. А вчера были большие, но по пять, а сегодня маленькие, но по 3. (с) > лучшим оказался подход > type > TSelRow = class > protected > procedure DoDelete; virtual; > procedure DoReturn; virtual; > end; Это ИМХО ещё хуже, чем одна длинная простыня. Впрочем, не настаиваю. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 14:18 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам "разнообразная вложенность" - понятие слишком растяжимое Я не возьмусь сформулировать математически строго - сама область слишком зыбкая и растяжимая. Попробую примерно так: 1. Линейный блок (то есть тот, где передача управления идёт строго сверху вниз) может быть столь длинным, сколь нужно для конкретной задачи. Это нормально читается и не создаёт практических проблем. В том числе он может включать в себя локальные (то есть небольшие) ветвления и циклы, это не мешает. В том числе он может быть завёрнут в try. 2. Цикл может включать в себя длинный блок (а-ля блок из первого пункта) если он такой один и занимает практически всё тело подпрограммы (практически всё - в смысле, что до цикла и после цикла может быть несколько технических строк, но ничего существенного). 3. В ветвлении совершенно недопустимы два длинных блока (if условие then длинный else длинный). Ветвление с одной веткой (if условие then длинный) чаще всего следует переписать как (if not условие then exit; длинный). Ветвление с одной длинной и одной короткой веткой нежелательно. Если таки не удаётся его избежать, короткая ветка должна идти первой (if условие then длинный else короткий) следует переписать как (if not условие then короткий else длинный). 4. В некоторых случаях допустимо дальнейшее наращение вложенности (например, цикл, телом которого является цикл с длинным блоком или if с длинным блоком), но здесь быстро наступает предел (скажем, какой-нибудь двукратно вложенный if внутри длинного блока из предыдущего примера уже точно слишком). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 14:25 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Ну что и ожидалось - вместо одного длинного плохого метода получить два плохих получше Всё правильно. Там, где нет возможности для одного глобального улучшения, надо идти шаг за шагом. Гаджимурадов Рустам Это ИМХО ещё хуже, чем одна длинная простыня. В твоём случае - возможно. В моём - это неизмеримо лучше. Краткая характеристика моего случая в терминологии из твоего примера: FSelRow - несколько десятков, условно группируемых на два подтипа, склонны к регулярному пополнению; клавиши - пара десятков, стабильны, обработчики - в большинстве случаев типовые, частично - типовые для подтипа FSelRow, время от времени - особые, однажды прописанные, почти никогда не меняются. Соответственно, какое удовольствие было ползать среди двух десятков простыней, содержащих case на полсотни вариантов каждая.... я как один раз его ощутил, так сразу и переделал на короткий элегантный модуль, в котором добавление нового FSelRow делается за несколько минут, просто-напросто добавлением нового класса и доопределением в нём трёх-четырёх методов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 14:39 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> 3. ... Если таки не удаётся его избежать, короткая softwarer> ветка должна идти первой (if условие then длинный softwarer> else короткий) следует переписать как (if not условие softwarer> then короткий else длинный). Ну это вариации из Макконнелла, он описал их лучше (хоть и гораздо многословнее), ИМХО. Кроме того, лично мне больше нравится (и понятнее/читабельнее) "натуральный" код, вместо "переставленного по размеру". Т.е. НЕ "переделанный" вариант следующего вида: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Да и вообще, "важный"/основной код хочется видеть до второстепенного, а не переставлять наоборот. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 14:48 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> удовольствие было ползать среди двух десятков простыней Когда простыней много - да, плюсы могут пересилить минусы. :) softwarer> короткий элегантный модуль, в котором добавление softwarer> ... делается за несколько минут, просто-напросто softwarer> добавлением нового класса и доопределением в нём трёх-четырёх методов. Ну, "за несколько минут" оставим без комментариев, но ты забыл упомянуть, насколько разрастается при этом код (по сравнению с одной простыней, не несколькими) и все прелести взаимодействия не-friendly классов. :) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 14:53 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Ну это вариации из Макконнелла, он описал их лучше (хоть и гораздо многословнее), ИМХО. Я допускаю, что Макконнел заглядывал в мой код, когда писал свою книгу. Гаджимурадов Рустам Кроме того, лично мне больше нравится (и понятнее/читабельнее) "натуральный" код, вместо "переставленного по размеру". Ничего не имею против, но при этом else за пару страниц от if категорически нечитабелен. Просто без вариантов. Я назвал вариант приведения наименьшей кровью, но если результат не устраивает - можно воспользоваться любым другим подходом, устраняющим такой if. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 14:53 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
"Флейм"...хм. Ёлы-палы, просто спросил!)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 15:06 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Barmaley57> "Флейм"...хм. Ёлы-палы, просто спросил!)) Предложи название получше - переименую. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 15:09 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> при этом else за пару страниц от if категорически нечитабелен. В смысле "условие" else или сам блок? Для "условия" как раз есть подсветка, комментарии, фолдинг и пр. извраты. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 15:11 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_ Когда в конце процедуры образовывается лесенка из 4-5 end, то не такой и маразм От таких мест нужно избавляться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 15:16 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Ну, "за несколько минут" оставим без комментариев Верное решение. Гаджимурадов Рустам ты забыл упомянуть, насколько разрастается при этом код Боюсь тебя огорчить, но я померял. Между версиями v1 и v2 (последними перед переделкой) добавление 4-х FSelRow по старому типу привело к увеличению кода на 95 строк. Между версиями v3 и v4 (первыми после переделки) добавление 2-х FSelRow по новому типу привело к увеличению кода на 52 строки. Если вычесть из этих строк пустые и комментарии, думаю, окажется, что код ещё и сокращается. Впрочем, это в любом случае неважно. Размер кода важен, когда маневрируешь между простынями. Здесь же FSelRow собран в компактный лежащий вместе класс, размером, например (у последнего из добавленных) 36 строк, с которыми ты и работаешь. До всего остального кода просто нет никакого дела. Если захочется, можно, например, вынести этот FSelRow в отдельный файл и наслаждаться "разросшимся кодом" менее 50 строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 15:18 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам В смысле "условие" else или сам блок? В смысле, программный код, содержащий такую конструкцию. Гаджимурадов Рустам Для "условия" как раз есть подсветка, комментарии, фолдинг и пр. извраты. Скажем так, костыли до определённой степени помогают, но не вижу смысла полагаться на них как на базовый механизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 15:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, авторавтор Минус фигурных скобок в том что если камент... ... Про комментирование в целях отладки уже отметили, .... Ну, отладке это точно не помешает, если не путаться в их последовательности Код: pascal 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 16:05 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Gerasimenko> Ну, отладке это точно не помешает, если не путаться в их последовательности Ну Вы хоть сообщение, на которое отвечаете, дальше первой строчки прочитайте что ли... softwarer> добавление 4-х FSelRow по старому типу softwarer> привело к увеличению кода на 95 строк Это для скольки штук простыней? softwarer> Здесь же FSelRow собран в компактный лежащий softwarer> вместе класс, размером, например 36 строк Ещё раз - ты на каждый FSelRow свой наследник делаешь или что именно тут 36 строк занимает? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 16:24 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ _Vasilisk_ Когда в конце процедуры образовывается лесенка из 4-5 end, то не такой и маразм Ну как ты от них избавишься? Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Что тут выкинуть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 16:34 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, - именно в примере - все пары b/e. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:27 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ЯННП. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Код: pascal 1. 2. 3. 4. 5. А вообще - смелее выделять блоки кода в методы, даже если они вызываются лишь из одной точки. Колбаса не нужна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:37 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Это для скольки штук простыней? Написал же вроде, пара десятков. Гаджимурадов Рустам Ещё раз - ты на каждый FSelRow свой наследник делаешь Да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:38 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Что тут выкинуть? Код: pascal 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:39 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer Гаджимурадов Рустам Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Что тут выкинуть? Код: pascal 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:49 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> Написал же вроде, пара десятков. Соответственно, кол-во строк не имеет смысла. softwarer> if not () then exit; С этим согласен, в простейшем случае. А это > while () do > try > except > end; > end; неравносильно предыдущему куску кода (особенно если except заменить на finally). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ> А вообще - смелее выделять блоки кода в методы Ты хоть смайлики ставь, а-то не всегда очевидно, когда ты троллишь. :) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 17:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer ... ... Код: pascal 1. 2. 3. 4. 5. 6. 7. exit вроде обязывает, нет? В структурно родственных языках практикуют такого рода форму для любителей раннего выхода: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 18:11 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
booby> exit вроде обязывает, нет? Exit - выход из метода. > В структурно родственных языках практикуют такого > рода форму для любителей раннего выхода: break - выход из цикла, не из метода. И Ваш код отличается от обсуждаемого. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 18:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, теперь я ЯННП обсуждать вроде предлагалось расстановку скобок составного оператора... В топике тогда весь код не соответствует обсуждаемому. Ладно, не обращай внимания, я случайно забрёл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 18:29 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ Код: pascal 1. 2. 3. 4. Я в begin-end заворачиваю даже один оператор, если он длинный и располагается на нескольких строках ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 18:46 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_> Я в begin-end заворачиваю даже один оператор, если _Vasilisk_> он длинный и располагается на нескольких строках Это оверкилл. Если это расчётный оператор (а не вызов функции с 12ю параметрами), то лучше его просто разбить на 2-3 с переприсваиваниями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 18:57 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
booby> обсуждать вроде предлагалось расстановку скобок составного оператора... Обсуждалось много чего, просто рассуждения про break vs exit - совсем не тема данного топика. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 18:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Если это расчётный оператор (а не вызов функции Код: pascal 1. 2. 3. 4. 5. 6. или Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 20:03 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_> Ну вот из реального кода Тут составной оператор определённо лишний. Лично я бы и Format выкинул, за ненадобюностью. > или > LPath.D := Format( Тут составной оператор тоже не нужен, ИМХО, достаточно отступов, которые ты итак сделал. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 20:12 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам ъъъъъ пропущено... От таких мест нужно избавляться. Ну как ты от них избавишься? Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Что тут выкинуть? первый IF выкинуть вообще просто Я лично адепт простых условий, и чтобы не было вложенносте всё, что не надо, проверить ДО Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 21:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_ Гаджимурадов Рустам Если это расчётный оператор (а не вызов функции Код: pascal 1. 2. 3. 4. 5. 6. или Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. это всеми любимый стиль оформления в PL/SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 21:25 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator> всё, что не надо, проверить ДО Это победа, да, 3 end-a вместо четырёх. Потом другом в коде выкинуть With и написать вместо блока переменную, да. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 21:35 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
А я ещё в некоторых случаях стал точку с запятой в отдельную строку выносить. И в вызываемый метод, когда параметров много - каждый параметр на отдельной строке. Пример: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Смысл в том, что: а) легко выделять для копи-пасты (строками целиком, не надо целиться мышкой между символами) б) пока код черновой - добавлять/удалять параметры можно комментированием одной строки в) точка с запятой показывает текущий отступ и не затеряется где-то справа, если вдруг вызов второго метода разрастётся ещё параметрами и это всё уедет вправо. Но такое чаще для PL/SQL (в Oracle, особенно точка с запятой актуальна для SQL-блоков в PL/SQL-коде). В Delphi всё же проще параметры определять в рекорды/классы и передавать одной переменной (или просто вызвав метод класса без параметров). А вообще я за GunSmoker не пишите комментарии - такой подход добавит читаемости и уменьшит кол-во потенциальных ошибок, проверено практикой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 21:35 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Ну как ты от них избавишься? Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Что тут выкинуть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2021, 22:34 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Вот поэтому скобочки из С++ рулят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 00:02 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
didgik Вот поэтому скобочки из С++ рулят. чем это они рулят ? ровно то же самое и будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 09:11 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_ ъъъъъ Код: pascal 1. 2. 3. 4. ... Да ладно. С "этим" питон живет, и ни жу-жу. И в рейтинге, в отличии от. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 10:35 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator didgik Вот поэтому скобочки из С++ рулят. чем это они рулят ? ровно то же самое и будет В сях begin end в среднем в 4 раза короче, и нет тупости типа Код: pascal 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 10:40 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Соответственно, кол-во строк не имеет смысла. Так я сразу так и сказал. Но поскольку тебя заинтересовал этот вопрос - дал информацию. Гаджимурадов Рустам неравносильно предыдущему куску кода Зависит от. Именно поэтому я не ленюсь расставлять комментарии типа { ... длинный кусок кода ... }. booby exit вроде обязывает, нет? "Всё, что я должен, записано в налоговом кодексе" (тм) booby В структурно родственных языках практикуют такого рода форму Есть разработчики, которые пользуются языком программирования примерно так же, как таджики разговаривают по-русски. Они пишут Код: pascal 1. 2. 3. пишут Код: pascal 1. 2. 3. 4. и ещё множество подобных конструкций, в том числе и описанную Вами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 12:41 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer Гаджимурадов Рустам Что тут выкинуть? Код: pascal 1. 2. 3. 4. Я конечно тоже использую такой метод "испуганного программирования", но исключительно когда эта строка - первая и единственная такого рода в процедуре. Типа если в датасете нет выбранной строки - то идем нафиг. Если такие убегания встречаются внутри, да еще неоднократно - это не есть хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 12:49 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ defecator пропущено... чем это они рулят ? ровно то же самое и будет В сях begin end в среднем в 4 раза короче, и нет тупости типа Код: pascal 1. 2. 3. 4. твой ахтунг в Дельфи не скомпилируется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 12:51 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам fraks> Так же, для удобства, после end пишу от чего этот begin. Только если длинные блоки (что уже плохо). Отступы должны помогать, тем более щас IDE умеют подсвечивать блоки (вот раньше проблема была, да). У меня D7, там нету подсветки. В Notepad++ и в Lazarus она есть, но не скажу что бы это как-то сильно помогало. Впрочем, я в них не работаю, только иногда запускаю. Поискал у себя код с длинными лестницами, нашел вот такого вида. Есть и больше, но в единичных случаях, лень искать. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Иногда даже вот так выделяю блоки Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:05 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Еще бывает что для компактности кода if с блоками растягиваю в одной строке Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:07 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам ъъъъъ пропущено... От таких мест нужно избавляться. Ну как ты от них избавишься? Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Что тут выкинуть? Код: pascal 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:20 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Сбоянил я смачно, да! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:21 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
bk0010 Гаджимурадов Рустам Ну как ты от них избавишься? Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Что тут выкинуть? Для улучшения читабельности. Только для этого, и это очень важно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:24 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Гаджимурадов Рустам fraks> Так же, для удобства, после end пишу от чего этот begin. Только если длинные блоки (что уже плохо). Отступы должны помогать, тем более щас IDE умеют подсвечивать блоки (вот раньше проблема была, да). У меня D7, там нету подсветки. В Notepad++ и в Lazarus она есть, но не скажу что бы это как-то сильно помогало. Впрочем, я в них не работаю, только иногда запускаю. Поискал у себя код с длинными лестницами, нашел вот такого вида. Есть и больше, но в единичных случаях, лень искать. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. [/SRC] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:27 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Еще бывает что для компактности кода if с блоками растягиваю в одной строке Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks> У меня D7, там нету подсветки. CnPack есть, он умеет. fraks> QDel.ParamByName('ndok').AsInteger := Fndok; fraks> QDel.ParamByName('io' ).AsString := Fio; Это тоже полезная привычка, да. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer Код: pascal 1. 2. 3. 4. 5. 6. 7. Код: pascal 1. А если там дальше ещё код после этого блока? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 13:57 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator ъъъъъ пропущено... В сях begin end в среднем в 4 раза короче, и нет тупости типа Код: pascal 1. 2. 3. 4. твой ахтунг в Дельфи не скомпилируется Вот именно. Есть ";" перед else - ахтунг. Нет "end" в конце модуля - ахтунг. Ладно, end в конце .dpr имеет свой begin. А в модуле-то он накуа? Нет "." в конце модуля - ахтунг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:07 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
alekcvp А если там дальше ещё код после этого блока? Второй раз за сегодняшнее утро пишу: именно поэтому я не ленюсь расставлять в примерах комментарии типа { ... длинный кусок кода ... } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:07 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock Это обычный говнокод. Первые 3 ифа выкидываются на с помощью Exit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:10 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock Это еще хуже, нужен else if везде, кроме первой строки. С чего бы там был нужен else if? Думаешь, два товара слететь не могут? Скорее там нужен вопрос "а если этих гудсов не шесть, а сто двадцать шесть, так и будешь код масштабировать?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:11 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ А в модуле-то он накуа? Ты ещё спроси накуа он в декларации классов или записей, бегина-то тоже нет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey ъъъъъ А в модуле-то он накуа? Ты ещё спроси накуа он в декларации классов или записей, бегина-то тоже нет... Бигин там есть. А в модуле - нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:16 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ Бигин там есть. А в модуле - нет. В модуле тоже есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey ъъъъъ Бигин там есть. А в модуле - нет. В модуле тоже есть. Ахтунг сплошной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:33 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock fraks Еще бывает что для компактности кода if с блоками растягиваю в одной строке Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. Else тут не нужен нигде. Каждая строка отвечает за свою настройку, независимо от других. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:37 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer YuRock Это еще хуже, нужен else if везде, кроме первой строки. С чего бы там был нужен else if? Думаешь, два товара слететь не могут? Скорее там нужен вопрос "а если этих гудсов не шесть, а сто двадцать шесть, так и будешь код масштабировать?" Там речь про выделение товаров цветом на основании вхождения товара в определенный список товаров. Магическая цифра 6 - это ориентировочное количество цветов которые обычный человек достаточно безошибочно может различить по цвету. Цветов немного, даже меньше шести. В данном случае используется 2 одинаковых цвета. Ранее было 5 настроек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:43 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам fraks> У меня D7, там нету подсветки. CnPack есть, он умеет. Я уже стар мозгами. Если я как-то обошелся без лишних неведомых мне свистоперделок - значит оно мне и не нужно. Гаджимурадов Рустам fraks> QDel.ParamByName('ndok').AsInteger := Fndok; fraks> QDel.ParamByName('io' ).AsString := Fio; Это тоже полезная привычка, да. Тут наверное было что-то умное, но я не понял. Если не лень - распиши. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:45 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock fraks пропущено... У меня D7, там нету подсветки. В Notepad++ и в Lazarus она есть, но не скажу что бы это как-то сильно помогало. Впрочем, я в них не работаю, только иногда запускаю. Поискал у себя код с длинными лестницами, нашел вот такого вида. Есть и больше, но в единичных случаях, лень искать. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. [/SRC] Я не претендую на образцовый код. > Первые 3 ифа выкидываются на с помощью Exit. Я избегаю "испуганного программирования", кроме единственного случая который в этом треде уже упоминал. Приведенный мной код - это только часть процедуры, Exit тут совсем не в тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:48 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks> Я уже стар мозгами. Если я как-то обошелся без лишних fraks> неведомых мне свистоперделок - значит оно мне и не нужно. Я знаю, но это неправильная, самоограничивающая логика. Если что-то может повысить удобство - нужно попробовать. Не понравится - выкинешь. Другое дело - лень, время и пр. fraks> Тут наверное было что-то умное, но я не понял. Если не лень - распиши. Это форум без тега SRC скушал пробелы. Я имел в виду привычку выравнивать пробелами простыню присвоения переменных, полей и т.п. - так читать удобнее. :) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:53 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey> Ты ещё спроси накуа он в декларации Kazantsev Alexey> классов или записей, бегина-то тоже нет... Я бы, кстати, не был бы против, если бы его когда-то назвали (или хотя переименовали) из end в endclass, например. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:54 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Я бы, кстати, не был бы против, если бы его когда-то назвали (или хотя переименовали) из end в endclass, например. Это был бы такой же шаг в прошлое с его end if, end loop итп., как и "комментарии что завершает этот end". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 14:59 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Я конечно тоже использую такой метод "испуганного программирования", но исключительно когда эта строка - первая и единственная такого рода в процедуре. Это попытка остаться немножко беременной. Если такая строка хороша как первая в процедуре, отсюда по индукции следует, что она хороша и в других случаях. fraks Если такие убегания встречаются внутри, да еще неоднократно - это не есть хорошо. Это есть хорошо. И точно всяко лучше, чем попытки обойтись без них. Кстати, задай себе простой вопрос: используешь ли ты raise в середине процедур? Если да - значит кривишь душой, ибо это точно такое же убегание, только более масштабное. Если нет.... ну да, ну да, настоящие мастера исключений не используют. Только коды ошибок, только хардкор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:03 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Я уже стар мозгами. Если я как-то обошелся без лишних неведомых мне свистоперделок - значит оно мне и не нужно. Не, надо пробовать. Я вот CNPack терпеть не могу: попробовал. Долго не пользовался GExperts, тоже пробовал ибо. Сейчас я Gexperts использую, т.к. в нем есть годный автоформаттер. Но всё остальное смело бы выкинул... хи, идея, вычистить Gexperts. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:14 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам fraks> Тут наверное было что-то умное, но я не понял. Если не лень - распиши. Это форум без тега SRC скушал пробелы. Я имел в виду привычку выравнивать пробелами простыню присвоения переменных, полей и т.п. - так читать удобнее. :) А, это да, это обязательно. Все что можно выровнять - обязательно выровняю. Во многих случаях это сразу показывает где ошибка. К сожалению, некоторые языки не позволяют такого. При написании bat-файлов очень не хватает такой возможности, выровнять при присвоении переменным по знаку =. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:15 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks Я конечно тоже использую такой метод "испуганного программирования", но исключительно когда эта строка - первая и единственная такого рода в процедуре. Это попытка остаться немножко беременной. Если такая строка хороша как первая в процедуре, отсюда по индукции следует, что она хороша и в других случаях. Категорически не согласен. Характерный пример у меня - обработчик события из контекстного меню грида. Если нет выделенной строки (фокус не выставлен или нет ни одной записи) то убегаем. Сразу видно что процедура далее не будет выполняться. Если убегание где-то в середине, да еще и не одно то это фигово т.к. нет места где производится "по окончании процедуры", ибо этих окончаний образуется целая куча. И при попытке дописать в процедуру еще одну обработку можем пролететь, ибо из нее вышли раньше. softwarer fraks Если такие убегания встречаются внутри, да еще неоднократно - это не есть хорошо. Это есть хорошо. И точно всяко лучше, чем попытки обойтись без них. Не всегда попытки обойтись заканчиваются красиво, но множественные выходы - исключительная, крайняя мера, а не обычное решение. softwarer Кстати, задай себе простой вопрос: используешь ли ты raise в середине процедур? Если да - значит кривишь душой, ибо это точно такое же убегание, только более масштабное. Если нет.... ну да, ну да, настоящие мастера исключений не используют. Только коды ошибок, только хардкор. Хм... для меня raise это примерно как транзакция. Где оно нужно - там оно нужно и это не вопрос красоты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks При написании bat-файлов очень не хватает такой возможности, выровнять при присвоении переменным по знаку =. Используй PowerShell. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:24 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ fraks Я уже стар мозгами. Если я как-то обошелся без лишних неведомых мне свистоперделок - значит оно мне и не нужно. Не, надо пробовать. Я вот CNPack терпеть не могу: попробовал. Долго не пользовался GExperts, тоже пробовал ибо. Сейчас я Gexperts использую, т.к. в нем есть годный автоформаттер. Но всё остальное смело бы выкинул... хи, идея, вычистить Gexperts. :) У меня установлен GExperts, с незапамятных времен. С тех когда было не лень изучать что-то новое :) Сейчас даже не могу сказать что именно оттуда использую, ибо все через шорткаты. - Комментирование/расскоментирование блока строк. - TODO List - Procedure List Форматтер не использую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:27 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ fraks При написании bat-файлов очень не хватает такой возможности, выровнять при присвоении переменным по знаку =. Используй PowerShell. PowerShell прикольная штука, но это нужно дополнительно изучать, и плюс там проблемка с запуском скрипта. Если все по феншую то скрипт должен иметь подпись чтобы запускаться. Или нужно полностью отключить защиту от запуска. Отключить что-то меня стремает, а подписывать - какая-то очень непростая песня, решил что пока обойдусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:32 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks ъъъъъ пропущено... Используй PowerShell. PowerShell прикольная штука, но это нужно дополнительно изучать, и плюс там проблемка с запуском скрипта. Если все по феншую то скрипт должен иметь подпись чтобы запускаться. Или нужно полностью отключить защиту от запуска. Отключить что-то меня стремает, а подписывать - какая-то очень непростая песня, решил что пока обойдусь. Ага, а bat - файлы неподписанные не стремает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:44 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Категорически не согласен. Да наздоровье. Просто это несогласие чисто эмоциональной природы, без опоры на факты. fraks Характерный пример у меня - обработчик события из контекстного меню грида. Если нет выделенной строки (фокус не выставлен или нет ни одной записи) то убегаем. Сразу видно что процедура далее не будет выполняться. Теперь с позиций этого рассуждения раскритикуй вот этот код и расскажи, чем ужасен выход из второй строки: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. fraks И при попытке дописать в процедуру еще одну обработку можем пролететь При любом дописывании в процедуру можно пролететь. Поэтому нужно думать, что и куда дописываешь, проверять корректность. Множественные точки выхода здесь ничего не меняют, тем более, как мы уже выяснили, они у тебя по факту всё равно есть - через raise. "Единая точка выхода" - это рудимент теории структурного программирования, смысл которого с тех пор потерялся. Когда об этом писал Дейкстра, под этим имелось в виду следующее: в середине структурного блока не должно быть GOTO куда-то в другие части программы. То есть не должно быть так, что из блока ты можешь уйти в A, в Б, в В и в Г, точка выхода должна быть одна. exit - это всего лишь goto на последний end процедуры. То есть конструкции Первая Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. вторая Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. и третья Код: pascal 1. 2. 3. 4. 5. 6. полностью эквиваленты и соответствуют подходу структурного программирования. Просто третья из них наиболее читаемая и удобная для восприятия. fraks Хм... для меня raise это примерно как транзакция. Где оно нужно - там оно нужно и это не вопрос красоты. Это же верно и для других конструкций, в том числе exit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:47 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks softwarer пропущено... Код: pascal 1. 2. 3. 4. Я конечно тоже использую такой метод "испуганного программирования", но исключительно когда эта строка - первая и единственная такого рода в процедуре а я очень сильно люблю именно этот метод. позволяет избавиться от излишней вложенности условий Сразу отсёк на входе в подпрограмму то, что не соответствует условиям, и пишешь только функциональный код ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 15:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
bk0010 YuRock Это обычный говнокод. Первые 3 ифа выкидываются на с помощью Exit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:06 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator а я очень сильно люблю именно этот метод. позволяет избавиться от излишней вложенности условий. Сразу отсёк на входе в подпрограмму то, что не соответствует условиям, и пишешь только функциональный код Любовь к этому методу появляется у тех, кто достаточно повозился со сложными и запутанными условиями, задолбался править вызванные ими баги и начал ценить упрощение и даваемые им блага. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:08 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer YuRock Это еще хуже, нужен else if везде, кроме первой строки. С чего бы там был нужен else if? Думаешь, два товара слететь не могут? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:08 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks YuRock пропущено... Это еще хуже, нужен else if везде, кроме первой строки. Else тут не нужен нигде. Каждая строка отвечает за свою настройку, независимо от других. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:09 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Приведенный мной код - это только часть процедуры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:11 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
К сожалению весь код Delphi без использования Exit и с лишними begin/end DelphiМогло бы быть Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: pascal 1. 2. 3. 4. 5. 6. 7. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. Код: pascal 1. 2. 3. 4. 5. 6. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: pascal 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock Значит, нужен цикл по контролам, используя свойство Tag. Так будет ещё хуже. А нужно там тривиальное Код: pascal 1. 2. 3. 4. 5. 6. Это если не задаваться вопросом о том, что для "шести одинаковых по сути фрагментов" следует использовать решения, поддерживающие множественность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:18 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
DimaBr, Ага, Exit, Break и Continue отлично сокращает лесенки. Но надо быть аккуратным в использовании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:21 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock fraks пропущено... Else тут не нужен нигде. Каждая строка отвечает за свою настройку, независимо от других. Эээээ. я совсем перестал понимать что такое хорошо. Зачем мне цикл по N контролам на форме, причем увидеть что конкретно в этот цикл попадет - весьма непросто, вместо 6 одинаковых строк с прямыми ссылками на контролы, из которых все очевидно? Если можно сделать просто кодом, без визуальщины - так и нужно сделать. Меньше потенциальных глюков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:28 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer YuRock Значит, нужен цикл по контролам, используя свойство Tag. Так будет ещё хуже. А нужно там тривиальное Код: pascal 1. 2. 3. 4. 5. 6. Это, конечно, улучшит ситуацию на 17% :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:28 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
DimaBr К сожалению весь код Delphi без использования Exit и с лишними begin/end В 94-м году я тоже писал "без exit и с лишними begin/end". Мир развивается. P.S. Впрочем, сейчас заглянул в исходники конца 80-х - в части случаев уместные exit я использовал и тогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:28 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer defecator а я очень сильно люблю именно этот метод. позволяет избавиться от излишней вложенности условий. Сразу отсёк на входе в подпрограмму то, что не соответствует условиям, и пишешь только функциональный код Любовь к этому методу появляется у тех, кто достаточно повозился со сложными и запутанными условиями, задолбался править вызванные ими баги и начал ценить упрощение и даваемые им блага. Именно. Все эти простые варианты просты пока не наступит пора их переделать. При переделке вся эта простота оборачивается необходимостью переписать всю логику по новой, но уже на нормальных условиях, без бегства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ fraks пропущено... PowerShell прикольная штука, но это нужно дополнительно изучать, и плюс там проблемка с запуском скрипта. Если все по феншую то скрипт должен иметь подпись чтобы запускаться. Или нужно полностью отключить защиту от запуска. Отключить что-то меня стремает, а подписывать - какая-то очень непростая песня, решил что пока обойдусь. Ага, а bat - файлы неподписанные не стремает... Ну да, есть такое двоемыслие :) У нас еще довольно много машинок под WnXP где этого PowerShell нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:33 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks, сказочник ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:36 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer YuRock Значит, нужен цикл по контролам, используя свойство Tag. Так будет ещё хуже. А нужно там тривиальное Код: pascal 1. 2. 3. 4. 5. 6. Это если не задаваться вопросом о том, что для "шести одинаковых по сути фрагментов" следует использовать решения, поддерживающие множественность. Это нормальный вариант. Если случиться переделать - буду в этом направлении двигаться. Множественность вообще и множественность по сильно ограниченному множеству - не всегда есть смысл связываться с множеством. Здесь одна только попытка перебрать контролы убъет весь смысл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:45 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock softwarer пропущено... Так будет ещё хуже. А нужно там тривиальное Код: pascal 1. 2. 3. 4. 5. 6. Это, конечно, улучшит ситуацию на 17% :) А цикл по Tag несомненно улучшит и работу и читабельность на 100%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:47 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks не всегда есть смысл связываться с множеством Наличие Код: plaintext 1. 2. 3. 4. 5. означает, что любой работающий с ними код будет иметь тенденцию к шестикратному копированию. А это - очень существенный аргумент в пользу того, чтобы сразу от такого уйти. Потому что если я, допустим, в случае чего придумаю, как без этого обойтись, то добрая половина разработчиков на голубом глазу возьмёт фрагмент строк в пятьдесят и откопирует его пять раз, меняя в нём CFG.LT_GoodsMark_ID_LTA1 на CFG.LT_GoodsMark_ID_LTA2... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 16:57 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks не всегда есть смысл связываться с множеством Наличие Код: plaintext 1. 2. 3. 4. 5. означает, что любой работающий с ними код будет иметь тенденцию к шестикратному копированию. А это - очень существенный аргумент в пользу того, чтобы сразу от такого уйти. Потому что если я, допустим, в случае чего придумаю, как без этого обойтись, то добрая половина разработчиков на голубом глазу возьмёт фрагмент строк в пятьдесят и откопирует его пять раз, меняя в нём CFG.LT_GoodsMark_ID_LTA1 на CFG.LT_GoodsMark_ID_LTA2... В данном месте 50 элементов невозможно принципиально, я уже писАл, это цветА. Перебрать контролы в виде множества - отдельная заморочка. В данном случае проще делать именно так, поименные переменные в конфиге. Я единственный разработчик этого продукта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:04 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks В данном месте 50 элементов невозможно принципиально, я уже писАл, это цветА Шестикратное копирование - уже достаточно плохо. fraks Я единственный разработчик этого продукта. Не факт, что так сохранится навечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:07 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer означает, что любой работающий с ними код будет иметь тенденцию к шестикратному копированию. У нас на работе есть питонист, самостоятельно переучившийся из 1С-ника. Он любитель хардкодить частные случаи, из чего проистекает то что любой код у него в единственном экземпляре. Одинаковых баз у нас штук 10, но справочники в каждой - свои. Бэкапов не любит, системы контроля версий не использует вообще. Вот это - проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:10 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks В данном месте 50 элементов невозможно принципиально, я уже писАл, это цветА Шестикратное копирование - уже достаточно плохо. Переделки этого кода не сулят никаких выгод. softwarer fraks Я единственный разработчик этого продукта. Не факт, что так сохранится навечно. Я не в ответе за чужие ошибки в будущем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Я не в ответе за чужие ошибки в будущем. Не в ответе. Но код, который уберегает от ошибок, качественнее, чем код, который к ним подталкивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:21 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> Это был бы такой же шаг в прошлое с его end if, end loop итп. Всему надо знать меру, необязательно от EndClass-a прыгать на EndIf и EndLoop. :) Понятно, что это малоактуально, но если бы был "код методов прямо в декларации" - было бы гораздо более актуально. :) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:29 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks Я не в ответе за чужие ошибки в будущем. Не в ответе. Но код, который уберегает от ошибок, качественнее, чем код, который к ним подталкивает. Если приведешь пример кода, может быть я бы понял о чем речь. Пока что мне видится что любой перевод в N-мерность только усложнит и увеличит количество кода, и приведет к необходимости контролировать это самое N (границы). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Всему надо знать меру, необязательно от EndClass-a прыгать на EndIf и EndLoop. :) Но их история побуждает не прыгать и к end class. Гаджимурадов Рустам Понятно, что это малоактуально, но если бы был "код методов прямо в декларации" - было бы гораздо более актуально. Да. И по этой причине мне не нравится тенденция напихивать в декларации классов всякие хрени в java-стиле. Лучше сохранять компактные декларации классов, при которых достаточно end. Вот, кстати, чего мне действительно не хватает, так это возможности объявить в interface секции только часть класса, а кучу технических деталей убрать в implementation. Что-то вроде partial классов в .net. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:38 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Если приведешь пример кода, может быть я бы понял о чем речь. Имхо, в тот момент, когда ты писал эти строки в CFG, стоило остановиться и сделать их, например, массивом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:42 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks Если приведешь пример кода, может быть я бы понял о чем речь. Имхо, в тот момент, когда ты писал эти строки в CFG, стоило остановиться и сделать их, например, массивом. И как потом к ним обращаться? Вот конкретно этот код как будет выглядеть если параметры будут массивом? Код: pascal 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 17:50 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks И как потом к ним обращаться? Как к элементам массива. fraks Вот конкретно этот код как будет выглядеть если параметры будут массивом? Код: pascal 1. 2. 3. 4. 5. 6. 7. Конкретно этот? Код: pascal 1. 2. 3. 4. 5. 6. 7. Неужели без меня было сложно ответить на этот вопрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 18:12 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks И как потом к ним обращаться? Как к элементам массива. fraks Вот конкретно этот код как будет выглядеть если параметры будут массивом? Код: pascal 1. 2. 3. 4. 5. 6. 7. Конкретно этот? Код: pascal 1. 2. 3. 4. 5. 6. 7. Неужели без меня было сложно ответить на этот вопрос? Я думал что массив должен принести какую-то пользу, а принес один вред. Где контроль границ массива? Где инициализация этого массива? Где сокращение кода, хотя бы в перспективе? Количество строк такое же. В чем смысл массива? Я бы еще понял если бы у меня контролы в виде массива были, но ведь нет. Код с конкретными переменными в большинстве случаев проверяется при компиляции. С массивом - неа, в рантайме извольте словить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 18:21 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Я думал что массив должен принести какую-то пользу, а принес один вред. И ты придумал эту фразу ещё до того, как задал вопрос fraks Где инициализация этого массива? А где инициализация твоих переменных? Ты хоть какую-то логику пытаешься соблюсти? fraks Где сокращение кода, хотя бы в перпективе? Везде. Скажем, если ты сохраняешь этот CFG в какой-нибудь ini-шник - на чтение и запись у них уйдёт по две строки вместо шести. Хотя как и в случае Рустама, количество строк - далеко не главный критерий, на который стоит опираться. fraks Количество строк такое же. В чем смысл массива? Смысл массива в том, что разработчик, когда начнёт писать подобные шесть строк - задумается и напишет получше. fraks Я бы еще понял если бы у меня контролы в виде массива были И в чём проблема сделать их в виде массива? И, например, вместо шести строк ResetCodes, о которых шла речь выше, остаётся одна: Код: pascal 1. fraks Код с конкретными переменными в большинстве случаев проверяется при компиляции. С массивом - неа, в рантайме извольте словить. Ты сам не первый час бьёшь себя пяткой в грудь о том, что их шесть, ровно шесть и никогда не будет иначе. Так какой тебе контроль нужен? Придумываешь "аргументы" без всякой логики, лишь бы звучали "весомо". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 18:32 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks Я думал что массив должен принести какую-то пользу, а принес один вред. И ты придумал эту фразу ещё до того, как задал вопрос У меня первым пунктом идет понимание что любое действие должно приносить пользу. Если пользы нет - значит это действие вредное. Если пользы я не вижу - значит не трогай, не дорос. От массива вижу только лишние ненужные заморочки. С массивами фиксированного размера работал последний раз наверное в еще в фортране. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 19:03 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks У меня первым пунктом идет понимание что любое действие должно приносить пользу. И это понимание снабжено религиозной верой в то, где есть польза, а где нет. Например, выше я упомянул про сокращение кода - и, уверен, этот фактор моментально перестал быть для тебя полезным. fraks С массивами фиксированного размера работал последний раз наверное в еще в фортране. (пожимая плечами) Ну, для данных фиксированного размера это довольно естественное решение. Но если хочешь, можешь с работать с массивами переменного размера или вообще не с массивами. Скажем, у меня часть свойств реализована как массивы с автодобавлением, бывает крайне удобно. Примерно так: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 19:21 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
если в правой части ещё и пустой строкой отделить, то правая часть будет просто замечательной а левая часть - УГ DimaBr К сожалению весь код Delphi без использования Exit и с лишними begin/end DelphiМогло бы быть Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. Код: pascal 1. 2. 3. 4. 5. 6. 7. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 19:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator если в правой части ещё и пустой строкой отделить, то правая часть будет просто замечательной Вот с этим не соглашусь. Я считаю, что каждый раз, когда внутри подпрограммы хочется написать пустую строку - есть решение лучше. Чаще всего - это комментарий, но в данном случае они излишни. Приведённые Димой варианты лучше, и незачем портить их пустыми строками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 19:26 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> Да. И по этой причине мне не нравится тенденция softwarer> напихивать в декларации классов всякие хрени в java-стиле. softwarer> Лучше сохранять компактные декларации классов Иногда удобно всё вместе, без разделения на декларацию и реализацию. В любом случае, лучше иметь возможность, чем не иметь её (в т.ч. ту, о которой говоришь ты). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 20:43 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Иногда удобно всё вместе, без разделения на декларацию и реализацию. В любом случае, лучше иметь возможность, чем не иметь её К сожалению, не в любом. Я был бы согласен с этим утверждением при условии, что с инструментом работают достаточно компетентные люди, которые не творят совсем уж глупостей. Но в ситуации, когда фича, с одной стороны, не даёт заметных преимуществ при грамотном использовании, а с другой - "заставь дурака богу молиться"... Лучше не давать фичи, главным и единственным результатом которой будут новые тонны говнокода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 21:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Иногда удобно всё вместе, без разделения на декларацию и реализацию. В любом случае, лучше иметь возможность, чем не иметь её (в т.ч. ту, о которой говоришь ты). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 21:54 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer defecator если в правой части ещё и пустой строкой отделить, то правая часть будет просто замечательной Вот с этим не соглашусь. Я считаю, что каждый раз, когда внутри подпрограммы хочется написать пустую строку - есть решение лучше. Чаще всего - это комментарий, но в данном случае они излишни. Приведённые Димой варианты лучше, и незачем портить их пустыми строками. ты что, экономишь строки ? может, ты ещё и комментарии экономишь ???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 22:14 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks под WnXP где этого PowerShell нету. https://www.microsoft.com/ru-ru/download/details.aspx?id=16818 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 22:57 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator ты что, экономишь строки ? Я экономлю опрятность и читаемость кода. Пустая строка - отличный, хорошо видимый разделитель подпрограмм (ну или других деклараций). Использование её внутри программного блока - ничего не даёт (либо даёт экономию комментария, которому стоило бы стоять в этом месте), но снижает её ценность как визуального разделителя. У тех разработчиков, которые пихают пустые строки, я не раз и не два видел вообще чудесный вариант: внутри подпрограмм куча пустых строк, при этом между подпрограммами разделителей нередко нет. Вот уж за что бил бы кирпичом, так именно за это. На всякий случай оговорюсь, что здесь я не имею в виду ассемблер, там зачастую фрагменты стоило разделять пустыми строками парой пустая строка - комментарий. Ну и пустые строки следует использовать в секции деклараций подпрограммы, если там есть вложенные подпрограммы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 23:02 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
У меня пустая строка разделитель логических блоков внутри процедуры. И наличие комментария не отменяет пользы пустой строки перед ним. Между процедурами - 3 пустых строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2021, 23:47 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Иногда удобно всё вместе, без разделения на декларацию и реализацию. В любом случае, лучше иметь возможность, чем не иметь её Нет, эту возможность нужно запретить международной конвенцией, как антигуманную. За кодовой лапшой напрочь теряется интерфейс типа. Чтобы просто понять что делает класс, нужно втыкать, втыкать и втыкать во всё это безумие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 00:18 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey Гаджимурадов Рустам Иногда удобно всё вместе, без разделения на декларацию и реализацию. В любом случае, лучше иметь возможность, чем не иметь её Нет, эту возможность нужно запретить международной конвенцией, как антигуманную. За кодовой лапшой напрочь теряется интерфейс типа. Чтобы просто понять что делает класс, нужно втыкать, втыкать и втыкать во всё это безумие. Если реализация метода короткая - зачем её прятать черте-куда? Должна быть возможность сделать разумно для разработчика. "Пусть расцветают сто цветов" - (с). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 01:36 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Пример, кричащий: класс, реализующий интерфейс. Бессмысленное копирование из интерфейса декларации методов. Класс, возможно, расширяет интерфейс лишь одним-двумя методами. А ты поди отличи эти методы от всего мусора, подтянутого из интерфейса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 01:51 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ Должна быть возможность сделать разумно для разработчика. Благими намерениями... Будь такая возможность, короткими методами ограничиваться никто не будет (особенно, если точить некогда - пилить надо). ъъъъъ А ты поди отличи эти методы от всего мусора, подтянутого из интерфейса. Отличить одно от другого, это уже потом, после того, как понял, что оно вообще делает. Давно взял за правило заключать реализацию интерфейсов в регионы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 02:20 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey Благими намерениями... Будь такая возможность, короткими методами ограничиваться никто не будет (особенно, если точить некогда - пилить надо). Если не будут ограничиваться - значит, разработчики считают, что так делать правильно. Не нравится - не делай так . А если тебя заботят проблемы сопровождения чужого кода, то - "кто на что учился", и вообще, это проблема административная, а не техническая. Когда-то создатель паскалей посчитали программистов несмышлеными идиотами, писающими под себя, и понаставили всюду квадратных колес и бессмысленных ограничений. И в итоге, паскаль скатился до уровня ЯП для маргиналов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 02:43 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ И в итоге, паскаль скатился до уровня ЯП для маргиналов. Единственная причина того, что он скатился в эту позицию - то, что он хорошо получился у Борланда. Если бы Борланд вместо него написал крутой и замечательный Turbo C, весь мир бы сейчас работал на Visual Pascal. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 03:04 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ А если тебя заботят проблемы сопровождения чужого кода, то - "кто на что учился", и вообще, это проблема административная, а не техническая. Проблемы в чужом болоте административно не решаются. Там своя администрация, со своим правильным видением. ъъъъъ Когда-то создатель паскалей посчитали программистов несмышлеными идиотами, писающими под себя, и понаставили всюду квадратных колес и бессмысленных ограничений. И в итоге, паскаль скатился до уровня ЯП для маргиналов. И в итоге появился сишарп. Fixed. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 03:06 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks Я бы еще понял если бы у меня контролы в виде массива были И в чём проблема сделать их в виде массива? И, например, вместо шести строк ResetCodes, о которых шла речь выше, остаётся одна: Код: pascal 1. Я бы записывал эту строку так: Код: pascal 1. 2. 3. 4. 5. 6. при этом она все равно остается неуклюжей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 07:08 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ fraks под WnXP где этого PowerShell нету. https://www.microsoft.com/ru-ru/download/details.aspx?id=16818 Это дополнительный софт, он исходно не установлен. Если можно написать нужное на cmd и в системе ничего не трогать - это нормально. Так же иногда использую финт - если на cmd выходит слишком заморочно, по каким-то причинам, то просто пишу консольную микроулилитку на delphi и вызываю ее из cmd. Никакого лишнего тяжелого софта, все подконтрольно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 07:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer fraks У меня первым пунктом идет понимание что любое действие должно приносить пользу. И это понимание снабжено религиозной верой в то, где есть польза, а где нет. Например, выше я упомянул про сокращение кода - и, уверен, этот фактор моментально перестал быть для тебя полезным. fraks С массивами фиксированного размера работал последний раз наверное в еще в фортране. (пожимая плечами) Ну, для данных фиксированного размера это довольно естественное решение. Но если хочешь, можешь с работать с массивами переменного размера или вообще не с массивами. Я постоянно работаю с массивами переменного размера. Я давно отказался от попыток работать с DataSet, вместо которого у меня самодельный компонент представляющий из себя, по сути, динамический массив рекордов. Если природа данных имеет неопределенное количество элементов - то использую именно его, но при этом и интерфейсно, это отображается либо в гриде либо в крайнем случае в списке. И сохраняется такое в конфиг соответственно, циклом. В рассматриваемом моем примере интерфейсная часть - несколько именованных пунктов меню, поэтому, с учетом что количество этих элементов ограничено как и по смыслу так и чисто физически - нет смысла делать гигантские меню - применять тут массив смысла никакого нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 07:26 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Для меня такая строка нечитаема, не видно ни сколько в ней элементов, ни как они пронумерованы, ни какие там разделители. Да и незачем :) Достаточно понимать, что в ней все контролы этой группы. Впрочем, оформление здесь - не суть. fraks при этом она все равно остается неуклюжей. Ну, если вспомнить, что идёт в качестве уклюжего варианта.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 11:33 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
rgreat У меня пустая строка разделитель логических блоков внутри процедуры. И наличие комментария не отменяет пользы пустой строки перед ним. У меня так же. rgreat Между процедурами - 3 пустых строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 11:44 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
fraks Я бы записывал эту строку так: Код: pascal 1. 2. 3. 4. 5. 6. при этом она все равно остается неуклюжей. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 11:49 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> Я был бы согласен с этим утверждением при условии, softwarer> что с инструментом работают достаточно компетентные softwarer> люди, которые не творят совсем уж глупостей. Я и сам часто придерживаюсь подобного мнения, но можно ведь добавить запрет (опцию) этого на уровне проекта или директивы компилятора. softwarer> Но в ситуации, когда фича, с одной стороны, не даёт softwarer> заметных преимуществ при грамотном использовании Ещё как даёт. Компактность, наглядность. Kazantsev Alexey> За кодовой лапшой напрочь теряется интерфейс типа. Kazantsev Alexey> Чтобы просто понять что делает класс, нужно втыкать, Kazantsev Alexey> втыкать и втыкать во всё это безумие. Я помню, что ты сторонник чистой декларации, да. Автофолдинг спасёт нежелающих втыкать. :) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 13:50 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock> rgreat > Между процедурами - 3 пустых строки. > А вот это я ненавижу, одной строки достаточно, и так все видно. Это дело вкуса. Многие предваряют заголовок процедуры // **** строкой комментария *** - этого вполне достаточно, наглядно и пр. Хорошее решение для всяких Лиспов и пр. скриптов. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 13:52 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
А ещё встречаются такие варианты Код: pascal 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 14:14 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Я и сам часто придерживаюсь подобного мнения, но можно ведь добавить запрет (опцию) этого на уровне проекта или директивы компилятора. Во-первых, это никак не спасёт. Тот, кто собирается наплодить тонну говнокода - и опцию выставит. Ну а во-вторых, такие опции - в принципе плохое решение. Их можно принять, когда из языка убирается что-то плохое, но иногда нужна совместимость со старым кодом - как, например, когда убирали присвоения типизированным константам, но "новое плохое решение с опцией" ещё хуже, чем просто "новое плохое решение". Гаджимурадов Рустам Ещё как даёт. Компактность, наглядность. Я достаточно поработал с языками, где это разрешено, и ни в своём коде, ни в коде других не ощутил пользы, выходящей за "вопрос вкусов". Когда на другой чаше весов объективный ощутимый вред... вкусы того не стоят, имхо. Гаджимурадов Рустам Это дело вкуса. Не совсем. В разделителях должна быть логика. Если между процедурами делать три пустых строки - даже когда сама процедура состоит из трёх строк - значит, их же нужно делать между другими декларациями. Значит, их же нужно делать между вложенными процедурами (внутри которых, в свою очередь, будут сажать пустые строки). В итоге... думаю, код получится слишком уж разреженным. В том смысле, что слишком большая потеря площади экрана, считаемой в "непустых строках". Гаджимурадов Рустам Многие предваряют заголовок процедуры комментарием Вот с этим согласен. Хорошая практика, близкая к обязательной. Хотя сволочное IDE здесь изрядно портит жизнь, поскольку просто обожает при автодополнении лепить новую процедуру между заголовком старой и относящимся к нему комментарием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 14:15 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
DimaBr А ещё встречаются такие варианты Код: pascal 1. 2. 3. Это стиль восьмидесятых. Я тоже так писал года наверное до 87-го. Современный вариант удобнее, но и тот вполне адекватен. По сути это замена цветового выделения ключевых слов, и когда она появилась - от такого написания ушли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 14:18 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Автофолдинг спасёт нежелающих втыкать. :) Для автофолдинга нужна IDE. Я просматриваю чужой код (не только дельфийский, но и жабу и шарпы и плюсы), обычно, в far или mc. Вот, например, читать код оксидженовской rtl, которая написана в таком стиле, это ад, блин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 14:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Это дело вкуса. Многие предваряют заголовок процедуры // **** строкой комментария ***. Но если всё однозначно, подводных камней нет - то и названия процедуры хватает, коммент не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 16:05 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer> Тот, кто собирается наплодить тонну говнокода - и опцию выставит. Не всегда нужно ориентироваться на всяких ламеров и обезьян. Да, это будет проблемой, но если ты с ними не сталкиваешься - тьо и ущерба (тебе) не будет или будет неощутимо. softwarer> Ну а во-вторых, такие опции - в принципе плохое решение. softwarer> "новое плохое решение с опцией" ещё хуже, чем просто softwarer> "новое плохое решение". Это такое НЛП - сделать сомнительный постулат и отталкиваться от него, как от истины. Плохое оно для тебя (и ещё для ламеров и обезьян, которых ты так опасаешься), для других - может оказаться полезным/удобным/хорошим в определённых ситуациях. В любом случае, даже если добавить эту возможность, по дефолту заблокированную - всё равно в массе большинство не сразу станет её использовать, просто по тенденции. > Я достаточно поработал с языками, где это разрешено Ну т.е. в том же шарпе - это плохо и неудобно? > Не совсем. В разделителях должна быть логика. Какая ещё логика в разделителях? softwarer> Если между процедурами делать три пустых строки - softwarer> значит, их же нужно делать между другими декларациями. softwarer> Значит, их же нужно делать между вложенными процедурами Вовсе не значит, ни то, ни другое. В разных ситуациях могут (и должны, и существуют на практике) разные правила оформления, комментирования и пр., в т.ч. могут быть разные разделители. Лично мне не нравятся 3 пустые строки (ни перед методом, ни где-либо ещё), но если кто-то их ставит - я бы не ожидал, что он будет выткать их буквально везде вместо одной строки. > Хотя сволочное IDE здесь изрядно портит жизнь, поскольку > просто обожает при автодополнении лепить новую процедуру > между заголовком старой и относящимся к нему комментарием. Это ты, видимо, про какой-то баг времён ХЕ2/ХЕ3 говоришь, в старых версиях этого не наблюдалось, IIRC (насчёт новых - не знаю, исправили или нет). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 16:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey> Для автофолдинга нужна IDE. Я просматриваю чужой код Мы всё-таки про Delphi говорим и теоретизируем... Даже в твоём случае - тот же NPP умеет фолдинг (и автофолдинг сделать не рокет-саенс). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 16:59 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам Мы всё-таки про Delphi говорим и теоретизируем... Delphi 10.4.2 фолдит регионы: Шёл 2021 год... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 18:06 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer Единственная причина того, что он скатился в эту позицию - то, что он хорошо получился у Борланда. Если бы Борланд вместо него написал крутой и замечательный Turbo C, весь мир бы сейчас работал на Visual Pascal. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 18:20 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey> Delphi 10.4.2 фолдит регионы: О да, я с этим ещё в ХЕ3 натерпелся. Само ужасное - что "это" может как портить код, так и вылетать с AV. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 19:11 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, Мне она код не портила, но вот фолдить за всё время так и не научилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 21:13 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey> Мне она код не портила Там "неточно" воспроизводимый, но довольно стабильный баг, в результате которого в коде (в тексте) возникала "визуальная" чехарда... Малоприятная штука, если ты написал/изменил пару десятков строк и не успел сохраниться - сиди потом и вспоминай, где остановился... Правда, старая ДОСовская привычка чуть-что нажимать Ctrl+S по 5 раз в минуту спасает... :) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2021, 21:45 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock Вот, как надо: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Так я только запросы пишу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2021, 07:10 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
+ к пустым строкам для логического разделения - к реализации в декларации - когда плюсы в универе проходили, поначалу нравилось, но это были лабораторки. На большом проекте размазывание только вносит сумятицу. На дельфях есть прямой read/write пропертей из внутренних полей, и хватит. + к "испуганному стилю" (крутое название :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2021, 10:54 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Dmitry Arefiev ?? [quot bk0010#22310596] softwarer Не С, Бейсик. MS и Borland договорились прекратить развитие Quick Pascal и Turbo Basic соответственно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2021, 20:47 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Борланда уже сто лет как нет никакого. Что вы всё ковыряете засохшее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2021, 21:03 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ъъъъъ Борланда уже сто лет как нет никакого. Что вы всё ковыряете засохшее. ну так ты же дельфи ковыряешь, а оно тоже засохшее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2021, 22:37 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator ну так ты же дельфи ковыряешь, а оно тоже засохшее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2021, 22:56 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator ъъъъъ Борланда уже сто лет как нет никакого. Что вы всё ковыряете засохшее. ну так ты же дельфи ковыряешь, а оно тоже засохшее Мы тут все знатоки вкуса устриц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2021, 11:53 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Опубликовали обновлённое руководство по стилевому оформлению кода Delphi . В частности: Statements Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2021, 19:37 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
GunSmoker Опубликовали обновлённое руководство по стилевому оформлению кода Delphi . В частности: Statements Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2021, 19:41 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. Еще оттуда. Это что, шутка, или серьезно? Не хочу матюкаться и обзываться, так что ничего не скажу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2021, 19:45 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock Еще оттуда. Это что, шутка, или серьезно? Не хочу матюкаться и обзываться, так что ничего не скажу. Ну я бы блок else .. end на один уровень с case поставил, а в остальном что не так? Когда там begin-end присутствует - это самый удобный вариант, ИМХО. Ну и когда однострочники идут вперемешку с блоками, то их тоже на отдельную строчку, да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2021, 20:35 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
alekcvp Ну я бы блок else .. end на один уровень с case поставил, а в остальном что не так? Во-первых, field-префиксы, равно как и прочие, лучше со строчной буквы писать. Во вторых, когда одно- и много-строчные case-ы идут подряд, лучше пустые строки вставлять, иначе при беглом просмотре запросто можно пропустить что-то. Ну и case-else я бы отступом делал, но это уже на любителя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2021, 21:16 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
alekcvp YuRock Еще оттуда. Это что, шутка, или серьезно? Не хочу матюкаться и обзываться, так что ничего не скажу. Ну я бы блок else .. end на один уровень с case поставил, а в остальном что не так? Когда там begin-end присутствует - это самый удобный вариант, ИМХО. Ну и когда однострочники идут вперемешку с блоками, то их тоже на отдельную строчку, да. Зачем нужен этот дополнительный уровень с begin end? И так ведь лесенка case. Необъяснимое уродство. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2021, 23:02 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock Зачем нужен этот дополнительный уровень с begin end? Дополнительный уровень с begin/end удобен либо когда некоторые case-метки слишком длинны, либо когда в некоторых блоках достаточно большие (в смысле количества строк) и длинные (в смысле длины одной строки в символах) действия. Тогда такое форматирование по мне предпочтительно, иначе важные части логики оказываются "слишком справа". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2021, 23:23 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
И все дружно забывают, что это ТОЛЬКО рекомендации. Давайте тогда обсудим, имеет ли право на жизнь конструкция типа: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Я про микс заглавных и строчных, если что.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 01:06 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
DarkMaster И все дружно забывают, что это ТОЛЬКО рекомендации. Давайте тогда обсудим, имеет ли право на жизнь конструкция типа: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Я про микс заглавных и строчных, если что.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 01:19 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock, Во всяком случае - более наглядно с отступами, как по мне... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 01:54 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
А мне нравиЦа!)) Сами практически так пишем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 03:34 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
white_nigger А мне нравиЦа!)) Сами практически так пишем За что вам отдельное cпасибо. Читать легко и приятно. * А то, экономщики строчек, как наведут "красоту компактности", так и выискивай потом по диагоналям - к какому там begin относится этот end, или ещё хужей позаботятся - намусорят комментариями "end; // for if | for for | for do".. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 05:12 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
ma1tus * А то, экономщики строчек, как наведут "красоту компактности", так и выискивай потом по диагоналям - к какому там begin относится этот end А подсветка синтаксиса на что? Правильный end же сам подсветится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 08:39 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
zedxxx ma1tus * А то, экономщики строчек, как наведут "красоту компактности", так и выискивай потом по диагоналям - к какому там begin относится этот end А подсветка синтаксиса на что? Правильный end же сам подсветится. Ага, особенно когда тебе надо быстро посмотреть кусок кода без запуска среды, например на GitHub'e. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 09:20 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
DarkMaster> Давайте тогда обсудим, имеет ли право на жизнь конструкция типа: Давайте обсудим. 1. Не имеет. 2. Где ты её увидел? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 09:41 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Я так и пишу) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 10:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Fr0sT-Brutal Я так и пишу) Всё красиво. Но case c begin глаз режет. Имхо, так лучше Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 11:09 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
DarkMaster И все дружно забывают, что это ТОЛЬКО рекомендации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 11:15 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Barmaley57 Fr0sT-Brutal пропущено... Я так и пишу) Всё красиво. Но case c begin глаз режет. Имхо, так лучше Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 11:39 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock, Вообще идеально. В смысле идеальный фарш. Сиди и одупляйся - где метки, где код, и к какому begin относится вот этот конкретный end. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 11:48 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock А еще лучше - так: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:10 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock А еще лучше - так: Раз здесь соревнование троллей, то я, пожалуй, скажу, что лучше записать этот case в одну строку. Хотя нет. Лучше в две. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:11 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
А как вам это: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:20 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:21 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Barmaley57 Fr0sT-Brutal пропущено... Я так и пишу) Всё красиво. Но case c begin глаз режет. Имхо, так лучше Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. В варианте рекомендации лучше видны разные варианты case, тут их выискивать в тексте нужно, а там сразу видны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:25 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Близнец1980 А как вам это: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Близнец1980 А как вам это: Один из лучших вариантов. Разве что else я делаю тоже с отступом. Но как я уже говорил, этот вариант неудачен в случае Код: pascal 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:30 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer Один из лучших вариантов. Разве что else я делаю тоже с отступом. Но как я уже говорил, этот вариант неудачен в случае Код: pascal 1. 2. Можно ведь так, что-бы далеко не убегало: Код: pascal 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:52 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Близнец1980 Можно ведь так, что-бы далеко не убегало: Можно. Но по мне, в этом случае Код: pascal 1. 2. 3. значительно лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 12:56 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
alekcvp YuRock, Вообще идеально. В смысле идеальный фарш. Сиди и одупляйся - где метки, где код, и к какому begin относится вот этот конкретный end. end - всегда под меткой. Выло бы else - это была бы еще как одна метка. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Идеально. Никакой лапши, как в вариантах выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 13:44 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Близнец1980 А как вам это: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Неясно только, почему перед else нет двух пробелов, ну да ладно, и так всё видно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 13:46 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
zedxxx Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 13:47 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Близнец1980 softwarer Один из лучших вариантов. Разве что else я делаю тоже с отступом. Но как я уже говорил, этот вариант неудачен в случае Код: pascal 1. 2. Можно ведь так, что-бы далеко не убегало: Код: pascal 1. 2. 3. 4. 5. Я так всегда делаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 13:49 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
У меня всегда begin с новой строки. Кроме случаев, когда короткие блоки в одну строчку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 14:44 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Fr0sT-Brutal У меня всегда begin с новой строки. Они, наверно, портят твой код, ведь такие блоки начинается не после доп. строки begin, а сразу. Или ты в таких случаях пустую строку добавляешь для единообразия с комментарием //begin? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 14:52 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock Типа class, case, record, try... Они, наверно, портят твой код, ведь такие блоки начинается не после доп. строки begin, а сразу. Или ты в таких случаях пустую строку добавляешь для единообразия с комментарием //begin? Там само ключевое слово вместо begin. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 15:20 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRockFr0sT-Brutal> У меня всегда begin с новой строки. Не всегда. В паскале достаточно конструкций, где нет begin, но есть end. А - Логика. Почему А? Потому что Альтернативная. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 15:22 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
alekcvp YuRock Типа class, case, record, try... Они, наверно, портят твой код, ведь такие блоки начинается не после доп. строки begin, а сразу. Или ты в таких случаях пустую строку добавляешь для единообразия с комментарием //begin? Там само ключевое слово вместо begin. А оказывается, что begin далеко не во всех блоках есть, и в этих случаях понятно, к чему относится end ))) А на самом деле всё просто - все блоки заканчиваются end (и тут есть исключение - repeat until, ну ладно), и не надо видеть, где там begin, чтобы всё было наглядно. То, что end - это конец блока - видно всегда и всем, при нормальном структурировании без лишних уровней в виде лапши. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 15:40 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам YuRockFr0sT-Brutal> У меня всегда begin с новой строки. Не всегда. В паскале достаточно конструкций, где нет begin, но есть end. А - Логика. Почему А? Потому что Альтернативная.Ну да, я живу в такой реальности: мне кажется, что запутаться в двух уровнях структурирования сложнее, чем в трёх уровнях. Кто живёт в другой реальности - пожалуйста, я ж не против. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 15:42 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
YuRock То, что end - это конец блока - видно всегда и всем, при нормальном структурировании без лишних уровней в виде лапши. Когда кейз структурирован как лапша выше - не видно где начинается конретный блок. Потому что перед ним может идти несколько однострочников без end. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 19:53 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
alekcvp YuRock То, что end - это конец блока - видно всегда и всем, при нормальном структурировании без лишних уровней в виде лапши. Когда кейз структурирован как лапша выше - не видно где начинается конретный блок. Потому что перед ним может идти несколько однострочников без end. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2021, 20:11 |
|
||
|
Флейм про оформление и 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 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Вот, кстати, только что наткнулся в чужом коде на такой замечательный фрагмент: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 14:39 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
А у меня и выбора нет. На работе официальное указание, одна точка выхода из процедуры. И никаких дискуссий :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 18:03 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Ну единственно все стараются их короткими делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 18:09 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Дикий Билл А у меня и выбора нет. На работе официальное указание, одна точка выхода из процедуры. И никаких дискуссий :) это п...ц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 18:51 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
defecator это п...ц Причем такая фишка тянется из-за доисторических делфей, в которых не было нормального выделения точки выхода. К вопросу о том, как "хорошо" сидеть на делфи 7 и других ископаемых. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 20:07 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi, несомненно, это единственная причина ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 20:42 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Aleksandr Sharahov JayDi, несомненно, это единственная причина Нет, одна из. Причем не от хорошей жизни. Как и многие другие стандарты оформления/написания кода, которые тянутся с давних времен (как в авиации все правила написаны кровью, так и в программировании все правила написаны миллионами пойманных багов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 20:58 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
JayDi Aleksandr Sharahov JayDi, несомненно, это единственная причина Нет, одна из. Причем не от хорошей жизни. Как и многие другие стандарты оформления/написания кода, которые тянутся с давних времен (как в авиации все правила написаны кровью, так и в программировании все правила написаны миллионами пойманных багов). бла-бла-бла хаос - он не от Delphi 7, он в мозгах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 21:20 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
Идея единственного выхода из подпрограммы умерла вместе с появлением исключений. В принципе. Можно хоть об стенку расшибиться. И в целом, прежде чем носить в сердце какие-то идеи, стоит понимать, в какой среде и в каком контексте они рождались. Расскажу, например, одну поучительную для молодёжи историю. Знаете, как в пятидесятых годах делали overloading подпрограмм? Ну начать стоит с того, как делали сами подпрограммы. Был язык Фортран, и там подпрограмма записывалась как Код: sql 1. 2. 3. а вот для overloading-а там была специальная конструкция, которая называлась ENTRY. Альтернативный вход в подпрограмму. И с ней подпрограмма принимала примерно такой вид: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. вот такую подпрограмму можно было вызывать с 3, 4 или 5 параметрами. И когда в какой-нибудь старой статье написано про вред многих входов в подпрограмму - надо понимать, что у автора перед глазами стояло именно это, а не то, о чём вы подумали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2021, 21:34 |
|
||
|
Флейм про оформление и begin-end
|
|||
|---|---|---|---|
|
#18+
softwarer Идея единственного выхода из подпрограммы умерла вместе с появлением исключений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2021, 06:59 |
|
||
|
|

start [/forum/topic.php?all=1&fid=58&tid=2037285]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
188ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
276ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 513ms |

| 0 / 0 |
