Coding Style Guidelines for UE4 Source Code


I looked into the source code and it feels that there are a few different coding styles used.
I would suggest that you make a coding style guide. As soon as there is a guide, I would help modifing the code to match this guide.
This would make it a bit easier to read the code and make the code more beautiful.

Kind Regards

That’s useful. But if you had searched for it, you would have found it already :wink:
Epic has a powerful search engine (not integrated into the forums!) it allows you to search within Wiki, Doc, Answerbase etc with one single try.
If you search for ‘coding standard’ you’ll find this: Coding Standard | Unreal Engine Documentation

Well, It seems that this was sometimes not used for the code. And there is many stuff missing from it.
There is no consistent code style like how should function calls/definitions be formatted.

void SomeFunction( bool bSomeBool );
void SomeFunction(bool bSomeBool);

Or in the guide there is ++whatEver used but in the code there is ++whatEver and whatEver++ used this makes the code not that beautiful.
You just have to look in LandscapeRender.cpp
And the guide should be on GitHub too.
As an example for a good guide Blink Coding Style Guidelines - The Chromium Projects

I would not fix the whole code base, this will just result in ugly history changes that are only aesthetic, and you should follow Epics guide instead of proposing a different one. Many Unreal developer which come from previous versions (UE3, 2, …) adhere already to it.

This was only an example of what stuff should be in a guide, because for me the Unreal Guide seems incomplete.
I only want that they make a complete guide with examples for cases how the code should look.

Start a wiki page based on Epic’s coding standard.
Couldn’t hurt :slight_smile:

I agree, there are a lot of inconsistencies in the coding style. That being said, it is not easy to maintain a fully consistent style with a couple hundred programmers over the course of nearly 20 years. We usually don’t make big cleanup passes to conform the entire code base, but fix things up as we go, i.e. if we change some function implementation or class declaration we clean up some of the surrounding code. While this takes a lot longer to get the desired result, it also helps us maintain comprehensibility of changes over time, which is quite important, because we frequently merge code branches and also have to go back in history to track down certain changes.