Здравствуйте, Andrey Rubayko, Вы писали:
AR> AN>>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.
AR> Неужели вы занимаетесь ревью чужого кода?
Всем иногда приходится это делать
AN>> ST> AN>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?
AN>> ST> Более того, я осмелился этот код переписать. Вот что у меня вышло:
AN>> А для NET 2.0 это тоже будет работать? AN>Будет, если либу загрузить...
AN>А если не нужны "чужие сообщения" либо вообще какие либо сообщения?
Мне только кажется или ты общаешься сам с собой?
По поводу вопроса о NET 2.0: я же просто отрефакторил этот код слегка, после чего он стал на порядок проще. Единственное, что нужно добавить явную проверку аргументов с генерацией ArgumentException, а не использовать контракты (я, кстати, об этом в комментарии явно указал)
А по поводу ваших QA и паранойи: почему вы думаете, что лишние проверки улучшают качество кода? Они это качество, как раз таки ухудшают, ибо понять код сложнее, кода больше, вероятность ошибок возврастает, ведь вполне можно забыть добавить еще одну проверку при добавлении очередной строки кода.
Кстати, CopyTo здесь не подойдет, поскольку мы можем копировать из своего массива в свой же массив (там условие есть и вполне может быть, что newBuffer будет указывать на buffer), в результате мы получим выход за границу массива.
Да, и проверка на отрицательность длины тоже есть, но сделано это неявно здесь:
Здравствуйте, SergeyT., Вы писали:
ST> AN>> ST> AN>Интересно сколько времени вам понадобилось, что бы понять как функция точно работает?
ST> AN>> ST> Более того, я осмелился этот код переписать. Вот что у меня вышло:
ST> AN>> А для NET 2.0 это тоже будет работать?
ST> AN>Будет, если либу загрузить...
ST> AN>А если не нужны "чужие сообщения" либо вообще какие либо сообщения?
ST> Мне только кажется или ты общаешься сам с собой?
Ну после того как я задал вопрос, глянул специально и появился ответ, так как до того казалось что чисто для 4-ки. Просто раз вы уже пользуете "Контракты", то есть опыт, поэтому посчитал что будет лучше задать новый вопрос, хотя похоже это также продумано.
ST> По поводу вопроса о NET 2.0:
просто было интересно, не поймите как критику.
ST> А по поводу ваших QA и паранойи: почему вы думаете, что лишние проверки улучшают качество кода?
Это видимо надо переносить в раздел "священные войны".
ST> Они это качество, как раз таки ухудшают, ибо понять код сложнее, кода больше, вероятность ошибок возрастает, ведь вполне можно забыть добавить еще одну проверку при добавлении очередной строки кода.
Как то связать не могу, если проверок не будет, значит вероятность появления ошибок уменьшается?
Здравствуйте, AlexNek, Вы писали:
ST>> Они это качество, как раз таки ухудшают, ибо понять код сложнее, кода больше, вероятность ошибок возрастает, ведь вполне можно забыть добавить еще одну проверку при добавлении очередной строки кода. AN>Как то связать не могу, если проверок не будет, значит вероятность появления ошибок уменьшается?
А ты сравни исходный код и мой, и скажи, в каком вероятность ошибок выше.
Если следовать твоей логике, то вероятность ошибок в моем коде должна быть в 5 раз выше, ведь именно во столько раз там меньше проверок
Проверок не должно быть много, их должно быть нужное количество и в нужном месте.
ST>> А по поводу ваших QA и паранойи: почему вы думаете, что лишние проверки улучшают качество кода? AN>Это видимо надо переносить в раздел "священные войны".
, чтобы понять отличия защитного и контрактного программирования (кстати, даже в защитном программировании никто не параноит настолько, чтобы проверять одно и тоже десять раз в *одной* функции) и самим сделать вывод (или, опять таки, просто сравните два варианта кода).
Здравствуйте, SergeyT., Вы писали:
ST> ST>> Они это качество, как раз таки ухудшают, ибо понять код сложнее, кода больше, вероятность ошибок возрастает, ведь вполне можно забыть добавить еще одну проверку при добавлении очередной строки кода.
ST> AN>Как то связать не могу, если проверок не будет, значит вероятность появления ошибок уменьшается?
ST> А ты сравни исходный код и мой, и скажи, в каком вероятность ошибок выше.
Исходный код сравнивать нечего его уже давно не существует в приведенном виде.
ST> Если следовать твоей логике, то вероятность ошибок в моем коде должна быть в 5 раз выше, ведь именно во столько раз там меньше проверок
Логика то как раз не моя (и кстати не такая)
кода больше, вероятность ошибок возрастает, ведь вполне можно забыть добавить еще одну проверку при добавлении очередной строки кода
А хотел сказать, что не вижу связи между наличием "правильной" проверки и количеством ошибок.
ST> ST>> А по поводу ваших QA и паранойи: почему вы думаете, что лишние проверки улучшают качество кода?
ST> AN>Это видимо надо переносить в раздел "священные войны".
ST> Нет, не нужно Лучше почитать
если я и прочту то QA уж точно нет
Здравствуйте, AlexNek, Вы писали:
ST>> Если следовать твоей логике, то вероятность ошибок в моем коде должна быть в 5 раз выше, ведь именно во столько раз там меньше проверок
AN>Логика то как раз не моя (и кстати не такая) AN>
кода больше, вероятность ошибок возрастает, ведь вполне можно забыть добавить еще одну проверку при добавлении очередной строки кода
AN>
Я, если честно, запутался Я здесь имел ввиду следующее: попробуйте добавить еще какую-нибудь логику в исходный пример. Это потребует в каждом обращении к buffer или newBuffer добавлять проверки, что еще сильнее ухудшит качество кода и может привести к тому, что кто-то добавит логику без этой проверки и все поломает. Все это решается одной проверкой вначале метода.
AN>А хотел сказать, что не вижу связи между наличием "правильной" проверки и количеством ошибок.
Я имел ввиду, что в исходном примере, проверки "неправильные", в моем примере — они "правильные". "Неправильные" проверки — ухудшают качество, "правильные" проверки — улучшают.
ST>> ST>> А по поводу ваших QA и паранойи: почему вы думаете, что лишние проверки улучшают качество кода?
ST>> AN>Это видимо надо переносить в раздел "священные войны".
ST>> Нет, не нужно Лучше почитать AN>если я и прочту то QA уж точно нет
Дать читать менеджменту, если он этого еще не читал. Если и он не осилит — уходить.
Здравствуйте, AlexNek, Вы писали:
AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.
25 см?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
FRE> AN>Что то часто мне стал попадаться код в который сразу не врубишься, при этом код делает свою задачу правильно. Предлагаю постить сюда ваши образчики и комментарии.
FRE> 25 см?
Ну если это код, то я зелёный
Здравствуйте, SergeyT., Вы писали:
ST> ST>> Если следовать твоей логике, то вероятность ошибок в моем коде должна быть в 5 раз выше, ведь именно во столько раз там меньше проверок
ST> AN>Логика то как раз не моя (и кстати не такая) ST> AN>
кода больше, вероятность ошибок возрастает, ведь вполне можно забыть добавить еще одну проверку при добавлении очередной строки кода
ST> AN>
ST> Я, если честно, запутался Я здесь имел ввиду следующее: ST> попробуйте добавить еще какую-нибудь логику в исходный пример.
Ну если еще не забыли, исходный пример выложен под рубрикой "как не надо писать код"
Иначе говоря, нужно размышлять о чем то более обобщенном. ST> Это потребует в каждом обращении к buffer или newBuffer добавлять проверки, что еще сильнее ухудшит качество кода
Почему потребует? ST>и может привести к тому, что кто-то добавит логику без этой проверки и все поломает. Все это решается одной проверкой вначале метода.
где то вдалеке появился свет, но если можно было привести примерчик... ST> AN>А хотел сказать, что не вижу связи между наличием "правильной" проверки и количеством ошибок.
ST> Я имел ввиду, что в исходном примере, проверки "неправильные", в моем примере — они "правильные". "Неправильные" проверки — ухудшают качество, "правильные" проверки — улучшают.
Я так и подумал, когда писал, что нужно определить понятие "правильный" в данном контексте. Я имел в виду, что если вместо ожидаемой ("правильной") проверки "а!=null" будет написано "а==null".
Однако Ваша идея понятна.
ST> ST>> ST>> А по поводу ваших QA и паранойи: почему вы думаете, что лишние проверки улучшают качество кода?
ST> ST>> AN>Это видимо надо переносить в раздел "священные войны".
ST> ST>> Нет, не нужно Лучше почитать
ST> AN>если я и прочту то QA уж точно нет
ST> Дать читать менеджменту, если он этого еще не читал. Если и он не осилит — уходить.
Проблема в том, что данные статьи они в принципе не смогут прочитать.
Ну а если уходить по подобным поводам, то надо каждый месяц менять работу
Хорошо, что один только метод кривой, а когда весь проект, это ужас просто =)
Вот пример "КАК ТОЧНО НЕ НАДО ПИСАТЬ КОД":
P.S. Кода много (около 1000 строк). Проект не буду высылать, там вообще ужас.
Для разогрева, есть такой компонент графический Memo в Borland C++ Builder,
ну так вот в этом коде одному из компонентов Memo присвоено свойство Visible = false и используется как буфер при расчетах ))
Здравствуйте, xobotik, Вы писали:
x> Хорошо, что один только метод кривой, а когда весь проект, это ужас просто =)
Ну этого просто нельзя допускать x> Вот пример "КАК ТОЧНО НЕ НАДО ПИСАТЬ КОД":
Ну самую "смешную" функцию можно было
x> P.S. Кода много (около 1000 строк).
У нас немного разные понятия о много кода 1000 строк для одного файла, еще можно сказать много. Но называть проектом 1000 строк кода... x> Проект не буду высылать, там вообще ужас. x> Для разогрева, есть такой компонент графический Memo в Borland C++ Builder, x> ну так вот в этом коде одному из компонентов Memo присвоено свойство Visible = false и используется как буфер при расчетах ))
Для Борланда непохоже, наверное стащили где то
x> жесть.rar Размер 6 кб.
Здравствуйте, xobotik, Вы писали:
x> То есть допустим на входе массив, необходимо сместить данные на одну позицию влево и добавить что-то в array[0]?
Массив 1,2,3,4,5
Результат 99,1,2,3,4,5
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, xobotik, Вы писали:
x>> Хорошо, что один только метод кривой, а когда весь проект, это ужас просто =) AN>Ну этого просто нельзя допускать
Да нельзя, ну что поделаешь, когда тебе дают задание рефакторить сие чудо)
x>> Вот пример "КАК ТОЧНО НЕ НАДО ПИСАТЬ КОД": AN>Ну самую "смешную" функцию можно было
x>> P.S. Кода много (около 1000 строк). AN>У нас немного разные понятия о много кода 1000 строк для одного файла, еще можно сказать много. Но называть проектом 1000 строк кода...
Гавно-кода и 1000 строк много)
x>> Проект не буду высылать, там вообще ужас. x>> Для разогрева, есть такой компонент графический Memo в Borland C++ Builder, x>> ну так вот в этом коде одному из компонентов Memo присвоено свойство Visible = false и используется как буфер при расчетах ))
AN>Для Борланда непохоже, наверное стащили где то
Не я писал, точно)
Здравствуйте, xobotik, Вы писали:
x> x>> Хорошо, что один только метод кривой, а когда весь проект, это ужас просто =)
x> AN>Ну этого просто нельзя допускать
x> Да нельзя, ну что поделаешь, когда тебе дают задание рефакторить сие чудо)
Мои соболезнования.
В таком случае наверное быстрее будет все с нуля написать.
Был такой вариант, кода правда побольше было. Один человек занялся оптимизацией кода в рабочей программе, другой начал разработку с нуля.
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, xobotik, Вы писали:
x>> x>> Хорошо, что один только метод кривой, а когда весь проект, это ужас просто =)
x>> AN>Ну этого просто нельзя допускать
x>> Да нельзя, ну что поделаешь, когда тебе дают задание рефакторить сие чудо) AN>Мои соболезнования.
Не, я это послал куда подальше =) AN>В таком случае наверное быстрее будет все с нуля написать.
Быстрее, когда есть постановка задачи) AN>Был такой вариант, кода правда побольше было. Один человек занялся оптимизацией кода в рабочей программе, другой начал разработку с нуля.
Класс, персонал большой значит )
AN>Чтобы понять как работает также нужно напрягаться. AN>Называется "экономия строк"
Особенно любит впихнуть как можно больше в одну строку местный мыщьх. Просто обожает оператор "запятая." Это, видать, его последователи.
Вообще считаю, что у человека должно быть развито чувство вкуса, чувство меры и чувство прекрасного (как бы напыщенно это не звучало) чтобы писать понятный код.
Здравствуйте, xobotik, Вы писали:
x> x>> x>> Хорошо, что один только метод кривой, а когда весь проект, это ужас просто =)
x> x>> AN>Ну этого просто нельзя допускать
x> x>> Да нельзя, ну что поделаешь, когда тебе дают задание рефакторить сие чудо)
x> AN>Мои соболезнования.
x> Не, я это послал куда подальше =)
Хорошо когда есть выбор. x> AN>В таком случае наверное быстрее будет все с нуля написать.
x> Быстрее, когда есть постановка задачи)
Узнаю дядю Васю x> AN>Был такой вариант, кода правда побольше было. Один человек занялся оптимизацией кода в рабочей программе, другой начал разработку с нуля.
x> Класс, персонал большой значит )
Все относительно, сколько бы народа не было его всегда не хватает.
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, xobotik, Вы писали:
x>> То есть допустим на входе массив, необходимо сместить данные на одну позицию влево и добавить что-то в array[0]? AN>Массив 1,2,3,4,5 AN>Результат 99,1,2,3,4,5
// 1public static T[] AddToFirst<T>(this T[] array, T item)
{
if (array == null) return new T[0];
T[] newArray = new T[array.Length + 1];
newArray[0] = item;
for (int i = 0; i < array.Length; i++)
{
newArray[i + 1] = array[i];
}
return newArray;
}
// 2public static void AddToFirst<T>(ref T[] array, T item)
{
if (array == null) return;
T[] newArray = new T[array.Length + 1];
newArray[0] = item;
for (int i = 0; i < array.Length; i++)
{
newArray[i + 1] = array[i];
}
array = newArray;
}
в первом варианте решения нравится сценарий вызова:
int[] array = new int[10];
array = array.AddToFirst(100);
Но метод 2 получше ибо по аналогии с другими классами .NET, методы имеющие слово Add в названии, все таки в основном возвращают void.
Да и в вашем случае, как я понял, массив необходимо передавать через ref.
Если конечно обобщенные методы не устраивают, а необходимо передавать массив byte,
то можно воспользоваться следующими материалами, там вроде как решаются похожие задачи с упором на производительность:
1) http://codelab.ru/task/cycle_shift/;
2) http://habrahabr.ru/blogs/algorithm/101059/;
3) http://devels.ru/?what=art&p=486.
Автор(ы): Бертран Мейер
