Варто зазначити, що код читається часто, на різну "глибину". Цей код:
PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();
легко «скувати». Це 3 твердження. Спочатку ми придумали PowerManager
. Тоді ми придумуємо a WakeLock
. Тоді ми . Я це легко бачу, просто переглядаючи початок кожного рядка; прості призначення змінних дійсно легко розпізнати частково як "Тип varName = ..." і просто подумки переглядати "...". Аналогічно, останнє твердження, очевидно, не є формою завдання, але воно містить лише два імені, тому "головна суть" відразу видно. Часто це все, що мені потрібно було б знати, якби я просто намагався відповісти "що робить цей код?" на високому рівні.acquire
wakeLock
Якщо я переслідую тонку помилку, яку, на мою думку, є тут, то, очевидно, мені потрібно буде детальніше розібратися над цим, і я фактично запам'ятаю "..." с. Але окрема структура тверджень все ще допомагає мені робити це одне твердження за часом (особливо корисно, якщо мені потрібно заглибитись у реалізацію речей, що викликаються у кожному операторі; коли я повертаюся назад, я повністю зрозумів "одну одиницю" а потім можна перейти до наступного твердження).
((PowerManager)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
.acquire();
Зараз це все одне твердження. Структуру верхнього рівня не так просто прочитати; в оригінальній версії ОП, без перерв рядків і відступів для візуальної передачі будь-якої структури, мені довелося б порахувати дужки, щоб розшифрувати її на послідовність з 3 кроків. Якщо деякі виразки з декількох частин вкладаються один у одного, а не розташовуються як ланцюжок викликів методів, то це все одно може виглядати схожим на це, тому я повинен бути обережним, довіряючи цьому, не рахуючи дужок. І якщо я довіряю відступі і просто просуваюся вперед до останнього, як передбачуваного пункту всього цього, що .acquire()
мені скаже самостійно?
Хоча іноді це може бути те, що ти хочеш. Якщо я застосую ваше перетворення наполовину і написав:
WakeLock wakeLock =
((PowerManeger)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();
Тепер це доводиться до швидкої роботи: "дістань WakeLock
, тоді acquire
це". Навіть простіша, ніж перша версія. Одразу очевидно, що річ, яку набувають, - це WakeLock
. Якщо отримання - PowerManager
це лише детальна деталь, яка є несуттєвою для цього коду, але wakeLock
це важливо, тоді це може допомогти поховати PowerManager
речі, тому природно скуповувати над ним, якщо ви просто намагаєтесь швидко отримати ідея того, що робить цей код. І не називаючи це означає, що він використовується лише один раз, а іноді і так що важливо (якщо решта області дуже довга, мені доведеться прочитати все це, щоб сказати, чи вона коли-небудь використовується знову; хоча використання явних підсферів може бути іншим способом вирішити це, якщо ваша мова їх підтримує).
Що означає, що все залежить від контексту та того, що ви хочете спілкуватися. Як і при написанні прози природною мовою, завжди існує багато способів написати заданий фрагмент коду, який в основному є еквівалентним за змістом інформації. Як і при написанні прози природною мовою, як вибираєте між ними, як правило, не слід застосовувати механістичні правила типу "усунення будь-якої локальної змінної, яка виникає лише один раз". Швидше якви вирішите записати свій код, буде підкреслювати деякі речі, а де-акцентувати - інші. Ви повинні прагнути робити ці рішення свідомо (включаючи вибір, щоб часом писати менш читабельний код з технічних причин), виходячи з того, що ви насправді хочете підкреслити. Особливо подумайте про те, що послужить читачам, яким просто потрібно «отримати суть» вашого коду (на різних рівнях), оскільки це станеться набагато частіше, ніж дуже близьке читання за виразом «за виразом».