Subject: Re: [boost] [guideline] 31 character filenames?
From: Christian Matuszewski (c.matuszewski_at_[hidden])
Date: 2012-03-30 09:03:33
Eric Niebler <eric <at> boostpro.com> writes:
> Our current guidelines say filenames should not exceed 31 characters.
> This was recently brought to my attention by a bug from someone who
> actually cares because he uses the ODS-2 filesystem on OpenVMS. On a
> lark, I hacked the inspect tool to check for too-long filenames and lo!
> found a bazillion. Most (but not all) violations are from doc files
> auto-generated by doxygen and docbook, but which nevertheless go out
> with the boost distribution and so should conform. (Right?)
> So, should we care? Considering that we have little control(?) over how
> doxygen and docbook generate their files? I have fixed the bug in
> question, but it feels like a token effort. Should we just drop support
> for niche filesystems like ODS-2, and close all future bugs "won't fix"?
>  http://www.boost.org/development/requirements.html
>  https://svn.boost.org/trac/boost/ticket/6196
I'm the one who filed the bug. I agree that ODS-2 is a niche filesystem also
because it already has the successor ODS-5. ODS-5 supports longer filenames.
Sadly, changeover to ODS-5 is still on the todo-list in our company.
Anyway, here are my arguments for limiting the filename length to 39 (or less)
1. The file for the bug in question was the only header file in the huge boost
project which was longer than 39 characters. It is now shortened, so all header
files are OK for ODS-2. So there is only an effort in checking new or changed
files to obey the rules. (I didn't check other files than header files).
2. There are still many people who like there source code lines to be shorter
than 80 characters. Longer filenames will lead to longer include directives.
It would be no problem for me if the documentation files would be too long.
Working with a niche OS, I'm already happy if a third party software compiles
out of the box.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk