Re[2]: Как не надо писать код
От: AlexNek  
Дата: 11.04.11 16:31
Оценка:
Здравствуйте, sergey_shandar, Вы писали:

s> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно.


s> Один вопрос: человек до этого кодил на C или C++? А то у меня Deja vu.

Мне это неизвестно. Обычно он пишет на Дельфях приложения несколько критичные ко времени выполнения.
avalon 1.0rc3 rev 380, zlib 1.2.3
Re[12]: Как не надо писать код
От: AlexNek  
Дата: 11.04.11 16:31
Оценка:
Здравствуйте, xobotik, Вы писали:

x> AN>Вы наверное еще не были в разделе "открытые проекты" и RSDN@Home?


x> Неа =) надо покурить этот хоум=)

Осторожно — можно подсесть капитально

x> А по поводу задачки, ну вот вроде решил:

Ну задачки для решения вроде не ставилось, но за прилежание
x>
x>         public void WriteTransformation(ref byte[] buffer, ref int dataLength, WriteByteHandler handler)
x>         {
x>             if (buffer == null) return;
x>             if (dataLength < 0) return;
x>             if (handler == null) return;

x>             if (dataLength < buffer.Length)
x>             {
x>                 for (int i = dataLength; i > 0; i--)
x>                 {
x>                     buffer[i] = buffer[i - 1];
x>                 }
x>                 buffer[0] = PREFIX;
x>             }
x>             if (dataLength >= buffer.Length)
x>             {
x>                 byte[] newArray = new byte[dataLength + 1];
x>                 for (int i = 0; i < buffer.Length; i++)
x>                 {
x>                     newArray[i + 1] = buffer[i];
x>                 }
x>                 newArray[0] = PREFIX;
x>                 buffer = newArray;
x>             }
x>             dataLength++;
x>         }
x>

x> P.S. Конечно можно было выделить как минимум один дополнительный метод это сдвиг элементов массива в право на N позиций,
x> но стоит задача в рамках одного метода реализовать, как я понял.
x> Так же конечно можно было воспользоваться встроенным методом Array.Copy вместо участка кода:
Что мне лично тут не нравиться
— вместо
if (dataLength < buffer.Length)
  {
     ...
  }
  if (dataLength >= buffer.Length)

лучше было бы.
if (dataLength < buffer.Length)
  {
     ...
  }
else

А то начинаешь мучительно думать,каким образом получается dataLength > buffer.Length и кстати, в этом случае, код будет неправильно работать.
— Для одного и того же действия используются различные имплементации.
— Старый алгоритм работы метода не был скопировал, а именно, что при "нулевом" буфере возвращается префикс.
x>
x> for (int i = 0; i < buffer.Length; i++)
x> {
x>     newArray[i + 1] = buffer[i];
x> }
x>

x> код:
x>
x> Array.Copy(buffer, 0, newArray, 1, buffer.Length);
x>

x> но как-то нарушается эстетика всего метода, а конкретнее симметрия, чисто мое мнение =)
x> Да и еще не рассмотрел случай, когда передается пустой buffer, но dataLength отлична и больше нуля, надо ли рассматривать такой случай?
Ценное замечания, старая функция на этом пролетает.
Надо рассматривать все что "выбьет" метод, может быть и спорно, на зато QA не будут получать повода для радости и уколок.
avalon 1.0rc3 rev 380, zlib 1.2.3
Re: Как не надо писать код
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.04.11 03:59
Оценка: 41 (5) +4
Здравствуйте, AlexNek, Вы писали:

AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.



public void WriteTransformation(ref byte[] buffer, ref int dataLength, WriteByteHandler writeByteHandler)
{
  if (writeByteHandler == null)
    return;
  if (dataLength < 0)
    throw new ArgumentOutOfRangeException("Data length should be non-negative", dataLength, "dataLength");
  if (buffer == null)
    buffer = new byte[0];
  if (dataLength > buffer.Length)
    throw new ArgumentOutOfRangeException("Data length should not exceed the buffer length", dataLength, "dataLength");

  var newBuffer = new byte[dataLength+1];

  newBuffer[0] = PREFIX;
  Array.Copy(buffer, 0, newBuffer, 1, dataLength);
  buffer = newBuffer;
  dataLength++;
}


AN>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?

Довольно много.
Из глупостей:
1. Попытки на ходу исправить bufferLength. Зачем? Отрицательные размеры, а также размеры более длины переданного буфера не имеют физического смысла. Вместо того, чтобы пытаться их как-то скорректировать, нужно выбрасывать исключение — пусть вызывающая сторона исправляет свой код.
2. Попытки схитрить с переиспользованием существующего буфера. Зачем? Это что, оптимизация? Для оптимизации нужны результаты профайлера. Судя по остальному коду, профайлер этого никогда не мерил. Ну так и незачем заниматься усложнением на ровном месте. Выделяйте буфер всегда. Дорогая операция здесь — копирование, которое происходит в любом случае. Выделение пары сотен байт из кучи в управляемой среде ничего не стоит.
3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.
4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс.
5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Как не надо писать код
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.04.11 04:01
Оценка:
Здравствуйте, SergeyT., Вы писали:

ST>Здравствуйте, AlexNek, Вы писали:


AN>>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.

ST>[skiped]

AN>>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?


ST>Более того, я осмелился этот код переписать. Вот что у меня вышло:


Если я правильно понял, то передача buffer == null и bufferLength = 0 — корректна. В этом случае нужно вернуть буфер единичного размера с префиксом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Как не надо писать код
От: Sinix  
Дата: 14.04.11 04:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Если я правильно понял, то передача buffer == null и bufferLength = 0 — корректна. В этом случае нужно вернуть буфер единичного размера с префиксом.

Но это нифига непонятно и неожиданно. Лучше явно декларировать свои намерения — отдельным методом.
Re[4]: Как не надо писать код
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.04.11 14:27
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>>Если я правильно понял, то передача buffer == null и bufferLength = 0 — корректна. В этом случае нужно вернуть буфер единичного размера с префиксом.

S>Но это нифига непонятно и неожиданно. Лучше явно декларировать свои намерения — отдельным методом.
Не вижу ничего неожиданного в том, что метод трактует new byte[0] и null одинаково.
А вообще — задачи чинить архитектурные проблемы не ставилось. Может, там вообще всё надо нахрен переделать, сократив объём кода раз в пять
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Как не надо писать код
От: AlexNek  
Дата: 14.04.11 16:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

S> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.


S> AN>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?


S> Довольно много.

Как говорится, что и требовалось доказать
S> Из глупостей:
Они и должны были быть в подобном коде (под данной рубрикой) и хорошо что Вы их перечислили.
S> 1. Попытки на ходу исправить bufferLength. Зачем? Отрицательные размеры, а также размеры более длины переданного буфера не имеют физического смысла. Вместо того, чтобы пытаться их как-то скорректировать, нужно выбрасывать исключение — пусть вызывающая сторона исправляет свой код.
В данном случае важнее была работоспособность.
S> 2. Попытки схитрить с переиспользованием существующего буфера. Зачем? Это что, оптимизация? Для оптимизации нужны результаты профайлера. Судя по остальному коду, профайлер этого никогда не мерил. Ну так и незачем заниматься усложнением на ровном месте. Выделяйте буфер всегда. Дорогая операция здесь — копирование, которое происходит в любом случае. Выделение пары сотен байт из кучи в управляемой среде ничего не стоит.
Специальных исследований не проводил, но помнятся противоположные результаты.

S> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.

if (newBuffer != null) if (buffer != null)

