Synfig is an old project, with a lot of stuff from before C++ library standardization, even pre-C++11.
Many coding good practices were developed/adopted since then, but sadly this project didn’t follow those changes, for different reasons (fear of breaking what currently works, too few developers, large source code, support of old systems, etc.).
Many helpful people contributed to Synfig, but we don’t follow some code “rules”/“consistency” in our contributions along the time.
Some cases are simple and “irrelevant”, like coding style: what is the project “autodoc” style (via Doxygen): ///, //!, /**, etc?; or if we should place a space between if keyword and its following parenthesis; or if class private member names should be pre/appended with _.
Other situations are more problematic, made “by hand” (like for loops instead of a now standardized std::find()), being the code error prone or difficult to understand and, consequently, to maintain.
Not modernizing our code base can be a contributor-barrier too. It seems C/C++ are “not” the “dominant” programming language among new aspiring contributors. Many of them know better Python and other scripting languages, with many features that ease development, and without usage of modern C++ standard feels like a pain.
We also don’t have the habit of writing unit tests for old and new code. That would help to avoid/prevent regressions and to detect bugs we didn’t see by reviewing code or even in the already existent code (like this, that made me spent one entire day to realize what I was doing wrong on my code, but it was not my code fault).
In the end, C++11 is (still) our current version target. What about we do aim to use the potential of C++11?
I mean we should start to follow the C++ Core Guidelines.
It is maintained by Standard C++ Foundation and it states at least one reason for every recommendation they made in its Core Guidelines. They usually lists bad/good examples too.
My proposal is to create a new project in our repository and report issues related to the Guidelines and link them to this new project. Thus we will be able to triage our progress, prioritize our efforts and make this large source code more consistent and maintainable.
I know we are so few contributors to do it, but that’s exactly one of the reasons that makes me think about it. It could be an easy way to new people start to contributing to source code and know/understand/experience more slices of the software code. One example is the “rule” Enum.3: Prefer class enums over “plain” enums. The programmer would have to search for "\benum\b" in the source code (via git grep or IDE, perhaps) and make a (simple) analyzis if the rule applies or not to that case, checking maybe for the first time that code area (“hm… so that’s a code for exportation”). By the way, the \b I used in the search word represents word boundary for regular expressions.
So what do you guys think about it?
PS: I support we should use C++17: it is now the standard required by gtkmm4, libxml++ (4.0 and 5.0), libsigc++ (3.0). But maybe we can shift later than we adopt some C++11 good points and current good practices. It would even help us simplify (= remove?) our synfig::ValueBase, as c++17 introduces std::variant.
. Thought all here would be CS/CE. I’m actually studying electrical/electronics with a specialization in IC design (not yet determined if analog/digital but most likely it’ll be digital).
