// codeart.ru / Теория программирования / Часть 3. О том, как сократить время на исправление ошибок Форум

Часть 3. О том, как сократить время на исправление ошибок rss подписка

Автор: Evgeniy Sergeev

Проектирование — занятие, безусловно, полезное, но даже хорошая проектная документация не спасет от ошибок при написании кода программы.

Когда-то, очень давно, я наивно полагал, что код бывает двух типов: рабочий и нерабочий. При этом, почему-то, совершенно не думал о том, что исходные тексты программы пишутся не только для интерпретатора или компилятора, но и для других разработчиков.

Спустя время, после достаточно длительной работы с чужими программами, я понял, нельзя писать код в расчете на то, что только тебе придется с ним работать. Потому что, в большинстве реальных проектов, исходники проходят через руки многих людей. Возможно сегодня ты единственный разработчик, но это не значит, что завтра будет так же. Если каждый внесет капельку собственной небрежности в процесс написания программы, в конечном итоге получится нечто напоминающее свалку, а не хорошо отлаженный механизм.

Если код понятен только тебе — это значит, что через некоторое время, никто не сможет с ним эффективно работать! Не верите? Возьмите свои программы годовалой давности и попробуйте воспроизвести собственный ход мыслей. Хорошие программы остаются читабельными даже спустя большие промежутки времени, плохие нет.

Крупные ошибки рождаются из мелких недоработок, сегодня поленился нормально оформить код, завтра это может стать привычкой. А бороться с дурными привычками — занятие неблагодарное. Хотя, даже плохой стиль кодирования можно исправить, если иметь достаточно терпения и желания. Но, все же, лучше сразу приучить себя качественно выполнять свою работу.

Плохой код рождается не потому что программист сознательно к этому стремиться. Маловероятно, что кому-то, в здравом уме и твердой памяти, придет в голову городить огород на пустом месте. В основном, плохой код — результат нехватки времен и опыта. Между тем, существуют несколько правил, которые реально помогают делать мои программы проще, а значит, процесс внесения изменений и исправлений протекает быстрее.

Собственно сами правила:

1. Функция (или метод) может состоять из одной строчки кода (очень часто подобные функции «разбухают» по мере развития проекта);
2. Функция (или метод) могут состоять из сколько угодно большого числа строк, но при этом название функции должно точно отражать реализуемую задачу (если функция выполняет 10 различных задач и все они перечислены в названии, то неправильность такой функции сразу бросается в глаза);
3. Функция (или метод) должны, по возможности, решать только одну задачу;
4. Для всех классов должен выполняться принцип информационной закрытости;
5. Исключить дублирование кода (другими словами, для внесения одного изменения исправляется код только в одном месте);
6. В программировании есть три цифры 0, 1, много (не нужно думать, что если сегодня в массиве всего три элемента, то через некоторое время их будет столько же!);
7. Нужно всегда придерживаться выбранных правил оформления листингов программы (даже ураган, цунами и другие стихийные бедствия не являются основанием для отступления от принятых стандартов);
8. Обратить особое внимание на именование переменных (тема большая, поэтому больше об этом ничего не скажу, чтобы не вступать в обширные дебаты на пустом месте);
9. Не экономить на переменных;
10. Минимизировать время жизни переменной (значит, что между объявлением и использованием переменной должно находиться как можно меньше строк кода).

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

Конец третей части.

Часть 4. Переменные — не деньги, экономить не нужно.

  1. Когда-то давно я тоже не экономил на переменных, и очень сильно об этом пожалел в последствии. Потому что программа, которую я написал, весила 600Кб, а загружалась чуть быстрее, чем фотошоп. По-этому на переменных _нужно_ экономить. Просто нужно научиться хорошо программировать, чтобы обходиться минимумом строк кода и минимумом переменных.

  2. Полезные правила. Возьму на заметку.

  3. mByte, :-) классная параллель между объемом кода и его скоростью! Только я даже представить себе не могу как большое, нет даже очень большое количество переменных повлияло на скорость твоего кода. Рискну предположить, что все же дело было не в переменных!

  4. Евгений, чего-то этим всем частям не хватает…Осмысленности, чтоли..все как-то не на том уровне, что хотелось бы..(Может это только мое мнение?)

    Впечатление после прочтения статьи остается сумбурное.

  5. anycolor, приму к сведению, правда с моей позиции все четко и понятно, видимо писать надо чуток более подробно.

  6. В общем, извини за оскорбление. Отписал у себя и у Маула. Спасибо что пояснил, именно за это (доведение до толка, а не пустоты) и стоит уважать людей. Вот и приходит уважение к тебе, хотя сначало хотелось назвать ……… промолчу 😉

  7. Евгений, дело в том, что когда пишешь компилируемую программу, то все переменные нужно объявить заранее, чтобы программа не залезла в чужое адресное пространство. По-этому все переменные занимают какое-то место в памяти. Например, числовые переменные занимают довольно много места. После удаления лишних переменных программа начала загружаться нормально. Так что дело все же было в переменных.

  8. mbyte, честно говоря это уходит за пределы моего понимания. Вообщем-то известный факт, что введение дополнительных переменных (скажем для сохранения промежуточных вычислений) только увеличивает скорость программы. Я, честно говоря, даже представить боюсь сколько переменных нужно ввести, чтобы программа начала тормозить, потому как время затрачиваемое на операции с выделением памяти — сущие копейки по сравнению с операциями умножения деления и т.д.

Leave a Reply

« »