Уже только эту строку можно занести в шедевры "как не надо"
S> 4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс.
С последним предложеним как то не совсем понятно
S> 5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам.
Если предоставите линейку напрокат
avalon 1.0rc3 rev 380, zlib 1.2.3
Re[3]: Как не надо писать код
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.04.11 04:42
Оценка: +2 :)
Здравствуйте, AlexNek, Вы писали:
AN>В данном случае важнее была работоспособность.
Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт.
Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор. Именно такие попытки "починить на ходу" отвечают за сверхъестественно выглядящие баги, которые ищутся годами. Поверьте мне — я в детстве тоже так делал.
AN>Специальных исследований не проводил, но помнятся противоположные результаты.
Результаты вам помнятся по С++.

S>> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.

AN>
if (newBuffer != null) if (buffer != null)

AN>Уже только эту строку можно занести в шедевры "как не надо"
Сама по себе строка ничего особенно плохого не содержит. Важен контекст.

S>> 4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс.

AN>С последним предложеним как то не совсем понятно
Посмотрите, сколько раз в исходном коде встречается строчка ...[0] = PREFIX.
Из-за того, что мест больше одного, нет никакой гарантии, что все ветви графа управления проходят через эту строчку. Объединяя ветви в одну и оставляя ровно одно присваивание, мы убеждаемся, что не бывает комбинации условий, когда в качестве префикса остаётся ноль.

S>> 5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам.

AN>Если предоставите линейку напрокат
Можете угрожать wireless-шнуром. Не знаю почему, но неопытные разработчики боятся его до судорог.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Как не надо писать код
От: AlexNek  
Дата: 16.04.11 10:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

S> AN>В данном случае важнее была работоспособность.


S> Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт.

S> Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор.
Вы не учли одной вещи. Что принимающая сторона на линии А всегда ожидает заголовок в ваши 5 байт.
S> Именно такие попытки "починить на ходу" отвечают за сверхъестественно выглядящие баги, которые ищутся годами. Поверьте мне — я в детстве тоже так делал.

Добавка байт была не починкой, а заданием класса/функции. Приведенный код возник когда выяснилось, что посылка вначале заголовка, а потом основного сообщения приводит к ошибкам на некоторых конфигурациях. Исправлять пришлось тому кто это нашел

S> AN>Специальных исследований не проводил, но помнятся противоположные результаты.


S> Результаты вам помнятся по С++.

Может быть. Сейчас решил чисто на шару проверить и получилось даже смешно
           (No new) Repeats 500000 buffer size 256 time 00:00:00.5496574
         (With new) Repeats 500000 buffer size 256 time 00:00:00.4979645
         * 
         * (No new) Repeats 500000 buffer size 512 time 00:00:01.0589830
         (With new) Repeats 500000 buffer size 512 time 00:00:00.9412769
         * 
         * (No new) Repeats 500000 buffer size 1024 time 00:00:02.1139021
         (With new) Repeats 500000 buffer size 1024 time 00:00:01.8606506
         * 
         * (No new) Repeats 100000 buffer size 4096 time 00:00:01.7431369
         (With new) Repeats 100000 buffer size 4096 time 00:00:01.5042657
         * 
         * (No new) Repeats 100000 buffer size 8192 time 00:00:03.3840202
         (With new) Repeats 100000 buffer size 8192 time 00:00:02.9811746

Надо бы еще IL глянуть
        public static void InitBuffer(byte[] buffer)
        {
            for (int i = 0; i < buffer.Length; i++)
            {
                buffer[i] = 0x55;
            }
        }

        private static void TestNoNew(int BufferLength, int RepeatCount)
        {
            byte[] buffer;
            Stopwatch timer = new Stopwatch();
            timer.Start();
            buffer = new byte[BufferLength];
            for (int i = 0; i < RepeatCount; i++)
            {
                InitBuffer(buffer);
            }

            timer.Stop();
            Console.WriteLine("(No new) Repeats {0} buffer size {1} time {2}", RepeatCount, BufferLength, timer.Elapsed);
        }

        private static void TestWithNew(int BufferLength, int RepeatCount)
        {
            byte[] buffer;
            Stopwatch timer = new Stopwatch();
            timer.Start();
            for (int i = 0; i < RepeatCount; i++)
            {
                buffer = new byte[BufferLength];
                InitBuffer(buffer);
            }

            timer.Stop();
            Console.WriteLine("(With new) Repeats {0} buffer size {1} time {2}", RepeatCount, BufferLength, timer.Elapsed);
        }

