Avoid clones
Clones may look useful at first glance but they really aren't. You are shooting yourself in the foot if you use them in the most common ways because their limitations are very easily encountered.
The main problem with clones is control. You can create them and delete them. You can also give them unique values using variables/lists set to "for this sprite only". However, very common questions asked on the Scratch forums are how to have the clones do more... How can they interact with each other? How do you keep track of which one is which? How do you prevent exponential growth of clones due to them all sharing the same scripts?
If the solution requires storing data in variables and lists, suddenly you don't need clones. You can do everything in the original sprite and more and avoid using clones completely. It does require learning how to to enumerate over a list using a loop and a variable counter (to access each list item) but clones also require learning. I argue that clones are a harder subject to learn given that their behaviour is unclear and debugging is awkward:
- Clicking a script will not run it in the clone, only the original sprite.
- Reporters and variable monitors only display what is in the original sprite.
- Debugging often requires the insertion of blocks into existing scripts to make a visual or audible change.
- The clones do not save with the project and are deleted when the green flag is pressed. Compare this to a list where this doesn't happen and you can save the state by exporting/importing it to a separate text file. Lists can also be manually edited.
- Clones have a limit of 300. The list item limit is 200000. There is no clone counter or blocks to get this value.
- Running scripts in clones often involves loops perpetually running within the clone and broadcasts. Neither provide good control over script run order. A broadcast can only run once per frame which is one of the few practical ways to communicate with clones.
The following are justifications for using clones, if these do not apply, use lists and stamps for 99% of other cases:
- You want to display many sprite costumes simultaneously with the same quality as the original sprite, in vanilla Scratch. (note that TurboWarp has a high quality pen option so this issue doesn't apply to it)
- You want to display something that doesn't affect the pen layer, such as some buttons on top of an emulator project.
- You want to play sounds with full control over the volume and effects of each, and when to start or stop them.
- You want to run ask blocks with a way to close them individually with code (rather than require the user to interact with it to close it).