Verse Codex - naming conventions, program structure, code clarity

Development Programming & Scripting Verse
, ,
1

o/

Attempt at Style Guide for UEFN projects & Verse programs structure:

UEFN Verse Codex

Reasons

Inspired by UE style guide by Allar, my job experience with C++ in UE where style guides help with clarity of code/projects, and fact that Verse programs are getting big for me.
I see also in official materials some inconsistency and since Verse doesn’t yet provide one this might help us sharing code, speed up workflows, instil good practices. Mind also LSP is quite limited atm. Overall style guide might help with above problems.

This is open project, WIP. Feel free to add Your inputs/feedback please, thanks !

Codex Style KISS

As first draft trying to keep it KISS as much possible
It might need clarification little bit later, but I’d like to hammer core tenets first, then make verbose version (though prefer KISS).

Few things we are debating:

  1. <decides>
    Was considering Try, Is or _ prefixes. Question like naming convention is very explicit:
  • TryEndGame() good, though gets quite verbose with getters like:
  • TryGetCharacter() but imo fail able getters should be distinguished
  • IsAlmostEqual() question suggest failure
    For me those indicate possible failure well enough. Not all getters fail, so verbose TryGet separates them.
    Why Try ? failure is deeply tangled in Verse fabric, a core feature. It seems we are in a way eliminating need for try catch blocks known from other general languages.
    Why considered _ e.g. _EndGame() ? It’s short, removes need for different words adhering to one concept, well readable. Though we doubt most will like this syntax and most will stick to it. There’s also a risk of new language features needing it & beginners being confused with type macro special _ identifier

Also thinking if we even need those. With traditional exceptions system you don’t really know if function throws. Verse makes failure explicit with [] syntax and failure context obligation. Weak LSP and non LSP reading context, e.g. snippets might though skew my view on this topic. After some tries this proposed system seems tho working.

  1. statics
    That’s mostly preference and thing coming from cpp, UE. constexpr & const global values often defined at translation unit scope, avoids magic numbers, helps with quick iteration on hardcoded stuff.

  2. async functions
    Async imo is good. There was also voice from community pointing to Wait used in UE but dunno how I feel about this esp. with API examples like Await()

  3. Though not included my tendency is to group things by:
    OrderOfExecution > RelatedConcepts
    So e.g. BeginPlay() would be very high with following forthcoming functions in order at least roughly, then groups of related contexts.

  4. Sorry for brushing over UEFN assets, will sit to this soon.

Please share your thoughts, thanks !
UVG :heart:

6 Likes
2

Hello there!
It’s nice seeing the community developing a code style, thanks for the effort :slight_smile:

We’re almost ready to publish a Verse Code Style doc that provides some guidelines. It covers most of the topics in this Codex, like when to make a function <decides>, naming conventions, and more.
Soon :tm:

5 Likes
3

o/ great to hear official one is coming !
Definitely are looking forward to this. Due to evolving nature of API community will greatly benefit of ‘from the source’ guidelines. Hope program structure will be also covered as this is also crucial for readability.

Would also be really great, (altho understandable It might not), to cover unsupported exceptions. There are constructs in API atm which are forced upon “not working now” approach, which do play a small role in file composition, which community gets surprised about. Preferably some hint in evolving guide about those would imo help.

Thanks for reply :slight_smile: