Аннотация:
В статье рассматриваются некоторые ошибки, которые часто встречаются в коде программ. Даны рекомендации, как не стоит писать код, на какие этапы разработки кода нужно обращать внимание в первую очередь.
ОЕБ>Авторы: ОЕБ> Burd ОЕБ> Zheka.O
ОЕБ>Аннотация: ОЕБ>В статье рассматриваются некоторые ошибки, которые часто встречаются в коде программ. Даны рекомендации, как не стоит писать код, на какие этапы разработки кода нужно обращать внимание в первую очередь.
эдакий краткий пересказ Мартина "Чистый код". зачем, не ясно
Очень много мест, где личные вкусовые предпочтения авторов подаются как
нечто "очевидное для всех". Со словами "сделаем код проще" предлагаются
простыни вдвое-втрое длиннее исходной, плодится туча мелких функций
используемых 1 раз, нарушается правило единственной точки возврата,
рекомендуется не оставлять комментариев чего этим кодом хотели достичь
(наверно это должно постигаться ясновидением из названия функций).
ОЕБ>Авторы: ОЕБ> Burd ОЕБ> Zheka.O
ОЕБ>Аннотация: ОЕБ>В статье рассматриваются некоторые ошибки, которые часто встречаются в коде программ. Даны рекомендации, как не стоит писать код, на какие этапы разработки кода нужно обращать внимание в первую очередь.
Спасибо за статью.
у меня вопрос по обработкам ошибок.
известны ли авторам типовые решения при обработке ошибок при записи в лог.
предположим есть приложение — робот работающий на отдельном сервере. свои ошибки он записывает в лог (файл, почта, бд...)
как обрабатывать ошибки записи в лог, если их не скрывать?
закрывать приложение? а как же отказоустойчивость?
повторная запись в лог?
кэширование сообщения для лога с последующей записью в лог?
O>простыни вдвое-втрое длиннее исходной, плодится туча мелких функций
таким образом код разбивается на логические куски с возможностью повторного использования.
O>используемых 1 раз, нарушается правило единственной точки возврата, O>рекомендуется не оставлять комментариев чего этим кодом хотели достичь O>(наверно это должно постигаться ясновидением из названия функций).
необходимо называть функции так, что б из ее имени было ясно что она делает.
Здравствуйте, Enomay, Вы писали:
E>люди, которые ленятся читать книги, статьи так же читать не станут. оно им не интересно.
Не всегда дело в лени. У меня на некоторые книги просто нет времени. Приходтся выбирать что читать
Если бы по "отложенным" был бы такой "краткий пересказ", то его бы прочел.
E>необходимо называть функции так, что б из ее имени было ясно что она делает.
"Что" делает, и "для какой цели в данном случае" — вообще говоря не одно и то же.
E>>необходимо называть функции так, что б из ее имени было ясно что она делает. O>"Что" делает, и "для какой цели в данном случае" — вообще говоря не одно и то же.
а что, по коду не ясно для какой цели эта функция используется в другой функции, из названия которой так же очевидно её предназначение?
Здравствуйте, Аноним, Вы писали:
А>как обрабатывать ошибки записи в лог, если их не скрывать?
Места для записи логов бывают разные. Но, в конечном счете — падать.
Если не получилось записать в файл, о какой дальнейшей работе можно вести речь?
Здравствуйте, HowardLovekraft, Вы писали:
А>>как обрабатывать ошибки записи в лог, если их не скрывать? HL>Если не получилось записать в файл, о какой дальнейшей работе можно вести речь?
Позволю себе не согласиться. Допустим, закончилось место на диске, куда пишет лог, но приложение же может работать и дальше. Ну будут сидеть без лога, порой отказоустойчивость важнее логирования.
в общем какого-нибудь универсального решения нет судя по всему.
если закончилось место можно отправить почту или чего-нибудь еще придумать все зависит от приложения и фантазии
главное если почта не отправилась при этом опять не писать а файл
хотелось именно поянять как кто поступает в таких случаях.
Здравствуйте, mrjeka, Вы писали:
M>Позволю себе не согласиться. Допустим, закончилось место на диске, куда пишет лог, но приложение же может работать и дальше. Ну будут сидеть без лога, порой отказоустойчивость важнее логирования.
Исхожу из своих практическийх наблюдений и на истину в последней инстанции не претендую.
Запись в лог — это, обычно, очень примитивная операция, по сравнению с основным функционалом приложения.
Если примитивная операция не выполняется, то с очень высокой вероятностью, остальное тоже работать не будет.
Т. е. скорее всего, вы получите картину, когда вроде и процесс работает, но толку от него нет, полезная работа не выполняется, а диагностическая информация отсутствует.
Да, сходу можно придумать ситуацию, когда лог пишется в базу, и в один прекрасный момент база становится недоступна. Вроде бы ничего страшного. Но, обычно получается так, что это же приложение использует этот же сервер баз данных для работы с основной базой (или вообще лог живет в той же базе, что и рабочие данные). И какой смысл тогда пытаться работать дальше?
Или в вашем примере с местом на диске — вряд ли приложение использует этот диск только для логов. Попытается записать что-то в файл в процессе работы, и что в результате?
А если исключение, возникшее при записи в лог, не столь очевидно и связано с багом в логгере?
Все-таки, обеспечение отказоустойчивости — это комплекс мер. IMHO, не стоит все навешивать исключительно на софт.
Здравствуйте, Osaka, Вы писали:
O>Очень много мест, где личные вкусовые предпочтения авторов подаются как O>нечто "очевидное для всех". Со словами "сделаем код проще" предлагаются O>простыни вдвое-втрое длиннее исходной, плодится туча мелких функций O>используемых 1 раз, нарушается правило единственной точки возврата, O>рекомендуется не оставлять комментариев чего этим кодом хотели достичь O>(наверно это должно постигаться ясновидением из названия функций).
Присоединяюсь. Данный "индусский код" до "модернизации" смотрится понятнее, чем после. Потому как "как слышится, так и пишется", тьфу, "как читается, так и работает", а после изменений — просто то же самое "в голове" смотрящего додумывается. С лишней точкой возврата — точно вредный совет. При переделках кода (например, рефакторинге) влететь с ней — проще простого. С маскировкой исключений — не факт. Есть сценарии, где пустая строка лучше, например, при вычисляемом заполнении ячейки grid. И вообще — может адрес необязателен или, например, потом валидация всей введенной простыни идёт ?
Здравствуйте, Osaka, Вы писали:
O>Очень много мест, где личные вкусовые предпочтения авторов подаются как O>нечто "очевидное для всех". Со словами "сделаем код проще" предлагаются O>простыни вдвое-втрое длиннее исходной, плодится туча мелких функций O>используемых 1 раз, нарушается правило единственной точки возврата, O>рекомендуется не оставлять комментариев чего этим кодом хотели достичь O>(наверно это должно постигаться ясновидением из названия функций).
Какие-то абстрактные наезды. Читал статью, и не припомню таких мест. Хотелось бы более развренутой критики. Типа вот вам цитата, а вот мои мысли по ней.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, HowardLovekraft, Вы писали:
А>>как обрабатывать ошибки записи в лог, если их не скрывать? HL>Места для записи логов бывают разные. Но, в конечном счете — падать.
Зависит от требований.
HL>Если не получилось записать в файл, о какой дальнейшей работе можно вести речь?
Из реальной жизни. РСДН падал просто потому, что на диске куда записывались логи Веб-сервера кончилось место. При этом функциональность сайта не нарушалась. Просто терялись не очень-то нужные логи. Я бы предпочел чтобы сайт работал и слал на мыло админу сообщения, что кончилось место под логи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.