UE4 is massive and written by people all over the world, including sometimes from the public who submit pull requests. Because of this, the “coding standard” has context. Certain assumptions are made by the programmer, such as not checking in accessors or modifiers for valid objects before assigning or returning member variables, because they know the result of these pointers are always going to be valid, as that was the way it was designed. I would even argue that them not checking pointers as a way to crash the program if they happen to not be because again, it is assumed they are valid and if they aren’t, they want the program to halt so they can fix the issue.
As an example, lets say the SetCameraSpeedSetting function was written like:
void FLevelEditorViewportClient::SetCameraSpeedSetting(int32 SpeedSetting)
{
if(GetMutableDefault( ))
{
GetMutableDefault()->CameraSpeed = SpeedSetting;
}
}
The programmer might rather have crash happen instead of a silent failure of a condition. I suppose they could add some logging when the condition fails but then that gets difficult because it gets buried in a lot of other logging and overall, its much more logical to keep the assumption that the program will work as designed.
Furthermore, UE4 is tested internally by a good size team as well as by the public when they have preview builds; or those who update to “main” often. This means that bug reports and crashes are all logged and dealt with, reducing the final shipping code from having crashes from instances like what you have posted.
I recommend that when writing your code, write it in the way you think is best. No matter what you do, there is going to be code in UE4 that maybe doesn’t agree with your design structure. Take it for what it is and honestly, only worry about situations of what you would call “bad” code if they are preventing you from working on your project. If you come across any of these sorts of issues, such as crashes or asserts, submit a bug report. You can also commit pull requests if you have fixed any code that is causing issues.
As for how to write a function, I do not have a good answer for you. Write it in the way you think is best. If that causes issues in your design, refactor it to work better. There is no perfect example of how to write code, where it is the best way in all instances. Use what is logical and fits your needs. Do your best to prevent crashes and give context to the problem you are solving in how you write the code to solve it.
Lastly, I do not know what the SimpleConstructionScript is. The documentation is not complete through the engine in what each class does. Do you best to find examples of how it is used and spend the time to learn what it is doing.