ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

File Names : what should be avoided

<< < (3/6) > >>

TucknDar:
I've always preferred lowercase characters (a-z,0-9) with underscores as separators. Sometimes uppercase in beginning of words, but usually all lowercase. Don't know why, just a preference :)

Eóin:
I was always a CamelCase fan, but recently I'm being converted over to lower case with '_' separators as that is what C++ libraries tend to use. I guess I just go with the flow :P

Armando:
Thanks for your input!
 
1- UPPER CASE and lower case
 
@Eòwin and mouser: I understand that one should not assume that a program or OS is case sensitive or not. But, even if 2 file names can't be differentiated by their "case" in windows, would the case formatting be preserved from one FS to another? the link I provided tells an interesting file transfer story (vfat to ext2, and fat32 to HFS+, or something like that) about lower case words being converted into upper case (and also the contrary), but CamelCase being preserved.
 
In each case, when the file or directory name was mixed-case it survived without mangling. This led me to my next filesystem portability decision: from now on, I’m going to use InternalCapitalLetters to name files. I typically like lowercase with dashes because it’s easier to type, but I’ll do a little extra work to save myself these types of troubles in the future.
--- End quote ---

            Q: Anybody has something to add about upper case / lower case conversion during file transfer?
 



2- CamelCase, underscore and "searchability" or accessibility
 
You see, apart from the problem of portability and "durability", for me it's also a problem of data searchability and accessibility...
 
So I have to take into account my searching tools and needs if I'm going to rename my files...
 
 
For instance, if I convert this file name
 
 
Smith, A. P. The Intersubjective Meditator - A Critical Look at Ken Wiber's Integral Spirituality.doc
 
 
following these conventions (I've decided to keep using the hyphen for now, as it seems that it's only with ISO-9660 level 1 that it could cause problems) :
 
 
   -A-
 
   a) spaces are erased, CamelCase is used instead
   b) [,] = [_]
   c) [.] = [__]
   d) [']  = [_]
   e) [:]  or  [;] or [ - ] = [_-_]
   f) [-] =  [-] 
 
OR
 
   -B-
 
   a) spaces = [_]
   b) [,] = [__]
   c) [.] = [___]
   d) ['] =  [_]
   e) [:]  or [;]  =  [_-_]
   f) [-] = [-]
   g) and each word starts with an upper case
 
 
 
With -A-, I get something like:
 
Smith_A__P__TheIntersubjectiveMeditator_-_ACriticalLookAtKenWiber_sIntegralSpirituality.doc
 
 
If I then try to find Intersubjective Meditator :
 
- X1 won't be able to find the file (it doesn't look for patterns inside words)
- Copernic will show it
- Farr will show it
 
 
With -B-, I get something like:
 
 
Ar-Smith__A___P___The_Intersubjective_Meditator_-_A_Critical_Look_At_Ken_Wiber_s_Integral_Spirituality.doc
 
Trying to find Intersubjective Meditator :
 
- X1 will find it (treats punctuation marks and other special characters as spaces, except when the punctuation is used as part of a search term)
- Copernic will find it
- Farr will find it too
 
 
So, after this very small experiment, it definitely seems that using [_] to separate words (instead of using CamelCase) is the safest bet...
 
      Q2 : any comments ? :)

Renegade:
I'm generally very conservative with file naming, but I do have some folders that will only exist on my own disk like, "日本 시장조사 - blah blah - 2007-06-11" which make sense to humans.

Doesn't it strike anyone as completely insane that here the tail is really wagging the dog? I mean that we're serving the computer and not the other way around?

f0dder:
I use national chars (the Danish æøåÆØÅ), spaces, multiple periods, etc. Applications not supporting this really need to be updated, and their lazy authors should receive a good spanking. I used to think that case-sensitiveness was good in a filesystem (ie., what *U*X tends to do), but I've come to realize that it's really just lazyness from the developers - there's no good reason behind it, imho.

PS: the path limit on windows is 260 chars, not 255. And really it's 259 since the last byte is used for the NUL character. Afaik NT and NTFS itself can handle more than this, but the 260-limit is imposed by the win32 layer and just about every application you will find.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version