Skip to main content

Code Style Conventions

[WIP and thoughts]

As far as Jacy is VERY WIP, I won't describe serious conventions, thus it's gonna be here -- in ideas.

Namings

Okay, I respect Rust, but snake_case is not kind of what most of the people like I think, even not considering things like "Most people like..." do not matter, I can describe everything from my view.

To be (snake) or not to be

It does not matter that much to me. The only thing I won't accept is the usage of the so-called PascalCase for functions, variables, etc. except types, names. By the way, I need a style guide, thus things like naming rules must be described with MUSTs ๐Ÿ˜„.

Intro and common rules

List of all writing styles referenced in the convention:

  • camelCase - starts with a lowercase letter, each next word starts with uppercase.
  • PascalCase - starts with an uppercase letter, each next word starts with uppercase.
  • snake_case - each word starts with a lowercase letter, words separated with _.
  • SCREAMING_SNAKE_CASE - all letters in uppercase, words separated with _.

All other variations MUST NOT be used in code.

Further, in this text I will use "MUST" and "SHOULD", "MAY" (mostly for alternatives to things that "SHOULD BE..."), so that gonna be clean what is my view.

"Different code-styles MUST not be mixed" is the most important rule here, I think. It means, that if somewhere here is written that something "SHOULD BE ..." but "MIGHT BE ..." and you've chosen a described alternative -- use it everywhere in your code.

Variables and functions

Variables and functions SHOULD be named in camelCase: somethingSomewhere, myFunction, foo, barBazFuzz

Variables and functions MAY be named in snake_case: something_somewhere, my_function, foo, bar_baz_fuzz

If one of the styles is chosen it MUST be followed in the whole code.

Constants

Talking about constants, I mean constants declared with const. Actually let without mut is a constant, but let is under the rule above

const SHOULD BE named in SCREAMING_SNAKE_CASE: UNCHANGEABLE_VALUE

Scientific constants like PI number MUST BE named in SCREAMING_SNAKE_CASE: PI, G

const MAY BE named in camelCase: myImportantValue

Type names

Type names include names for:

  • struct
  • trait
  • enum
  • type
  • type parameters (read further)

All types MUST be in PascalCase: MyType, SomeStructure, EnumWithEverythingINeed

Exception is built-in primitive types: i8, i16, i32, int, i64, i128, u8, u16, u32, uint, u64, u128, isize, usize, f32, f64, double, bool, char, str

Nothing else CAN NOT BE named in PascalCase except user-defined types!

Type parameters

Type parameters are under the rule above ("Type names"), anyway, they are styled a little bit differently.

Type parameters MUST BE named in PascalCase: T, U, V and SHOULD BE 1 character long.

As you can see, 1 uppercase character is used for type parameters, but which to use when there's more than one or usage is specific? Here's the table of common cases:

CaseNames
Single "any" typeT
Key-value typesK for key and V for value. Often used in mapping structures
Multiple typesFirst - T, Second - S, Third - U, Fourth - V
Meaningful typesTSize, TInput, TOutput
A lot of "any" typesT0, T1, T2, ..., TN. Rarely needed, but can occur in, for example, tuple type implementations

"any" type implies cases when it is not important to refer to this type, and it just needed to be annotated.

Modules (mod)

mod MUST BE named in snake_case: std, my_lib, some_module

Resulting table of naming styles

EntityPreferred naming style
Type aliasesPascalCase
Type parametersSingle upper case letter T or meaningful PascalCase name rarely
Lifetimes1-8 letter long lowercase word, e.g. 'a or 'tree
Traits (trait)PascalCase
Enums and variants (enum and its members)PascalCase
Implementations (impl)PascalCase
Functions and methodscamelCase
Local variablescamelCase
Constant and static variablesSCREAMING_SNAKE_CASE
Modulessnake_case
Partiessnake_case
File nameskebab-case (preferred) or snake_case (alternative)

Only built-in primitive types can use snake_case