You're Naming Booleans Wrong! Unreal Engine 5

[@Ben-rz9cf]

I would generally use "isDead" versus just "dead". You could easily pick it out as a boolean in a large list without the b, and "isOnFire" is inherently obvious as to what it means, versus "OnFire" could easily be describing an event for any time the gun is firing. The "is" is not redundant.

[@maxmustsleep]

That's why you write bOnFire Or actually I'd use bBurning or a gameplay tag nowadays

[@MarcusBuer]

"bOnFire" is by itself a bad name, "isBurning" is much more descriptive. Also I agree with Ben, the prefix "is" is better because it carries temporal meaning, which can be useful for some mechanics that require transient states (jumping, wetness, burning, as examples).

[@CyberWolf755]

Still preffer "isSprinting", "isDead", "hasPlacedObject"

[@CyberWolf755]

To clarify, some names, like "Dead" is not descriptive enough or just too short and there might be other features that use that word for let's say a faction or attribute.

[@KratonWolf]

Hey, good video, but I thought I'd point out something that can sometimes happen (it really depends on your game) that would actually have booleans used more preferably rather than enums. The thing that makes Enums great is that you can only be in one of it's states at a time (for instance, I use enums to denote what attack type a person is doing, and set my attack animation accordingly, as you can only do one kind of attack at a time, such as punching or kicking, in virtually all fighting games). But that can also sometimes be the drawback to Enums, IF you're actually NEEDING to be in both states at the same time. For instance, if you want the player to be able to do certain actions while jumping, like you jump and push a direction to sort of float in that direction (not very realistic but it's done in a LOT of games) mid-jump, you want to be able to be "running" and "jumping" at the same time. Your code wouldn't have your animations play the running animation while you're jumping, but you'd want any executed code to actually happen in that sort of case so you can be moving while jumping. Likewise, if it's a fighting game, maybe you want to be able to attack while jumping or attack while walking/running, and in that case an Enum would likewise not work (though you could use it for attack types, but keep movement bool based) because you'd want your movement code and attacking code to work together. Again, only 1 animation would be wanted to be played (perhaps an animation that is different from both walking and attacking, like a mixture of the two). But everything else depending on those states would need to function at the same time. Another thing I noticed is you mention how you don't ever want to have "redundant" naming conventions, specifically where the "Is" naming convention is concerned. I agree with that for the most part, but if someone is working with just C++ and not a nice visual system like Blueprints, you can't tell something is a Boolean or any other type of variable just by looking at it's name. Normally in C++, you have your variables instantiated somewhere, and never again do you see the variable type, because only one variable would have that variable name (or you'd notice immediate errors). In a case like that, you would actually want something tiny added to help denote what kind of variable it is you're looking at. Adding b is a good way for booleans if you don't have any other variable types that could possibly begin with b (with custom classes though, that's not necessarily the case, as you could feasibly have a reason to create a custom variable class designed to give you a bit more control over what kind of data that variable can store. For instance maybe you want a float that cannot be a negative value and so it would be a class that just stores a number that has been capped between 0 and 3.402823466E+38. Or maybe you want an integer that is only ever a number 0 or greater but able to store a value higher than a byte). BUT adding "Is" in front is a good short way to instantly tell anyone that it's a boolean without confusing anything else, without the risk of confusing it with other variable classes that may also start with "b". As someone who is primarily a cpp/C++ thinker when it comes to my game design, even using Unreal Engine 5 I still put "Is" in front of my bools, because I don't like to let my brain get lazy and have to rely on colours that, to be fair, someone else decided would be the way that it is. I don't see "red" and go "oh that's a bool". Someone at Epic decided that should be the way it is in their engine, but that doesn't work everywhere you go. If I let myself get that lazy, I'd have problems down the road if I ever use someone else's system (if I worked for a big game studio company, and had to use their in-house engine), I'd make MORE problems than it's worth by doing booleans any other way (especially if the game studio has their own way they do it, you really HAVE to work as a team and do it the same way, no matter how you feel about it).

[@nekronavt]

Next step - use Gameplay Tags for states instead.

[@zaxisup]

Very true!

[@Dontstopbelievingman]

Thank you. Have been looking all over for best practice advice.

[@maxmustsleep]

One of the bigger reasons why is, are, can, should and the likes shouldn't be part of bools is that they should be reserved for functions that return bools and need additional computation before returning a result as opposed to a state or status of sorts. You might want to check if a player is unconscious, out of stamina, swimming or in a cutscene before you activate something. You don't want to know a state you want to know a series of requirements to answer if something can or should happen Though of course gameplay tags and GAS might be preferable in many cases

[@benbynum3882]

Narrowing down variable and function names like this is great, because it makes you think about your design. i.e. If you can't narrow a name down more, maybe what it's doing would be better done in a different class

[@soulroll-nz]

Thanks for this, will be tidying up my project because of this, saw a few projects with the b prefix and didn't know why.

[@zaxisup]

Glad I could help! The b prefix is used a lot in projects and the documentation by Epic but is never explicitly explained.

[@Luillopanto25]

I use "Actor Tags" instead of Booleans actually. It is already built-in so I decided to use them.

[@stevengunnels9359]

