If the functionality is longer than a few lines then don't implement it in system (built-in) events (Clicked, ItemChanged etc). Instead, create well-named functions and call them from those events.
Advantages of this approach:
1. The functions' names will tell us what the functionality is.
2. If a built-in event should perform more than one logical task then implementing each task in its own function will conform to the best coding practices. It's ok to call two or three function from a system event, but if the script grows and begins to have its own logic then... it becomes "implementing functionality" and, therefore, needs to be extracted into a function.
3. One day that functionality can need to be called from another place. Calling a well-named function is not only more elegant (you shouldn't call GUI events unless you're using call super from a descendant script) but also enables developers to add arguments - today the required functionality is identical, but sooner or later it can branch.
4. Someone will try to implement something in the ancestor ButtonClicked, thinking it's only going to fire when there's a button clicked. Then you'll end up with some spaghetti solution to keep track of whether this is a non-button-clicked ButtonClick... Ugly!
5. Different DataWindow objects (buttons, fields) require different processing in such events as Clicked and ItemChanged, so there is no reason to put their processing (not related to each other) in one script. In fact, these events are only traffic hubs for routing the program flow to different functions using choose case construction (the only exception is when the code is simply a few lines).