волшебные значения delphi

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

Выдели код, нажми волшебную кнопку слева от редактора кода и получишь удобное средство переименования. Чудеса рефакторинга в современных IDE!

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

Имя должно быть осмысленное и без лишних пояснений должно быть понятно, что за ним скрывается.

Имя переменной должно содержать какой-либо префикс, который укажет нам на тип данных;

О переменных можно говорить очень много, но я кратко дам несколько основных правил, которых желательно придерживаться:

А что если переменная называется iFileLength? Вот тут уже легко понять, что это целочисленная переменная Integer или int (в зависимости от языка) и она содержит длину файла. Чтение такого кода и сопровождение значительно упрощается.

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

Многие из программистов абсолютно не обращают внимание на имена переменных. Когда порграмма состоит из 1000 строк кода, то понять о назначении переменной не сложно. Но когда исходный код исчисляется 5 тысячами строк и более, начинаются серьезные проблемы. Особенно через годик, после написания кода. Спросите программиста, что может храниться в переменной Temp, Str или param? Первое, что приходит в голову - там хранится отходы жизнидеятельности человека, которые мы сбрасываем в туалете.

К комментариям можно отнести отдно простое правило - они должны быть короткими и понятными. Если среда разработки поддерживает комментарии TODO, то не стесняйся использовать их, они реально помогают.

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

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

Важность рефакторинга подчеркивает и то, что во всех последних версиях сред разработки (Delphi 2005/2006, JBuilder 9 и выше, Visual Studio 2005) появились различные мастера и функции для улучшения кода. Эти функции не могут охватить все сферы рефакторинга, да и без знания основ их использовать проблематично.

То же самое касается и кода. Если он написан хорошо и легко читается, то его приятно сопровождать, добавлять новые функции или оптимизировать. Такой мод можно даже использовать в других проектах. Но если код написан ужасно, то намного приятнее написать все с нуля. Из-за плохого кода лет пять назад я забросил один из любимых своих проектов и переписал заного. Этот проект я начинал еще в 1996-м году и ниразу не задумывался о рефакторинге. Тогда даже понятия такого не знал (возможно, его и небыло). Получив серьезный ожег я теперь на всех этапах написания кода задумываюсь о его улучшении и при первом же появлении мусора улучшаю и очищаю код.

Ты хотя бы иногда убираешь на своем рабочем столе? Хоть иногда чистишь компьютер от мусора и от не используемых программ? Ну и наконец, убираешь в квартире, чтобы не ходить по мусору? Последний пример может быть и не очень хороший, потому что убираться в квартире большинство из нас не любит (сбрасывая это занятие на маму/жену/подругу), но ходить по мусору и жить в бардаке уж точно не приятно.

Что можно улучшать в коде, который и так уже работает и выполняет возложенные на него функции? Если программу не планируется улучшать и добавлять новые возможности, то можно больше уже ничего не улучшать. Лучше даже удалить исходники, дабы не тытаться разбираться в бардаке или использовать его в будущем. Но если программа нужна не один день, то рефакторинг необходим.

Для чего нужен рефакторинг

Рефакторинг программного кода - необходимость или мода?

Загрузка. Пожалуйста, подождите...

Рефакторинг программного кода - необходимость или мода? » DelphiComponent.ru | Delphi, компоненты Delphi, исходники Delphi