#22enforce variable casing rules with compiler warnings

~clover commented · 2 years ago
Author
Owner
think it should definetly exist.

doing this in sema would allow for different casing rules depending on the type of content (my opinion is of functions to follow camel casing, and variables follow snake casing, and types follow pascal)

but things to consider are libraries and apis. i think this can be best achieved with future layers that make case conversions for JSON and libraries easier, so that blight code can be consistant even if outside sources are not.

Milestone: 0.3.0.
~clover changed the status to Todo · 2 years ago
~clover commented · 2 years ago
Author
Owner
plan:

all identifiers without @ escaping syntax must adhere to

if used as a function name, only camel case

otherwise must be one of: camel, pascal, snake

variable names must not start or end with _

in assignments, use a new instruction (possible name: .check_casing_semantics), to add warnings when you do let foo = getSomething();, where foo is initialized to type, where the casing is wrong, but the fact it is wrong is not known until semantic analysis

using @ syntax opts out of the above checks. the purpose of an @ identifier is to say that the identifier has a has some reason to use a non-standard, such as @"Content-Type"

pub const Casing = enum { none, /// some_value snake, /// someValue camel, /// SomeValue pascal, pub fn detect(str: []const u8) Casing {} }; pub const Type = enum { pub fn expectedCasing(t: Type) Casing {} };