Naming Events, Variables, and functions

Development Programming & Scripting Blueprint
, ,
1

Been wondering I know in code c++ we name things using no spaces all in one word:
Ex: int hungerBar = 100;
But in blueprints naming is it alright to just name everything with underscores?
EX: Hunger_Bar = 100;

2

Hey there @WiseManDark! So “best practices” is one of those things that is a bit different for everyone. It won’t break anything to use the underscores in BP variable names, but considering in blueprints you can use spaces for variable names many users do. I generally maintain the same convention without space or underscores personally, but having the spaces helps readability when working with lots of blueprint variables.

3

Are there downsides since it’s allowed? Cuz if it’s allowed and has no major downsides, I might just keep naming things with spaces for BP.

4

probably not in BP but i would say there is no advantage either. I think PascalCase is clear enough

5

Blueprint can really exacerbate naming issues because of how it inserts spaces or replaces ‘_’ with them.

Here’s two variables declared in C++:
image

And this is how they show up in the Blueprint’s variable list:
image

The show the exact name in the details panel though:
image
image

And now I can actually add a variable from blueprint with an actual space in the name!
image
image

And if I make a variable without a space from blueprint, the display name isn’t changed the same way variables from C++ are!
image
image

The only real downside is that because spaces aren’t allowed in C++ names, it’s easy/possible to duplicate a variable name from C++ by including a space and Blueprint will happily let you do that. If you always do PascalCase, Blueprint will be able to prevent you from creating a blueprint variable with the same name as C++ because they will be the same.

6

When will this be useful though, and is it worth it for me to redo most of my existing vars for bp to remove the spaces?

7

i wouldnt go back and change everything, it risks breaking too much in BP but start building better habits for your next project

8

I’d agree with @Auran131, it’s not worth going back and changing anything that you already have. Just to change how you’re building things in the future. This is often why you see “bad” code in projects. Something was learned that was “better” but it wasn’t retroactively applied to existing code because it wasn’t worth the time or effort or consequences to change.