Is it just me, or SFML is very well written

[nfect]

So  I learnt how to code with SFML, at the beginning it was hard to make sense of everything, but eventually I got it. After 2 years, the deeper I got into SFML, the more I read the source code, the more I realized how well it was written, elegant and clean. Some months ago I started using another library for an audio project (you may already know what library I'm talking about), and the deeper I get into it, the more awful I find it, it all "works", but it's definitely an awful piece of library, there's as many hurdles as there's after thought, it feels clunky, "fakely" user friendly, cramped and convoluted. There's a too many of everything acting as flexibility, while not enough of simple things that could make it really flexible (unless you  rewrite  yourself the source code). So I'm wondering, is it because I learnt coding with SFML that I find it hard to go deeper in another library, or is SML just as good as I feel it is?

[Nexus]

A lot of the clean code can be attributed to Laurent, the original author of SFML, who kept the philosophy of "simple" true over the years
When I joined the community over a decade ago, the C++ quality was definitely a factor for me, compared to more low-level C alternative libraries.

From all the programming languages I know, C++ has the widest variance of code quality in my opinion. Even PHP and JS have no chance here. A big part of the reason is the number of paradigms that C++ has enabled, and the big changes in usage over its lifetime.

It's not just that there is a lot of bad C++ code, but there is an almost creative variety of different ways how code can be bad.
We really have everything:

• C with classes, manual memory management and a big pointer mess (LZMA, most gamedev-related libraries)
• over-engineered template hell (several Boost libraries)
• Java in C++ (Ultimate++, many UI frameworks)
• macro hell (wxWidgets)
• antiquated design (standard iostreams)
• over-fashionable design (using template parameter packs and trailing return types just for the sake of modernity)
• wheel reinventors (almost every gamedev library w.r.t. standard containers, linear algebra libraries)

For a long time, truly well written libraries almost seemed like a niche, a gem, to find in C++. There are so many different styles to write C++, it's hard to objectively classify which code is clean. Obviously, the above list is my personal view, and other people might see this differently.

If I needed to summarize what makes libraries good, I would probably mention something along the lines of:

• It has a clear scope, keeps its promises but does not try to solve problems it is not made for.
• There's typically one way to solve a problem, and it's clear which one.
• There's an intuitive relation between types, functions and other symbols in the library, and the number of symbols in total is manageable.
• Abstraction level is high, I don't need to know anything the implementation in order to work with the library.
• Things are named appropriately. For many parts of the library, I don't even need to consult documentation. But if I do, documentation is always helpful.

[nfect]

I'm just amazed by the clarity. Is there a way I can get some information on how Laurent planned the whole thing, or if he kept rewriting almost from scratch once a "new thing" had to be implemented.

there is an almost creative variety of different ways how code can be bad.

I loved that line!

@Nexus do you think SFML is here to stay and will be maintained/upgraded over the years? Some people I talk to believe it's "old" or  "dated" while I can't stop praising it. I just hope it's here to stay, even though I don't have any project ongoing with sfml right now, I wouldn't like it to be gone.

@Samrich just ask, I'll answer asap.

[Nexus]

Is there a way I can get some information on how Laurent planned the whole thing

Let's see if he stumbles across this thread

But a lot of good API design comes down to experience in software engineering. You work with a lot of APIs and begin to see what works and what doesn't. Always try to see it from a user perspective -- a good process to ensure that is dogfooding.

@Nexus do you think SFML is here to stay and will be maintained/upgraded over the years? Some people I talk to believe it's "old" or  "dated" while I can't stop praising it.

It should stay, even if development has slowed down a bit. On one hand the library is in a state where a lot of things work and are stable, but there are still some larger things we'd like to do, see solution designs. I personally try to push the C++17 topic a bit, which should help modernize the library from a language perspective.

Still, we should acknowledge that it's not the 2000s anymore, where C and C++ were the only languages for game development, and writing your own engine was a must. For people who just want to create a small game, an engine (like Godot or Unity) and simpler language (like GDScript or C#) can be more productive. You're trading off control over the code base and need to adhere to the way how the engine does things, however. SFML is still very lightweight and highly optimized for 2D rendering, and you're free to use whatever architecture on top. Be it a classical OOP scene-graph, an ECS or something entirely different, SFML provides the building blocks and doesn't dictate how to use them. So it ultimately depends also on personal preference.

[Stauricus]

@Nexus do you think SFML is here to stay and will be maintained/upgraded over the years? Some people I talk to believe it's "old" or  "dated" while I can't stop praising it. I just hope it's here to stay, even though I don't have any project ongoing with sfml right now, I wouldn't like it to be gone.

personally I don't think it will be gone for atleast a decade, but probably more. I don't think there are plans for ending it, either.
the lib is very well structured and based on modern C++ standards, which is the reason i did choose it instead of SDL, for example. it also is built on top of OpenGL, so many updates from it will reflect on SFML.

and I have noticed an increase in beginner's topics lately. so many people are trying to learn programming, instead of just going for game engines. and in 2021, with Reddit and StackOverflow, Facebook and Discord, having an alive forum is a big deal 

[ErA]

The API/Code itself is pretty clean and easy to understand. But SFML is still C++03. I would have agreed with you on SFML being well written if you asked that question 10-15 years ago.

But the way you write modern C++ is very different. Especially C++ 11 had a major impact on how C++ code is written. I don't think i would call a library that doesn't make use of features like smart pointers, doesn't support move semantics and still uses workarounds like sf::NonCopyable instead of =delete in 2021 well written.

[nfect]

It's more than the code I'm talking about, the way it's written depends on it's "era", like an old house made of stones, I'm not really looking at the bricks but at the way they fit together. I mean I learnt almost everything I know about coding with sfml, and not just how to write an if or an else, but how it should flow, readability, and ergonomics/flexibility, which, let's be honest here, is something that is lacking in "today's" libraries.