S> S>> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.

S> AN>
if (newBuffer != null) if (buffer != null)

S> AN>Уже только эту строку можно занести в шедевры "как не надо"

S> Сама по себе строка ничего особенно плохого не содержит. Важен контекст.

С точки зрения форматирования мне страшно понравилось
S> S>> 4. Зачем растить столько ветвей в графе управления? DRY: достаточно ровно одной строки, которая приписывает префикс.

S> AN>С последним предложеним как то не совсем понятно


S> Посмотрите, сколько раз в исходном коде встречается строчка ...[0] = PREFIX.

Должна быть ровно один раз
S> Из-за того, что мест больше одного, нет никакой гарантии, что все ветви графа управления проходят через эту строчку. Объединяя ветви в одну и оставляя ровно одно присваивание, мы убеждаемся, что не бывает комбинации условий, когда в качестве префикса остаётся ноль.

S> S>> 5. Отказ от использования встроенных средств. Array.Copy — то, что доктор прописал. Это мало того, что более понятно, так ещё и более оптимально (там внутри используется развёртка циклов и копирование как минимум по DWORD за раз). За побайтное копирование в 21 веке нужно бить логарифмической линейкой по пальцам.


S> AN>Если предоставите линейку напрокат


S> Можете угрожать wireless-шнуром. Не знаю почему, но неопытные разработчики боятся его до судорог.

У нас сейчас другая страшилка: Будешь писать плохой код прийдет микрософт WER и заберет твою прогу.
avalon 1.0rc3 rev 380, zlib 1.2.3
Re[5]: Как не надо писать код
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.04.11 13:19
Оценка:
Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, Sinclair, Вы писали:


S>> AN>В данном случае важнее была работоспособность.


S>> Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт.

S>> Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор.
AN>Вы не учли одной вещи. Что принимающая сторона на линии А всегда ожидает заголовок в ваши 5 байт.
AN>Добавка байт была не починкой, а заданием класса/функции. Приведенный код возник когда выяснилось, что посылка вначале заголовка, а потом основного сообщения приводит к ошибкам на некоторых конфигурациях. Исправлять пришлось тому кто это нашел

Я не понимаю, о чём вы говорите. Я говорю о том, что код, который отправляет буфер размером в 10 байт, устанавливая bufferLength = 15, заведомо некорректен. Понимаете? Вы в вашем коде вместо того, чтобы сразу упасть (гуглить по fail fast) отправляете 11 байт вместо 16ти. Это может некоторое время выглядеть работающим, но впоследствии приведёт к совершенно сверхъестественному поведению, которое вы будете чинить годами.


S>> Результаты вам помнятся по С++.

AN>Может быть. Сейчас решил чисто на шару проверить и получилось даже смешно
Мерили в релизе или в дебаге?

S>> S>> 3. Повторение избыточных проверок. Это только запутывает код и мешает компилятору со средой проводить оптимизации. Проверили буфер на null один раз, в самом начале — и достаточно. Делать это в цикле тем более не имеет смысла.


S>> AN>
if (newBuffer != null) if (buffer != null)

S>> AN>Уже только эту строку можно занести в шедевры "как не надо"

S>> Сама по себе строка ничего особенно плохого не содержит. Важен контекст.

AN>С точки зрения форматирования мне страшно понравилось
Ну, это уже мелкие красивости, типа i++ + ++i

S>> Посмотрите, сколько раз в исходном коде встречается строчка ...[0] = PREFIX.

AN>Должна быть ровно один раз
Виноват, посмотрел не в ваш код. Да, у вас это таки правильно
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Как не надо писать код
От: AlexNek  
Дата: 16.04.11 14:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

S> S>> AN>В данном случае важнее была работоспособность.


