Iconic Gaming's Coding Conventions

[iGottic]

Hey folks,

Recently I had put together some coding conventions for Iconic Gaming to ensure consistent, readable, and scalable code. This is an iteration upon our unclear legacy guidelines.

You can find the conventions here: https://github.com/iG-Studios/iconic-lib/blob/main/Guidelines/conventions.md

On that page you can find:

• Guides for styling, juxtaposition, functionality, declaration, and more
• Clear, concise examples to demonstrate points
• Tips and rationale to clarify examples

Chapters:

• Juxtaposition
• Indentation
• Documentation
• Variable and Function Styling
• Variable Naming
• Function Naming
• Userdata Declaration
• Prototype Functionality
• Misc Styling
• Typing
• OOP Format
• File Organization
• Modularization

That’s all, if you have questions feel free to ask below!

[noblemaxx (monkeybaby)]

This is a really great resource! I was wondering if you have any opinions on organizing module scripts (when to separate classes/functions into different scripts, etc)? And also, how many variables do you split your code into ( working with CFrames, stuff usually gets ugly with many odd named variables)

[iGottic]

@noblemaxx

This is a really great resource!

Thank you!

@noblemaxx

I was wondering if you have any opinions on organizing module scripts (when to separate classes/functions into different scripts, etc)? And also, how many variables do you split your code into ( working with CFrames, stuff usually gets ugly with many odd named variables)

Good question. To clarify, I included this as an update to the conventions. Here is what was added:

File Organization

Here is the file structure we use at Iconic Gaming:

• ReplicatedFirst
  • ./Client
    • All client scripts
  • ./Dependencies
    • All client modules
  • ./Assets
    • All client assets
• ServerScriptService
  • ./Server
    • All server scripts
  • ./Dependencies
    • All server modules
• ReplicatedStorage
  • ./Common
    • All shared modules
  • ./Assets
    • All shared assets
• ServerStorage
  • ./Assets
    • All server assets

Modularization

Modularization is important to make sure that functionality is divided into isolated scopes, either through functions or modules.

Functions should be reserved for splitting functionality that is part of a larger picture in a script or module. For example, a weapon might have functions to shoot, reload, etc.

Modules are used to separate bigger things to create libraries, databases, and systems. Some examples of things that are their own modules include:

• Configurations
• Utilities
• Systems
• Frameworks
• Classes
• Etc

Variable modularization is the smallest level of splitting up information into something more digestible. This is something you should eyeball, with the general rule of thumb being "if it’s readable, it’s good. Make sure to utilize variables still for repeated information.

[thebrickplanetboy (zBrick20)]

What about private members for OOP? Do I still need to rely on _camelCase?

[iGottic]

At Iconic Gaming we do not do that.