Should I avoid using spaces in my filenames?

Question

I sometimes find experienced programmers who will actively avoid using spaces in their filenames, opting to use underscores or camelCase instead.

(i.e. /org map/attach jobs.cpp vs /org_map/attach_jobs.cpp vs /orgMap/attachJobs.cpp)

From what I understand, this was originally done on older systems which had more strict restrictions on filenames. But modern computers don't seem to have any issues with spaces.

Why do some developers avoid using spaces in filenames? Is this a design practice I should consider for my own projects?

Answer 1

Spaces in filenames aren't any problem, except when they are. The problem is that most parts of the compilation toolchain are scripted, often with multiple levels of scripting languages and variable expansion piled on top of each other.

The most important example is a shell script as part of a Makefile, which is perhaps generated by an M4 template (autotools…), which may run shell scripts itself to determine paths. It is possible but quite painful to handle spaces correctly in POSIX shell in nearly all circumstances: instead of foo $bar $baz you'd write foo "$bar" "$baz". It is not generally possible to do so in Makefiles. It is extremely cumbersome to handle space escaping correctly over multiple levels of scripting languages.

So if there is any chance that your program is supposed to be compiled by a Makefile-based build system, don't use spaces in your filenames. This should be easy to do since the filename should indicate the file contents, and in most programming languages identifiers can't contain spaces either. In C++, just name the file after the namespace or the most important class it contains.

Answer 2

Each space on the *nix systems have to be quoted. That means when you want to run to vi /tmp/my file.cpp you have to add the \ for masking the space, therefore command looks like vi /tmp/my\ file.cpp.

On the Windows machines it is not such a pain, as when using cmd or powershell console it automatucally masks the space in the filename (when using auto-completion in command line).

Personally, I do not use spaces in my filenames in any project and do not really recommend that.

Some build systems/programs are most likely to be running on *nix systems (Jenkins, make) can have trouble when you upload a file with the space inside the name - therefore, build fails.

Answer 3

As soon as there is any scripting involved, the developer needs to make 100% sure that their scripts handle file names including spaces, or other characters that would be relevant to a script.

Having file names with spaces may break scripts. Only scripts that where already broken, obviously, but still it will cost you time to get it right. Some people have had bad experiences with broken scripts, and therefore avoid the things making them fail.

On the other hand, if you create things like an installer, that will be running in a user's environment, you better consider that "/ / / / / /" is a perfectly fine path for a directory, and make sure your script handles it.

Answer 4

How about the opposite question? Some argue that spaces in filenames are good because they look nice. Do they? Most of the time, you cannot tell if that's a single space, a tab, or a couple of spaces. Actually, there is a suite of unprintable characters which might be used in filenames. Nowadays, most systems support UTF-8, so it is possible to compose formally strange names which look familiar, for example using the Greek letter "Α", which looks like "A", but won't be found by tools looking for the latter.

The fact that something is available, doesn't mean it is a good idea to use it. It depends what one is after. If the purpose is to generate confusion, using those funny filenames will accomplish it.

By the way, MS-DOS allowed spaces in filenames, while modern URI don't.