I’ve noticed a lot of code examples (and maybe UE4 itself) tend to use a class modifier in function parameters, which initially confused me to no end. Looking it up, I came to find out this is a way of forward declaring a class, but that it’s considered poor coding style. I’d have to agree with what I found, because in the 12 years I’ve studied C++, I had never encountered such an odd method of class forwarding up until finding it in UE4 tutorials.
I would suggest changing the tutorials and examples at the very least, to forward declare classes on their own, not in function parameters.
I myself used to always forward declare classes at the top of the file before I used UE4. The code style is definitely weirder than what I’m used to :). Capitalized variable names? b in front of bools but not other types (I think this is polish notation or something)? Madness… I got kind of used to it though. I think it’s been like this since the very beginning and epic probably won’t change their style any time soon.
It’s weird at my day job though when I forget I don’t need to capitalize my variable names and people comment on my code reviews to fix it.
Although I also don’t appreciate the variables start with upper case - and I doubt many ppl will change their style for it -, the main 2 things that I don’t like are:
They add A (speaking about actors) in front of the class names, but then the class file names don’t have it
When you create a class, they enforce this on you too.
But I really doubt any of their coding style will change tbh.
As noted duly by other moderators (I think even the staffs mentioned it) that UE C++ code is almost 20 years old and going. The Hungarian notation was inherited from the days of Win32 programming. Forward declaration is probably a side effect of maintaining archaic code written in 1998.
EDIT:
Unless UE4 is written from scratch in 2003, then all of what I said is basically irrelevant…
UE4 is definitly based from UE3, Cascade and Matinee looks the same as in UE3, Material Editor and Sound Cue regardless of new fancy graph UI it’s also same thing practically, so i would not be suppriced if UE4 and past engine all been build on UE1 fundamentals, the way game framework works didn’t change since UE1 (one of reasons why i know UE3 and UE4 so much is i was playing with UE1 a hell lot), UnrealScript runtime is still used for Blueprint and “b” prefix on bools also existed in UE1, so… ;p
The proposed change would not add any functionality improvement or feature to the engine and would only provide an aesthetic change. As long as the forward declaration is done properly it can be included at the top of the file or elsewhere. When following the tutorials and examples it is still possible to keep coding practices you’re comfortable with.
@CMeurin
That (their style of naming) has actually positive aspects too if you think about it.
You stick to your style of programming - nobody enforces you to code in their style. What will happen then? You will be able to recognize at first sight your code from theirs.
Their style is old fashioned in places and silly in others but they will not change it. It is just too much of it.
You just stick to your style and don’t be bothered by theirs “in house” style.
Coding style is often a contentious point, and some engineers (including, to be honest, me) get irrationally attached to a particular coding style.
One thing that I’ve really appreciated about Epic’s code is that it’s very consistent. The engine code is the cleanest very large code base I’ve worked with. That’s due largely to the caliber of Epic’s engineers, but it’s also due to the fact that they have held to a consistent coding style over the years. I value that code consistency and quality a whole lot more than the minor differences between the Epic coding standard and my own personal style preferences.