Існує море інформації про те, як потрібно писати вихідний код програм. У цьому тексті ви знайдете кілька порад про те, як його видаляти.
Цей спосіб може здатися очевидним, але я вважаю що це не так, оскільки розробники використовують безліч інших способів зробити це. Ось як потрібно видаляти вихідний код:
Більшість розробників не люблять так робити. Вони вважають за краще залишати всюди шматочки старого коду, про всяк випадок - раптом знадобиться знову. Вони довго і наполегливо працювали над написанням цього коду. Вони налагодили його, і він працював. І тому розробники не хочуть просто взяти і викинути старий код.
Таким розробникам я скажу: "Use the source (control), Luke" [1]. Використання систем управління версіями (таких як CVS. Perforce. Або Subversion), означає, що вам ніколи не доведеться турбуватися про те, що одного разу зроблена робота може зникнути назавжди. Весь ваш старий код буде лежати в CVS, готовий до повторного використання на першу ж вимогу.
Якщо у вас немає системи управління версіями (.) Або у вас просто немає бажання копатися в старих ревізіях, то скопіюйте шматок вашого коду в окремий файл і збережіть його в окремому місці. Але не залишайте його там, де йому зовсім не місце - у вашому початковому тексті.
Якщо у вас є ділянка коду, який вам вже не потрібен, то існує одна вагома причина для того, щоб дійсно видалити його, замість того, щоб залишати в відключеному стані: щоб зменшити плутанину і невизначеність. Одними з найгірших ворогів розробника є плутанина або незрозумілі місця в його коді, оскільки вони будуть заважати, і знижувати ефективність подальшої роботи.
Відключений ділянку коду безпосередньо породжує невизначеність. У головах інших розробників він викликає питання:
- Чому раніше використовувався інший варіант коду?
- Чим нова реалізація краще?
- Чи повинні ми будемо знову повертатися до старого варіанту?
- У яких випадках це потрібно буде зробити?
// OldWayStepOne (fooey);
// OldWayStepTwo (gooey);
NewWay (fooey, gooey);
Майбутні розробники, подивившись на цей код, побачать, що колись використовувався старий варіант OldWay, також вони побачать, що тепер працює новий варіант NewWay, але вони не будуть знати, чому старий варіант OldWay залишений поруч:
- Можливо, новий варіант NewWay всього лише експеримент? Якщо так, то чим він кращий, ніж старий? Як і коли повинно бути прийнято остаточне рішення: залишати його чи повертатися до старого?
- Можливо, старий варіант краще, але разом з ним щось працює не так? Якщо так, то що саме не так? І причина цих незрозумілостей криється в самому коді OldWay, або в тому, як цей код викликається? Коли ці непонятки будуть усунені?
- Можливо, проект змінився, і старий варіант OldWay виконує непотрібну роботу?
Чи не краще зробити так ?:
// OldWay працював краще, але надто неефективно, і до тих пір, поки
// НЕ буде перероблений MumbleFrabbitz, ми будемо використовувати
// NewWay до етапу M4.
// OldWayStepOne (fooey);
// OldWayStepTwo (gooey);
NewWay (fooey, gooey);
Хто може сказати сьогодні, чи буде насправді перероблений MumbleFrabbitz до етапу M4? Може бути і не буде. Це нормально; хто знає, що день прийдешній нам готує? По крайней мере, цей варіант допоможе розробникам зрозуміти, чому старий код залишений поруч. Маючи на руках інформацію про те, чому внесені зміни, і чому старий код все ще залишений тут, розробники зможуть зрозуміти, коли вони зможуть остаточно перейти на новий варіант NewWay, або коли вони зможуть повернутися назад до більш успішному рішенню.
#if 0
OldWayStepOne (fooey);
.
OldWayStepTwenty (hooey);
#endif
Для мови Python:
if 0:
OldWayStepOne (fooey)
.
OldWayStepTwenty (hooey)
Забороняється відключати код директивами умовної компіляції, не пояснивши чому.
Якщо вам необхідно використовувати C препроцесор для видалення коду, то "#if 0" буде кращим варіантом, тому що він принаймні ясно показує, що цей код ніколи не повинен бути скомпільовано.
У компанії Lotus вихідні тексти для програми Notes містили багато фрагментів коду, відключеного за допомогою директиви "#ifdef LATER", виходячи з (коректного) припущення, що символ препроцесора "LATER" ніде не визначений. Цей варіант - дуже слабка форма документування; він показує, що код поки ще не готовий до компіляції, але буде готовий пізніше. Але коли? Серед розробників ходив жарт про те, що треба визначити символ "LATER" і подивитися, що з цього вийде!
При використанні будь-коли визначаються символів для видалення коду, ви залишаєте в головах розробників неясність: що ж цей символ означає. Можливо, це конфігурація коду, звана "LATER", і в такому випадку з цим варіантом доведеться рахуватися.
Скажімо, у вас є чудовий клас, який має купу методів. В один прекрасний день ви виявляєте, що якийсь окремий метод більше не викликається. Ви залишите його або видаліть?
В даному випадку немає простої відповіді на це питання, тому що це залежить від класу і від методу. Відповідь залежить від того, припускаєте ви, що цей метод може знадобитися знову в майбутньому. Грубий відповідь може бути такий: якщо цей клас є частиною фреймворка, то залиште його, якщо ж він частина програми, то видаліть його. (Я планую написати окрему статтю про відмінності між фреймворками і додатками).
// (Тут використовувався інший алгоритм, який використовував хешування
// і працював швидше, але він мав проблеми із синхронізацією. Якщо він
// вам потрібен, то він в ревізії 1.16 або раніше у файлі ThingMap.java в CVS.)
Просте угоду подібне до цього:
Ви також можете використовувати подібний підхід і для великих ділянок коду:
#if 0 // - Я думаю, що це не потрібно, якщо використовувати FooBar
OldWayStepOne (fooey);
.
OldWayStepTwenty (hooey);
#endif
При видаленні непотрібного коду велика ймовірність залишити примарні заглушки від попереднього варіанту. Намагайтеся якомога ретельніше приводити все в порядок. Наприклад, при видаленні виклику OldWay в наступному коді:
Дуже спокусливо залишити такий супутній код, тому що важко зрозуміти: чи потрібен він ще чи ні. Але якщо ви залишите цей порожній умовний блок, то якийсь інший супроводжуючий програміст одного разу наткнеться на цей код, подивиться на нього і зрозуміє, що тут щось не так. І йому доведеться досліджувати всі до кінця. І щоб зрозуміти призначення пустого умовного блоку, йому знадобиться набагато більше часу, ніж вам, щоб видалити його.
Дійте рішуче і видаляйте старий код. Ви не будете по ньому нудьгувати.
- Erroneously empty code paths. про помилки при програмуванні захисного коду.
- Fix error handling first. про те, як важливо, щоб ваш обробник помилок завжди працював найкращим чином.
- Мій блог. в якому обговорюються і інші схожі питання