Une chose à noter est que le code est lu fréquemment, à différentes "profondeurs". Ce code:
PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();
est facile à "écrémer". C'est 3 déclarations. Nous commençons par un PowerManager
. Ensuite, nous arrivons avec un WakeLock
. Ensuite nous acquire
le wakeLock
. Je peux voir cela très facilement simplement en regardant le début de chaque ligne; Les affectations de variables simples sont vraiment faciles à reconnaître partiellement comme "Type varName = ..." et il suffit de parcourir mentalement le "...". De même, la dernière affirmation n’est évidemment pas la forme de la cession, mais elle n’implique que deux noms, l’essentiel est donc immédiatement apparent. Souvent, c'est tout ce dont j'avais besoin de savoir si j'essayais simplement de répondre "à quoi sert ce code?" à un niveau élevé.
Si je suis à la recherche d'un bogue subtil dont je pense qu'il est ici, il est évident que je devrai l'examiner plus en détail et que je me souviendrai en réalité des "..." Mais la structure de déclaration séparée m'aide toujours à faire cette déclaration à la fois (particulièrement utile si je dois approfondir la mise en œuvre des éléments appelés dans chaque déclaration; lorsque je reviens, j'ai bien compris «une unité» et peut ensuite passer à la déclaration suivante).
((PowerManager)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
.acquire();
Maintenant, tout est une déclaration. La structure de niveau supérieur n'est pas si facile à lire en écrivant; dans la version originale du PO, sans sauts de ligne ni indentation pour communiquer visuellement une structure, il aurait fallu compter les parenthèses pour le décoder en une séquence de 3 étapes. Si certaines expressions à plusieurs parties sont imbriquées les unes dans les autres plutôt que disposées en chaîne d'appels de méthode, elles risquent de ressembler à cela. Je dois donc faire attention à ne pas faire confiance à cela sans compter les parenthèses. Et si je me fie à l’indentation et que je passe à la dernière chose présumée de tout cela, que .acquire()
me dit-il en soi?
Parfois cependant, cela peut être ce que vous voulez. Si j'applique votre transformation à mi-chemin et écrit:
WakeLock wakeLock =
((PowerManeger)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();
Maintenant, cela communique en un rapide "obtenir un WakeLock
, puis acquire
il". Encore plus simple que la première version. Il est immédiatement évident que la chose acquise est un WakeLock
. Si obtenir un PowerManager
est juste un détail assez insignifiant par rapport à l’objet de ce code, mais wakeLock
c’est important, alors il pourrait être utile d’enterrer le PowerManager
contenu, il est donc naturel de le survoler si vous essayez juste d’obtenir rapidement idée de ce que ce code fait. Et ne pas le nommer communique qu'il n'est utilisé qu'une seule fois, et parfois c'est ce qui est important (si le reste de la portée est très longue, je devrais lire tout cela pour savoir si elle est utilisée à nouveau; bien que l'utilisation de sous-portées explicites puisse être un autre moyen de résoudre ce problème, si votre langage le permet
Ce qui montre que tout dépend du contexte et de ce que vous voulez communiquer. Comme pour l'écriture de prose en langage naturel, il existe toujours de nombreuses façons d'écrire un code donné qui sont fondamentalement équivalentes en termes de contenu d'information. Comme pour l'écriture de prose en langage naturel, vous ne devez généralement pas appliquer de règles mécanistes telles que "éliminer toute variable locale ne se produisant qu'une seule fois". Plutôt commentvous choisissez d'écrire votre code mettra l'accent sur certaines choses et de moins souligner d'autres. Vous devez vous efforcer de faire ces choix consciemment (y compris le choix d'écrire du code moins lisible pour des raisons techniques parfois), en fonction de ce que vous voulez réellement souligner. Pensez en particulier à ce qui sera utile aux lecteurs qui doivent juste "comprendre l'essentiel" de votre code (à différents niveaux), car cela se produira beaucoup plus souvent qu'une lecture très proche expression par expression.