Developing.ru

Часто слышу и вижу что-то вроде "можно упростить код" ну и т.д.

Препод у меня вон постоянно говорит, как они раньше на машинах с 2к памяти работали. Там понятное дело, хочешь не хочешь, а надо код сокращать, если есть возможность.

Мне вот интересно вы стараетесь всегда уменьшить код, оптимизировать, дабы меньше ресурсов чтоб жрал(или ради быстроты) или полагаетесь на то, что с нынешними машинами это не обязательно?


З.Ы. не знал куды тему запихнуть ^_____^

Во-первых. "запихнуть" надо было во флейм.
Во-вторых. Те задачи, который выкладываются на форуме, в большинстве своем не интресны его завсегдатаем. следовательно, они [завсеглатаи] пытаются решить эту задачу наиболее коротким и рациональнам способом, упрощают код до невозможности. в этом их интерес.

З.Ы. знаете, когда делать нечего, среди опытных программистов есть игра:
1) выбирается задача.
2)Решается, каждым по-отдельности.
3)Сравниваются коды. у кого быстрее и меньше строчек в коде, тот и выиграл.
это я так, вкратце.

Смотря в каком случае.
Для простеньких школьных задач это не принципиально, а вот при сложных, многократно повторяемых вычислениях нужно, чтобы код работал быстро. Ни одному пользователю не понравится программа, которая будет тормозить. Или, например, на олимпиадах по программированию всегда есть ограничения типа 64 мб памяти и 2000 мс работы на одном месте. Как-то на олимпиаде практически написав программу еще часа пол сидел, пытаясь уложиться в нужный промежуток времени. А вообще - нужно сразу приучаться писать правильный код, стараться сэкономить ресурсы и время.

MOTOCoder, совершенно согласен свами !!! un4-funeral, мы не стораемся а почти всегда пишем код оптимизированый, тоесть сокрашённый !

Все зависит, от поставленных задач, в основном надо чтобы было сделано быстро и работало, а так же написано понятно, так что зачем оптимизация. Да и разбираться в полиморфном коде не простая задача.

Лично я пишу код в несколько этапов(проходов)
1. Логически разбиваю задачу на подзадачи
2. Пишу рабочий и функциональный код не обращая внимания на реализацию.
3. Убираю все лишнее, оптимизирую некоторые наиболее критичные узлы
4. После (3) становится ясно что алгоритмы довольно простые и все можно было бы сделать гораздо проще.
5. После (4) понимаю, что многие функции можно выразить в одну строчку, а некоторые не нужны совсем.
6. После очистки получаю рабочий и довольно быстрый код.

Такая схема у меня обычно относится к большим и длительным проектам и некоторым задачам с хитрыми алгоритмами. Придерживаюсь следующих мнений:

1. В языках высокого уровня довольно часто код, занимающий одну строку работает в несколько раз медленнее чем тоже самое в нескольких строках. Связано это зачастую с компилятором.
2. Работа с переменными - это всегда работа с памятью, соответственно работа с массивами, индекс которых есть переменная - операция длительная.
3. Из (2) следует, что при работе с массивами из записей гораздо быстрее работать с какой-то конкретной переменной, нежели напрямую с элементом массива.
4. Если требуется работать с указателями, то удобнее использовать ассемблер, т.к. ни один из языков высокого уровня в своей семантике не дает четкой логики в операциях с указателями - т.е. не всегда понятно - производится ли запись в сам указатель либо в адрес куда он указывает.
5. Никогда не кидать в процедуру/функцию массивы и большие структуры, а кидать поинтеры на них. Основано на том, что параметры идут в стек, и таким образом перед вызом происходит их клонирование - помимо памяти это хавает еще и время, особенно в потоковых обработках, когда такие процедуры вызываются много раз.
6. При разработке 32-битных приложений даже если переменная принимает 0 или 1 - желательно задать ей тип DWORD. Это связано с тем, что шина памяти принимает выровненный адрес запрошенного блока. Если это не так, то потребуется прочитать/записать еще один блок. Это замедляет обращение к переменной в 2 раза.
7. Коментарии нужны - коментарии выжны, но стараюсь создавать код, который сам по себе есть коментарий. Относиться к названиям переменных, процедур и функций, классов, типов, меток и пр. идентификаторов.