Naming conventions and practices are neither right or wrong, and just because someone else does not use your chosen convention or practice does not mean they are naming Booleans (or any other data type, structure, or routine) wrong or incorrectly. Some conventions and practices may be "better" than others, but "better" is subjective, and whether one convention or practice is "better" than another may also be situational, case-dependent, or just a matter of preference. Naming conventions and practices serve to communicate purpose and eliminate ambiguity to avoid misunderstanding, misinterpretation, and misuse. The more clearly the purpose is communicated, the less likely the named item will be used incorrectly. Thus, as a general rule, the less ambiguous the name, the better. If you leave it open to interpretation, different people will interpret it differently, and inevitably, it will be misunderstood at some point or another. From your video, it is evident that you subscribe to the "terse naming" philosophy of the '70s & '80s. It is likely how you learned it because a lot of computer science literature and documentation that came out of the period has been passed down through the years and remains relevant today. There is nothing inherently wrong with this, but I suspect that you do not really know "why" such naming practices were agreed upon in the first place because you seem to focus on eliminating redundancy, which was not the primary goal of terse naming. The primary goal of terse naming was to maximize the amount of effective lines of code in a single text file because its size was constrained by a very limited amount of memory. Additionally, it seems you fail to realize just how much redundancy there actually was in the terse naming process because (in addition to the raw source code) the creation of extensive paper documentation was required just to be able to understand the code, and it was not uncommon to see two (or even three) different explanations set forth in the interest of clarification - depending on complexity. Furthermore, one might argue that what you are "teaching" about naming conventions and practices in your video is not only of poor form, but also irresponsible because what you are "teaching" and the way you are "teaching" it not only fails to eliminate ambiguity, but actually introduces additional ambiguity and therefore, increases the likelihood of mistakes. You claim that "bDead" (which displays as "Dead" in the graph) is a better name because it is 'less redundant' since "it's on the player" and "player is implied". An alternative argument is that "bIsPlayerDead" is a better name because it is identified as a Boolean by using the "b" prefix while it shows on the graph as "Is Player Dead" thereby making it more clear and less prone to misidentification than "bDead". Additionally, If you have multiple character types that could be dead, and you are switching between their different blueprints, it is easier to get mixed up about what is dead because while you were trying to eliminate redundancy, you have now required that the programmer slow down to confirm what "bDead" is referring to when "bIsPlayerDead", "bIsRabbitDead", and "bIsMonsterDead" is far less prone to being mistaken. Next, you exemplify "bHeld" and suggest it indicates "is the player holding something" or "is the object currently being held" but "bHeld" (or "Held" in the graph) is ambiguous because it does not tell us if it "IsCurrentlyHeld" or if it "CanBeHeld". Then, with "bOnFire", you attempt to eliminate some ambiguity by adding "On" instead of "just doing adjectives" you actually introduce a route of ambiguity by assuming that "OnFire" means "Burning" when it could just as easily mean the character is walking "OnFire". The problem is you are using "on" (which may be a preposition or an adverb) and "fire" (which may be noun or a verb) and this means there are at least four different possible interpretations. Thus, such an argument would suggest that "bIsCharacterBuring" and "bIsCharacterWalkingOnFire" would be "better" names because they are less subject to misunderstanding. Finally, I would suggest that using prefixes is a good practice (especially in written code such as C++), but with Blueprints, it is better practice to make your descriptive enough to identify what the variable type is and precisely what it is intended to mean. We no longer have to worry about running out of memory just because we use long descriptive names, and self-documenting naming practices eliminates (or at least reduces) the need for vast amounts of additional documentation.

[@DailyPaily]

Interesting, im already doing this.

[@georgevandiemen9835]

Informative video. But for me, "IsPlayerDead?" feels(!) better and more intuitive readable than the optimised "Dead". Grouping in a category doesn't help, too.

[@zaxisup]

It's definitely up to personal preference. While the simple adjective version may be the most optimal, it may not be the most practical for every team. The important thing is to pick a naming convention that works for you and your team at the start of the project and stick with it!

[@tuomaskarmakallio]

The QuestionMark is poor form, but otherwise I agree

[@maxmustsleep]

The big thing is that you should reserve verbs for functions, like CanAttack is a function that returns a bool that will internally check if the attack delay is done, you have enough bullets left and you're not in a cutscene

[@Mittzys]

This video is redundant in itself

[@dusteyezz784]

This video is plain wrong. Long variable names have long been accepted as superior. Redundancy is fine. What matters in the end is that when a different person looks at your code, the name gives them the information they need without ever looking into any code. Proper convention would be bIsSelfOnFire or bIsOnFire. That way when you read code it reads like a story. There is 0 thinking involved and 0 assuming. Unreal Engine documentation has their own section about naming conventions as well. On Fire doesn't answer who is on fire. Always assuming that the Player is on fire, as the class is the Player is not a good idea. You could be tracking the state of something within the Player Class and that would be the correct way to go in some cases. In that case you could end up in a scenario where another player is having a state tracked, particularly to avoid an RPC.

[@tuomaskarmakallio]

The "Is" explicitly implies the (b), so I would say the b prefix is redundant, unless you are writing c++ code and it's part of your teams convention. Otherwise I totally stand behing IsPlayerDead. 100% Clear!

[@dusteyezz784]

@@tuomaskarmakallio The b is part of epics naming convention, in actual use it gets removed automatically in blueprints, hence you should always name with a (b) in front.

[@Ravenok]

how about you keep making videos?

[@JinKee]

Oooh that explains why my variable comes up as "Uttfucked"

[@IRONFRIDGE]

Yes useful 👌🏼

[@jakedubs]

I name all my variables with funny names because if you spend hours inside the engine, you basically see the same sets of words "character, jump, attack, damage, collision, object, mesh". In order to improve speed and organization, I call them like; swordy, deathly, superattacker, jumpyjump, herocharacterman, etc. When you're working for hours your brain recognizes these words much more sharper. There's really no wrong way to do it.

[@SuperIcebeat]

Naming conventions make your code more readable and understandable by both you and other developers. When you follow a consistent naming convention, it's easier to quickly grasp the purpose and context of a variable without needing to read the entire code block.

[@Iobsterpeterson]

There certainly is a wrong way to do it. For instance, suffixing bools with a question mark.