Hi,
I’m currently looking into some of the open issues, and I did not find any developer guide.
Is there such a resource, which I just overlooked? If not, I have a few questions regarding the graphviz sources:
Regardig the c/c++ standard, it seems like c++11 is used if the compiler supports it, and there is no constraint for the c standard? So code should compile in every c / c++ standard?
There is a number of macros which, in my opinion should be constants / inline functions, like #define canread(f) ((f)->_cnt>0). Is this for historic reasons, or is there something I’m missing?
Are there any coding standards I should be aware of?
Quite coincident timing of your questions on several fronts…
I don’t think there’s much of a developer guide at present, but @magjac is in the process of writing one.
We recently had a discussion about the C and C++ standards in use. I proposed unconditionally using C++11 and C99, which would require a baseline compiler of GCC 4.6. However @Ellson let me know that one of our supported platforms is CentOS-6/RHEL-6 which only ships with GCC 4.4.7. It looks like we could move to C++11 when RHEL-6 becomes EOL in December 2020, but it will be difficult to do so beforehand.
Regarding macros vs inline functions, inline has some surprising – and unfortunately variable – semantics across early versions of GCC and/or the C standard. I agree, functions are generally preferable to macros, and if it’s possible to turn some macros into inline functions without breaking compatibility I’d be in favor of it.
In terms of coding standards, I generally try to match the formatting of the code surrounding the area I’m editing, but I’m not aware of any rigorous guidelines for the Graphviz code base.
I’ll bite, if we’re discussing coding standards, my 2c is that I’ve had great success at work with avoiding many style discussions on teams by using clang-formatter (like gofmt for C and C++) and a pre-merge check that everything’s formatted. Making formatting tool-enforced is really the only scalable way to get everyone’s format looking the same and consistent. clang-format is very mature and scalable – we use it on the Google Maps C++ codebase.
That said, I’m not much of a C coder, so I don’t think I should get much say in this
The C / C++ mixture might be complicated sometime, but I would understand the situation if a lot of code is inherited in C and the tendency is C++, which I would support.
I don’t think a rigorous coding standard is necessary, readability is important but that is more related to cyclomatic complexity than to how many spaces your indentation has.
WRT to supporting GCC 4.4.7 until Dec 2020 - by the time the code base gets refactored to C++ 11 / C99 and any meaningful changes get added its going to be close to end of year anyway - personally I would branch the CentOS-6 version now and move on…
(Or start a new feature branch for the “modern” version)
I’m not sure we have the resources to maintain multiple production branches (fixes would need to be back ported to the CentOS-6 branch). I was imagining starting the migration to C99/C++11 in December 2020, not finishing it then. I would like to do this in the long term for maintainability, but in the short term there are plenty of other pending user issues to address. Having said that, if you want to work on this before then I think we’d be very happy to have pre-prepared patches ready to merge in December
