While this example is obviously trivial, the strength of advice, especially when compared to similar facilities such as [[Python_syntax_and_semantics#Decorators|Python decorators]] and [[Java annotations]], lies in the fact that not only do the advised functions / methods not need notto be designed to accept advice, but also the advice themselves need not be designed to beginbe withusable as advice. The availability of [[eval|evaluation]] throughout the lifetime of a piece of code (cf. [[Multi-stage programming|code staging]]) in Lisp allows advice to be [[Inline expansion|inlined]] automatically into any other code in a variety of ways. Any piece of code can be advised to carry out any other computation before, after, around, or instead of its original definition.
===Concern=Readability====
Advice can havehas the potential to introduce confusion, as a piece of advice applied to a function is not apparent to a user who tracks down the function's source definition to learn about it. In thesesuch cases, advice acts almost like a [[COMEFROM]], a joke facility added to [[INTERCAL]] to spoof the [[Spaghetti code|spaghettification]] attendant to the extensive use of [[GOTO]]s. In practice, however, such issues rarely present themselves. [[Upstream (software development)|Upstream]] developers and maintainers of Lisp packages and modules never use advice, since there is no advantage to be gained by advising functions when their original source definitions can be freely redesignedrewritten to featureinclude the desired behaviourfeatures. Advice is only useful in that it enables [[Downstream (software development)|downstream]] users to subsequently arbitrarily modify default behaviour in a way that does not require propagation of such modifications into the core implementation's source definition. Additionally, Lisp systems providing advice facilities generally also provide introspection which return things like docstrings, type signatures, and when relevant, lexically applicable advice.
