Довжина функції


протягом своєї кар'єри я чув безліч аргументів про довжині функції. Більш глибокий питання — коли код потрібно виносити в окрему функцію? Іноді рекомендації засновані на розмірі, наприклад, функція має поміщатися на екрані. Інші засновані на повторному використанні — будь-код, що використовується більше одного разу, повинен бути винесений в окрему функцію. Але якщо код використовується лише один раз, то його можна залишити на місці. Мені здається, що великим значенням володіє аргумент про поділ наміри і реалізації. Якщо потрібно витратити час на пошуки фрагмента коду щоб зрозуміти, що він робить, то потрібно винести його у функцію і дати їй таке ім'я, яке відповідає на питання "що". Тоді наступного разу сенс функції відразу буде очевидним, і в більшості випадків вас не буде хвилювати те, як функція виконує свою роботу. Іншими словами — що відбувається в тілі функції.
Коли я став застосовувати такий принцип, я розвинув в собі звичку писати дуже маленькі функції — звичайно не більше кількох рядків. Будь-яка функція довше шести рядків вже пахне. Цілком звичайна справа для мене — мати функцію з одним рядком коду. Кент Бек показав мені коли-то приклад з оригінальної системи Smalltalk, і це допомогло мені по-справжньому зрозуміти, що розмір — це не важливо. Smalltalk в ті роки працював на чорно-білих машинах. Якщо потрібно було підсвітити текст або графіку, то доводилося реверсувати відео. Клас в Smalltalk, що відповідає за графіку, містив метод 'highlight', і в його реалізації була лише одна рядок — виклик методу 'reverse'. Назва методу було довше реалізації, але це не мало значення, тому що між наміром і реалізацією цього коду — велика відстань.
Деякі люди хвилюються з приводу коротких функцій, тому що їх турбує вплив викликів на продуктивність. Коли я був молодий, це іноді мало значення, але сьогодні це рідкість. Оптимізують компіляторів часто працюють краще з короткими функціями, тому що їх легше кешувати. Як зазвичай, в оптимізації продуктивності мають сенс у першу чергу рекомендації загального характеру. Іноді це правильне рішення повернути код з функції назад на колишнє місце. Але найчастіше наявність маленьких функцій дозволяє знайти інші способи оптимізації. Я пам'ятаю, коли люди були проти наявності методу isEmpty для списків. Стандартним способом було aList.length == 0. Але тут як раз той випадок, коли назва функції вказує на намір, і це може допомогти з продуктивністю якщо існує більш швидкий спосіб визначення порожнечі колекції, ніж перевіркою довжини.
Маленькі функції начебто цієї працюють тільки якщо назви досить гарні, так що потрібно приділяти увагу цьому. З часом ваш навик буде поліпшуватися, і такий підхід може сильно підвищувати само-документованість коду. Функції більш високого рівня можуть читатися як історія, і читач вибирає, які функції заглибитися якщо потрібно дізнатися подробиці.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.