S> S>> Я не понимаю, о какой работоспособности можно говорить в коде, где кто-то присылает массив длинной 10 и просит отправить 15 байт.

S> S>> Значит, автор кода забыл добавить последние 5 байт, и в устройство в результате вашей "починки" уезжает мусор.

S> AN>Вы не учли одной вещи. Что принимающая сторона на линии А всегда ожидает заголовок в ваши 5 байт.

S> AN>Добавка байт была не починкой, а заданием класса/функции. Приведенный код возник когда выяснилось, что посылка вначале заголовка, а потом основного сообщения приводит к ошибкам на некоторых конфигурациях. Исправлять пришлось тому кто это нашел

S> Я не понимаю, о чём вы говорите. Я говорю о том, что код, который отправляет буфер размером в 10 байт, устанавливая bufferLength = 15, заведомо некорректен.

S> Понимаете? Вы в вашем коде вместо того, чтобы сразу упасть (гуглить по fail fast) отправляете 11 байт вместо 16ти. Это может некоторое время выглядеть работающим, но впоследствии приведёт к совершенно сверхъестественному поведению, которое вы будете чинить годами.
Не понимаю также при чем здесь 15/16 байт?

У нас есть специальные куски кода которым просто запрещено выкидывать исключения.
Ну как пример, вы не можете в книге причитать строку. Вместо того чтобы сказать строка не читается, ложи книгу назад (fail fast) мы читаем книгу дальше и просто помечаем строку красным цветом. По моему это более приемлимо для пользователя.

S> S>> Результаты вам помнятся по С++.


S> AN>Может быть. Сейчас решил чисто на шару проверить и получилось даже смешно


S> Мерили в релизе или в дебаге?

Дебаг. Можно и релиз глянуть... получше
  (No new) Repeats 100000 buffer size 8192 time 00:00:02.7632629
(With new) Repeats 100000 buffer size 8192 time 00:00:02.9427531
avalon 1.0rc3 rev 380, zlib 1.2.3
Re[2]: Как не надо писать код
От: MaximUN  
Дата: 21.04.11 16:04
Оценка:
Здравствуйте, SergeyT., Вы писали:

ST>Более того, я осмелился этот код переписать. Вот что у меня вышло:


ST>
ST>public byte[] WriteTransformation(byte[] buffer, int bufferLength)
ST>{
........
ST>}
ST>


В мне кажется ваш код ничем не лучше изначального. Слишком уж сложно для такой довольно тривиальной (правда с несколькими вырожденными случаями) операции. Комментариев — примерно столько же, сколько и кода.
Рядом есть вариант от Sinclair, ИМХО в разы лучше.
Re[7]: Как не надо писать код
От: HowardLovekraft  
Дата: 22.04.11 05:46
Оценка:
Здравствуйте, AlexNek, Вы писали:

AN>У нас есть специальные куски кода которым просто запрещено выкидывать исключения.

Т.е. даже если все хреново, и задача не выполнена, притворись, что все хорошо?
А если исключение выбросит сторонний код, используемый вашим кодом?

Re[8]: Как не надо писать код
От: AlexNek  
Дата: 22.04.11 08:50
Оценка:
Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, AlexNek, Вы писали:


AN>>У нас есть специальные куски кода которым просто запрещено выкидывать исключения.

HL>Т.е. даже если все хреново, и задача не выполнена, притворись, что все хорошо?
HL>А если исключение выбросит сторонний код, используемый вашим кодом?

HL>

Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.
Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится
... << RSDN@Home 1.2.0 alpha 5-AN rev. 351>>
Re[9]: Как не надо писать код
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.04.11 08:55
Оценка: +1
Здравствуйте, AlexNek, Вы писали:

AN>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.

AN>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится

По-вашему исключения придумали что бы морочить ими голову пользователям?
Re[10]: Как не надо писать код
От: AlexNek  
Дата: 22.04.11 09:29
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:


AN>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.

AN>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится

S>По-вашему исключения придумали что бы морочить ими голову пользователям?

