> 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
I'll admit, I didn't actually read the codebase. I just took the notes at face value. I agree. People are harsh in review of themselves.
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 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 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.
The types bit is incredibly common, i think pretty much all codebases i've worked on professionally did that.
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.
You can just hover over the keyword with an IDE and instantly see that it's just a typedef for static. There's nothing wrong with doing something like this, especially since it wasn't meant to be OSS and more of a personal project until now. In addition, i32 is not an ambiguous typedef. It's way clearer that this is a 32 bit integer than `int` is.
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?
> You can just hover over the keyword with an IDE and instantly see that it's just a typedef for static
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.
Internal define for static is actually really good, maybe different keyword like 'fn' would be better cause it doesn't clash with windows.h but, redefining static to a different keyword allows you to search for it in a codebase while static can be a local variable, global variable, function.
I fundamentally disagree. The reason programming languages work are because things are consistent, if everyone defined their own flavor of keywords then you're not using the same language anymore. On any project I've worked on I would fail a code review for attempting to introduce something like this.
He is consistent, all functions have that keyword, it's his codebase. He has also has the api(custom) define so his metaprogram knows which functions to publish into the plugin system. C++ syntax is not very regular so if you want to consistently catch all functions with a homemade parser or grep or whatever it would need to be complex, it needs to do backtracking, account for stuff like operator+ etc. If you do what he is doing it's trivial to make a metaprogram for C++ that would consistently catch all functions.
It's great that you would fail a code review in your company for that but it's not relevent.
The API custom define is perfectly fine. (Well it sucks but that's not his fault, that's a c++ language deficiency). But making custom defines for fundamental types and for language keywords because you'd rather type internal than static is just messy.
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