When building a new software that will store a directory of configuration files in /etc, should the directory be named software_name.d or just software_name?
I can't seem to find good style guides regarding this subject. Debian is the primary distribution I have in mind but more general style guides or guidelines are welcome.
'Official' guidance is preferred to personal opinions.
The typical use of a .d directory is to hold multiple config files (typically sharing a common file extension, such as *.conf) which are then merged or composed to produce a single logical configuration. This mechanism is typically equivalent to one where the multiple config files were concatenated to form a single config file.
Applications typically evolved to use .d directories in order to play nicer with Linux software packages (deb/rpm) and package managers. A .d directory is nicer towards the use of packages by distributions, since then packages can simply "drop" a standalone file into a directory (which is a natural operation, as packages manage/contain files), rather than having to edit a shared configuration file to add a stanza to plug in that particular package. (In earlier days of Linux distributions, you'll see packages doing exactly that, editing existing configuration files, through post-install and pre-uninstall scripts.)
The use of a configuration directory named /etc/software_name is more common when the application uses multiple configuration files for different purposes (and perhaps even using different file formats, such as JSON, ini files, etc.) In that case, you might want to use a directory to group all the configuration files for that same application, but if you're not expecting other packages (or system administrators) to want to extend the configuration by "dropping" new files into a directory, then you won't use a .d directory.
Some systems end up using both actually. For example, yum (the Red Hat package manager) has its own configuration file, but it also has a .d directory for its own repos (/etc/yum.repos.d.) I believe apt is also similar, so you could look at that one if you're on Debian. You can see that setup makes sense, since you might want to manage adding/removing repositories by "dropping" new files into a .d directory (either from packages you push, or through a configuration management system) without having to modify the existing one (which might be getting updates from the O.S. distribution itself.)
There is a lot of discussion over this topic. Nothing really definitive is apparent.
For "official" guidance on what is 'correct' I say the definitive source would be the Filesystem Hierarchy Standard at The Linux Foundation. Unfortunately I didn't find anything definitive with some basic searches. You may have luck with more diligent searching.
Failing the FHS, I would look to the community you are writing software for, try to find a general consensus on what they prefer, and decide if that meets your requirements. I think you are asking for guidance where none actually exists, because "recommended" is a pretty vague term in this case. "Recommended by whom? And for whom?"
.d directories, as summarised by Russ Allbery: Generally when you see that .d convention, it means "this is a directory
holding a bunch of configuration fragments which will be merged together
into configuration for some service."*
– Stephen Kitt
May 14 '19 at 21:12