Я только говорю, что не следует все мешать в одном корыте
... << RSDN@Home 1.2.0 alpha 5-AN rev. 351>>
Re[11]: Как не надо писать код
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.04.11 10:19
Оценка:
Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:


S>>Здравствуйте, AlexNek, Вы писали:


AN>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.

AN>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится

S>>По-вашему исключения придумали что бы морочить ими голову пользователям?

AN>Я только говорю, что не следует все мешать в одном корыте

Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины.
Re[12]: Как не надо писать код
От: AlexNek  
Дата: 22.04.11 10:31
Оценка: -1
Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:


AN>>Здравствуйте, samius, Вы писали:


S>>>Здравствуйте, AlexNek, Вы писали:


AN>>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.

AN>>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится

S>>>По-вашему исключения придумали что бы морочить ими голову пользователям?

AN>>Я только говорю, что не следует все мешать в одном корыте

S>Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины.

Так что надо вывалить исключение и сказать пшел вон?
По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать.
Смысл в том что блок распознавания страниц должен всегда выдавать результат, а не передавать исключение наверх, те исключения просто обрабатываются "локально"
... << RSDN@Home 1.2.0 alpha 5-AN rev. 351>>
Re[13]: Как не надо писать код
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.04.11 10:40
Оценка:
Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, samius, Вы писали:


S>>Здравствуйте, AlexNek, Вы писали:


AN>>>Здравствуйте, samius, Вы писали:


S>>>>Здравствуйте, AlexNek, Вы писали:


AN>>>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.

AN>>>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится

S>>>>По-вашему исключения придумали что бы морочить ими голову пользователям?

AN>>>Я только говорю, что не следует все мешать в одном корыте

S>>Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины.

AN>Так что надо вывалить исключение и сказать пшел вон?
Сначала надо уловить разницу между тем, что является корректным набором данных для метода и нет. В случае некорректного формата данных нужно кидать исключение сразу, так быстрее найдете то место, где они становятся некорректными. Вам Sinclair дал ссылку на FailFast.

AN>По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать.

Исключение разве мешает это сделать?

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

Кто этот смысл выдумал?

Вообще не пойму, причем тут страницы, до сих пор речь шла о WriteTransformation
Re[14]: Как не надо писать код
От: AlexNek  
Дата: 22.04.11 10:47
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:


AN>>Здравствуйте, samius, Вы писали:


S>>>Здравствуйте, AlexNek, Вы писали:


AN>>>>Здравствуйте, samius, Вы писали:


S>>>>>Здравствуйте, AlexNek, Вы писали:


AN>>>>>>Задача выполнена, но с ошибками. вроде пример с чтением книги приводил.

AN>>>>>>Возьмер допусти OCR прогу. Не может она распознать один символ и выкидывает при этом исключение — "Стор. Не могу распознать символ". Вам это понравится

S>>>>>По-вашему исключения придумали что бы морочить ими голову пользователям?

AN>>>>Я только говорю, что не следует все мешать в одном корыте

S>>>Вот и не мешайте все в одно корыто. На примере OCR почувствуйте разницу между тем когда подали данные с нераспознаваемым символом, и тем когда подали поток данных недостаточной длины.

AN>>Так что надо вывалить исключение и сказать пшел вон?
S>Сначала надо уловить разницу между тем, что является корректным набором данных для метода и нет. В случае некорректного формата данных нужно кидать исключение сразу, так быстрее найдете то место, где они становятся некорректными. Вам Sinclair дал ссылку на FailFast.
Я специально привел пример, когда этого не следует делать.

AN>>По мне, так лучше показать пустую страницу и написать внутри что ее невозможно обработать.

S>Исключение разве мешает это сделать?
Да иногда может.

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

S>Кто этот смысл выдумал?
Наши принципы работы с пользователем

S>Вообще не пойму, причем тут страницы, до сих пор речь шла о WriteTransformation

Просто как более понятный пример
... << RSDN@Home 1.2.0 alpha 5-AN rev. 351>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.