Is it considered a best practice to not use capital letters in file naming?

Question

People say you shouldn't use spaces in Unix file naming. Are there good reasons to not use capital letters in file names (i.e., File_Name.txt vs. file_name.txt)? Or is this just a matter of personal preference?

Answer 1

People say you shouldn't spaces in Unix file naming.

People say a lot of things. There are some tools that may screw up, but hopefully they are few in number at this point in time, since spaces are a virus proliferated by giant consumer proprietary OS corporations and now impossible to avoid.

Spaces make specifying filenames on the command line, etc., awkward. That's about it. The only categorically prohibited characters on *nix systems are NUL (don't worry, it's not on your keyboard, or anyone else's) and /, since that is the path separator.¹ Other than that anything goes. Individual path elements (file names) are limited to 255 bytes (a possible complication if you are using extended character sets) and complete paths to 4 KiB.

Or is this just a matter of personal preference

I would say it is. Most DE's seem to create a slew of capitalized directories in your $HOME (Downloads, Desktop, Documents -- the D is very popular), so there's nothing bizarre about it. There are also very commonplace traditional files with capitals in them, such as .Xclients and .Xauthority.

A value of capitalizing things at the beginning is that when listed lexicographically they'll come before lower case things -- at least, with many tools, and subject to locale.

I'm a fan of camel case (aka. camelCase) and use it with filenames, e.g., /home/goldilocks/blueSuedeShoes -- never mind what's in there. Definitely a matter of personal preference but it has yet to cause me grief.

Java class files tend to contain capitals by nature, because Java class names do. And of course, let's not forget NetworkManager, even if some of us would prefer to.

---

^{1. There is a much more delimited, recommended by POSIX "Portable Filename Character Set" that doesn't include the space -- but it does include upper case! POSIX also specifies the more general restriction regarding "the slash character and the null byte" elsewhere in the same document. This reflects, or is reflected in, long standing conventional practices.}

Answer 2

One reason to avoid caps in filenames is that sorting order in Unix is case sensitive, so files starting with a capital letter will appear out of order. That's the reason why Makefile is usually named using a capital M - it's one of the files you want to see first, without scrolling/skipping down trough a-l.

This said, you can do much worse in terms of file names:

• using spaces will break some badly-written programs and scripts which don't quote file names properly
• starting a file name with a - may cause problems as many programs will see it as a command-line option instead of a file name (e.g. rm -r will not remove a file named -r).
• starting a file name with a . will hide it from many utilities and shell globbing (e.g. rm * will not remove files like .config)
• using special characters like |<>*? and even non-printable characters like newline is technically possible, but may break scripts/programs similar to space character. The difference is that the space character is often used, so programmers tend to test their programs against it, while less popular characters often remain untested.

Answer 3

If you are going to interface with a Windows environment you should avoid capitals because Windows will lowercase everything. This is more often a problem going the other way; a link to Page_2.html will find page_2.html in Windows, but will fail in Unix.

Answer 4

Since NL_Derek opened this can of worms, but didn't articulate it properly, I'll say this:

It's OK to use capital letters, but you should avoid creating files (in the same directory) that differ only by case, e.g., File_Name.txt and file_name.txt, because

• If you somehow make the directory available to a Windows system, it will not be able to access both files.  It will probably be able to access only the one that appears first in the directory, regardless of which name you use.  (Except: it may give you access to them as FILENA~1.TXT and FILENA~2.TXT — type dir /x to see what short name (if any) goes with what long name.)
• If the file system is actually a Windows file system (e.g., mounted from an exFAT or NTFS file system from an NFS server running Windows), the two names will (probably) not be allowed to coexist.  For example, if you do cmd1 > foo and cmd2 > Foo, you may end up with a single file, containing the output from cmd2.
• Similarly, if you ever transfer the files to a Windows system, the two names will (probably) not be allowed to coexist.  For example, if you created an archive (e.g., zip) containing the two files, and extracted it on a Windows system, the second file would probably overwrite the first one.  Same thing if you transferred them to a Windows box with FTP or something similar.

Answer 5

One reason to avoid caps is that bashs tabcompletion is case-sensitive (at least by default)—this still trips me up every time I end up in front of a bash with default configuration. Sure, there are other popular shells, but this combined with the fact that bash is the default login shell on many OSes means that the default is oftentimes case-sensitive completion. Using all-lowercase filenames rather simplifies things here.

Answer 6

Apart from technical reasons, I have a practical aspect to this. Sticking to lowercase letters will ensure that searches are easier unless one is too fond of using grep -i or locate -i. Sometimes, even camelCase can be confusing if one has to use a string of like-case words as in storageNYCDCPrimary. So, I find it best to stick to lowercase and pepper them with underscores or hyphens for readability, like storage_nyc_dc_primary.

Answer 7

I do consider it is best practice to avoid using capitals and spaces in filenames.

Some will say they do not agree but it is a matter or what I call religious beliefs: hard to discuss and agree on. Those not agreeing say that most of the tools are now fixed to be capitals and spaces friendly: they are right but this is not the question though.

The right question is how much do you need to use capitals and spaces in filenames. To this question, except when I am programming in Java, the answer is mostly all the time: I do not need capitals and spaces in my filenames. All spaces I replace by an underscore (_) or a minus sign (-), and because of that I do not use camel case (aka. camelCase) contrary to some of the other religion.

Many people called bullshit on me for doing and teaching that - some of them still do - some of them tripped on a tool that was not capital/space friendly and came to me saying that I was right and that they should have listened to me. Do whatever you want, and if you use capitals and spaces in filename, I hope you will never trip on a badly written tool. However, if you trip on such tool, hopefully again, it will not be hard to fix and will not cost your business and/or you lot of money and/or time. But if it ends-up having bad repercussions, you will remember that some told you in the past that using capitals and spaces in filenames is bad practice.

And one last thing, if you want to avoid all problems, no special characters in filenames (only lower case letters, digits, underscore and minuses [1]). This unwanted character list also includes all non ascii characters (yes, French and other non English people - and I am one of them - none of those: à, â, ä, ç, é, ..., ö, æ, œ, ...). This also extends to many other things, including login and password. I will let you guess what happen when you put a quote or double quote (' or ") in a login or password that is handled by a bash script not written by a confirmed sysadmin....

[1]: maybe we could extend that to ~, @, # and some others, but this is looking for trouble (and yes I know about emacs files...).