C2 forum

General Category => Ideas => Topic started by: acbaile on September 22, 2018, 02:41:15 AM

Title: deleted
Post by: acbaile on September 22, 2018, 02:41:15 AM
deleted
Title: Re: Naming restrictions
Post by: bas 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).
Title: Re: Naming restrictions
Post by: magnusi 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.
Title: Re: Naming restrictions
Post by: lerno on November 10, 2018, 04:01:57 PM
Interestingly, if we enforce the type casing we can simplify analysis quite a bit:


Title: Re: Naming restrictions
Post by: bas 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?
Title: Re: Naming restrictions
Post by: lerno 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.