Author Topic: Naming restrictions  (Read 47 times)

acbaile

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Naming restrictions
« on: September 22, 2018, 02:41:15 AM »
Is it good idea to restrict case of first letter depending on the type?

For me, for example, it will be only irritation. I prefer everything in small.

Maybe, it's better to realize it like option in compile-time checking? Without necessity.

bas

  • Full Member
  • ***
  • Posts: 177
    • View Profile
Re: Naming restrictions
« Reply #1 on: September 24, 2018, 12:22:29 PM »
I can easily image developers initially being irritated by something like this. It takes away some
of the freedom. However all C2 code then becomes a lot more similar and thus more readable. This is
a huge advantage. For the same reasion the Go language formats all libraries with the same required
style. Initially developers hate it, but in the end, code is So much more readable (and reusable).

magnusi

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: Naming restrictions
« Reply #2 on: November 09, 2018, 11:25:48 PM »
I would much prefer it being a warning rather than a hard error (for reasons of FFI), but I agree with Bas that clear style is extremely beneficial, especially if you look at how horrible C look, where people use all sorts of indentation styles, naming schemes (especially juicy is some peoples' tendency to append _t to their types, which is a suffix belonging to POSIX only) and casing, which can result in a plenty of inconsistencies.

lerno

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: Naming restrictions
« Reply #3 on: November 10, 2018, 04:01:57 PM »
Interestingly, if we enforce the type casing we can simplify analysis quite a bit:

  • Types are the built in ones (as keywords) + anything starting with uppercase.
  • Identifiers are anything starting with lowercase (i.e. variables, function names)
  • Initial underscores are allowed and skipped when determining against these rules (so __Foo is a type, __foo is a
    an identifier)
  • Reserve anything starting with a single _ for user use (so allowed), double __ is reserved for internal use, so is disallowed. Same rules inside of indentifiers/types: Foo_bar is allowed, Foo__bar is not allowed.
  • Reserve __x_, __X_ prefix to bypass name rules externally. So __x_Foo would match an external symbol "Foo" assumed to be a function/variable. __X_foo would match an external symbol "foo" assumed to be a type. An exported function __x_Foo would be exported externally as Foo to C/C++.


bas

  • Full Member
  • ***
  • Posts: 177
    • View Profile
Re: Naming restrictions
« Reply #4 on: November 13, 2018, 08:54:39 AM »
Interestingly, we don't use the casing during parsing/analysis, we only check if it's correct.
Since C2 hasn't (yet) solved the issue of (C-code)
Code: [Select]
const int* const
The analyser doesn't see pointer variables as constant. When should a variable be a constant:
if it points to a constant or if it is a constant pointer to a (dynamic) variable?

acbaile

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: Naming restrictions
« Reply #5 on: November 13, 2018, 06:18:29 PM »
When should a variable be a constant:
if it points to a constant or if it is a constant pointer to a (dynamic) variable?

It seems, any combination of "const" is possible: constant can be data, that pointer points to, and constant can be variable-pointer itself.

lerno

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: Naming restrictions
« Reply #6 on: November 13, 2018, 08:41:33 PM »
So what about it, should we use it during parsing? That way we can skip some steps during analysis.