I originally thought this is a kind of passive skill of the programmer profession, but I realized that many colleagues do not pay much attention to program-triggering events and execution order. In this article, I want to explain why we, as programmers, should pay attention to these things and what benefits it brings.
#When the program is triggered
If you accidentally download a virus from the internet, and it’s now saved on your local disk. Is it game over? Not yet. It hasn’t been executed. Just delete it (preferably using a file shredder tool). Our computers follow the Von Neumann architecture, in which programs and data are treated equally when they are stored in the hard drive (as well as in memory). The program on the hard drive has not been executed. I guess people working in cybersecurity are familiar with this. A successful attack inevitably involves the successful execution of malicious instructions.
You must have been scared by those prank Flash games ages ago, right? (No? Well, maybe this example is too old). If you close the game before the jump scare scene is triggered, you’re safe, nothing happens. The Flash game is already running in your browser (meaning all the game’s code is in memory), but that doesn’t mean the jump scare scene (a specific piece of code) will necessarily be triggered by your operations.
#Program-triggering events and execution order
The term ‘program-triggering event’ is something I coined myself, referring to “events that trigger the execution of instructions.” It’s a simple definition, but I couldn’t find a ready-made term that precisely fits this definition. Perhaps in the right context (such as in event-driven architecture), the term “event” alone embodies this meaning, and in the following text, we will use “event” instead of that term.
In graphical user interface applications, user actions are events; in servers, external requests are events; in scheduled execution systems, the system serves as the event triggering timed tasks. Different program entities can trigger each other in a chained manner. For example the famous interview question - What happens when you type google.com into your browser’s address bar and press Enter? Wow, it’s really quite a chain. From this perspective, a program residing in memory is somewhat like nervous system: it is alive (part of the persistently running logic actively listens for events), but it is in a standby state. An event will activate its corresponding processing logic (a portion associated with the event), and after the logic execution, it returns to the standby state.
Looking more abstractly, each node in a chain of calls is a part of the input–process–output model. Let’s take a closer look at the hierarchical execution within the same process, for instance, from the perspective of functions. You must be familiar with the Call Stack, which records the order of function calls, making it clear who called whom. This represents the function-level program execution sequence. The interview question mentioned earlier involves multiple levels of execution sequence.
#What are the benefits?
When programming and designing programs, one should always keep in mind the events and execution order of the program. Here are a few examples:
-
When given a new requirement, the first thing to think about should not be how to implement the requirement, but what event can trigger this new logic. No matter how fancy the implementation is, without an event to trigger it, it’s just a dead code sitting in memory.
-
If you need to add new logic within existing logic, where is the most appropriate place to insert the call to the new logic? Draw a data flow diagram and check the execution order. Call the new logic as soon as the required data (function parameters) are ready.
-
If the program doesn’t crash, but some fields in the output result are incorrect, what tool can leverage the information that “some output fields have incorrect values”? Data flow analysis can trace backward from the output logic of those error fields until it reaches the point where they are declared; the error lies somewhere in between.
-
If you want to write a cheat for a game, modifying the existing logic and data by altering the data received by the original logic, or canceling the invocation of the logic that should have been called, where is the ideal insertion point? Like a dam, your newly written code must be placed before the logic you want to modify, preferably right before the original logic, to avoid unintended consequences spreading to other parts you don’t want to modify. (The principle behind some Minecraft mods follows this approach, of course, they don’t do anything malicious, well, perhaps.)
Advertisement time!
minecraft-access is a mod designed to help visually impaired players play Minecraft. Currently, I am the only active developer, and there are quite a few new requirements and bugs. If you’re interested in understanding the logic behind Minecraft through mod development, this mod is undoubtedly your best choice. If you’re intrigued, we look forward to seeing you on the PR page and issue page.