Side note: it's funny how formerly closed-source projects always open up to have tons of spaghetti code and bad design planning.
I was curious after you said this, so I took a look at the 4coder source. It looks like very straightforward code. The files are clearly marked so you know exactly what they do, the APIs look simple and reasonable, and they have clearly marked folders containing all platform specific code. I'm not sure why you put this side note here, but it doesn't seem to hold water in this case. The code is definitely not spaghetti, and it looks like it was designed with quite a bit of forethought.
Edit: I would just like to add that I saw the author left several comments about the state of the code in the Readme that imply the code is very unstable. I think developers tend to be very critical of their own code, but when I took a cursory glance at the code from an outside perspective it seems much easier to follow then many other projects I've tried to take a look at. For example, for a quasi-open source project, ffmpeg is extraordinarily complex and hard to follow. So I definitely don't think OSS = super well designed code haha
To your second point: I think it's a matter of size for a project becoming spaghettified. ffmpeg is mature and massive, so it's no surprise it's jumbled at this point. For a project of 4coder's scale, I'd wager that being open source sooner would've benefitted its design.
But, it's in the past. I'm just glad the dev left the code in the community's hands before dropping it. A lot of devs don't even do that, and the project becomes history.
I dunno, I'm looking at their "4coder_base_types.h" header [0] and redefining basic types and builtin keywords for personal preference (yeah I know, static is overloaded) is a serious eyebrow raiser.
[0] https://github.com/Dion-Systems/4coder/blob/62fe17699a99f7d2...
The keywords bit isn't that common, though it could be related to some custom script (e.g. having the editor parsing the "function" keywords) or doc generator.
Finally, big libraries do this as well. Freetype is notorious for typedefing weird stuff like FTPos and all that. It's just one way to model the domain language in the code, and that's fine by me. If the big open source libraries can do it, what's wrong with a small one doing it too?
Assuming you're browsing in an IDE, and that the IDE understands your build system. Github for example doesn't detect that it's a typedef for static. There's also the fact that the keyword `internal` is overloaded, and not in a standard way. For example, does it mean that it's not exported (a la dllexport in msvc).
> In addition, i32 is not an ambiguous typedef. It's way clearer that this is a 32 bit integer than `int` is.
but that's not what the typedef is to, the typedef is to int32_t which is a standard type that is guaranteed to be 32 bits.
> If the big open source libraries can do it, what's wrong with a small one doing it too?
typedef'ing FT_POS is totally different - FT_POS is not redefining a basic type to be used all over the project, it's defining the types used to refer to coordinates. Freetype is also written in C, and is almost 30. You also better hope that when you're using these typedefs that any third party libraries (e.g. free type) also use the same aliases.
It's great that you would fail a code review in your company for that but it's not relevent.
> I DO NOT recommend learning from this codebase, especially not with an uncritical eye. It may be a useful reference for certain algorithms and architectural ideas, and it certainly contains some cautionary tails. But if you are a beginner, I encourage you to aim for more than emulating the style and structure of this codebase.
The editor seems cool regardless.