Еще я стараюсь всегда проводить user-oriented семантическую оптимизацию. К примеру, писал я как-то в одной программе для банковского документооборота функцию для определения високосного года:
if year%4==0 and year%100<>0 or year%400==0:
return 1
else:
return 0
А потом подумал: а зачем нужны две последних проверки? Моя программа - это не памятник нерукотворный, а вполне определенный прикладной продукт. Что будет, если я оставлю в коде только if year%4==0? Программа будет неправильно выдавать високосный год в 1900, 1800, 1700 годах в прошлом и 2100, 2200, 2300 и т.д. - в будущем. Напрашивается вопрос: а с какого рожна меня должны волновать эти даты? В 1900 году банк-заказчик еще не существовал, а если и существовал, уж точно не вел электронный документооборот. А к 2100 году банк уже успеет разориться. Или перейти на другую программу. Или я успею умереть, так что мне будет уже абсолютно параллельно, правильно ли программа, написанная в начале XXI века, определяла високосный год.
Здесь, конечно, оптимизация минимальная, освободили два машинных такта (или четыре, не скажу точно), что практически незаметно, но код стал намного приятнее для чтения.

Еще на Башорге была цитата, разговор программиста и тестировщика. В точности не помню, но смысл такой:
- У тебя ошибки в программе. В поле "Возраст" не влезает больше 2 цифр. Поле "Пол клиента" принимает только два значения "М" и "Ж".
- Вот когда нашей программой начнут пользоваться столетние транссексуалы, тогда это и будет ошибкой

&quot писал(а):Препод у меня вон постоянно говорит, как они раньше на машинах с 2к памяти работали. Там понятное дело, хочешь не хочешь, а надо код сокращать, если есть возможность.

С двумя и даже ста двадцатью восмью килобайтами оптимизация, по-моему, вообще не имеет смысла, так как в эту память всё равно не влезет никакая запись алгоритма решения сложной задачи, а только такая задача и может решаться долго (даже на машинах с тремя и менне мегагерцами). А вот на современных компах, новые проги. решающие недавно возникшие сложные задачи, приходится так оптимизировать, что раньше это сочли бы невозможным. Я недавно писал прогу и мне пришлось прямо в приладе сжать данные в 14,78 раза, иначе она висела намертво.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------

&quot писал(а): Если требуется работать с указателями, то удобнее использовать ассемблер, т.к. ни один из языков высокого уровня в своей семантике не дает четкой логики в операциях с указателями - т.е. не всегда понятно - производится ли запись в сам указатель либо в адрес куда он указывает.

Бред. Наоборот, ассеблер её не даёт. А c++ (явно высокого уровня) даёт такую логику. синтаксис и симантику указателей, что впору перевернуть сисемблер: писать основу на ассемблере, а всё что использует указатели, вставлять на плюсплюсе.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------

&quot писал(а):Коментарии нужны - коментарии выжны, но стараюсь создавать код, который сам по себе есть коментарий. Относиться к названиям переменных, процедур и функций, классов, типов, меток и пр. идентификаторов

Хорошо, что ты это умеешь. Мне кажется, что и я умею, но сомневаюсь. А многи не умеют точно. ССВ, например, (если на формуме есть его тёзка, просьба не обижаться - имеется ввиду не форумчанин) пишет так, что пока в жалких двух тысячах его строк разберёшся, обязатльно плюнешь, напишешь тысяч триста своих и будешь считать, что поленился.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------

&quot писал(а):А потом подумал: а зачем нужны две последних проверки?

Никогда так не делаю. Мой вариант: если заню, что правило четырёхтысячного утверждено, то воткну и его проверку.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------

&quot писал(а):При разработке 32-битных приложений даже если переменная принимает 0 или 1 - желательно задать ей тип DWORD. Это связано с тем, что шина памяти принимает выровненный адрес запрошенного блока. Если это не так, то потребуется прочитать/записать еще один блок. Это замедляет обращение к переменной в 2 раза.

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

&quot писал(а):После (4) понимаю, что многие функции можно выразить в одну строчку, а некоторые не нужны совсем.

Ага. А ещё десять нужных функция оказывается незапалнировано. Пишем их в самом конце для замены инлайнов и других функций.

&quot писал(а):Логически разбиваю задачу на подзадачи
2. Пишу рабочий и функциональный код не обращая внимания на реализацию.

С этого, по-моему, надо начинать. Да не все так делают.

Некрофил .

Duncon писал(а):Некрофил.

Новое - это хорошо забытое старое (мудрая народная мудрость)