Comment by hardwaresofton
4 years ago
I am also that age, and kebab-case is the best case for filenames.
2021-01-01-some-important-document.pdf gives me the warm fuzzies. On the off chance that some more differentiation is needed, throw in an underscore and a whole new world opens up
I go one step further: 2021-11-11_client_project-name.ext
2021-11-11_client_projectName.ext is also OK. But underscore separates fields, hyphens for space replacement.
I see and applaud your use of the underscore there, but I must reject the premise!
work/client/project/2021-11-11-file.ext is more or less how I lay stuff out. I’d say client/project is a folder level distinction (arguably dates too).
[EDIT] Realistically most of the stuff under <project> is git repos and I usually make a “home” repo where I keep org files for tracking hours, notes, and resources related to the engagement.
I'll be the opposite voice: the file system isn't for precise organisation, it's just for storing. For organisation, the ideal thing to use is tags. Since most file systems don't have tags and using software for that would be a pain, the best way to do this is to list the tags in the file name.
1 reply →
work/client/project/2021-11-11-file.ext is great until you've got a '2021-11-11-project-status.txt' in a few directories and you need to find one quickly! I do a combination: clients/client/project/2021-11-11-client-project-update.txt
5 replies →
> But underscore separates fields, hyphens for space replacement
But why not the other way, hyphen-minus for separating fields and underscore for space replacement? That seems to me more consistent with how underscores and dashes are used.
I fully agree, that's how I do it :)
my_project-some_activity-this_document-20210923-v02.txt
Maybe you mean `2021-11-11_client_project-name_v2_final.ext`
2021-11-11_client_project-name_v2_final_ridaj(1).ext
1 reply →
this is the way
but the extra Shifts, no thank you
2 replies →
I've recently shifted sharply toward the dash from the underscore. I find it more readable, and it doesn't require the shift key. However, I do find it useful to use underscores to create groups, e.g. test-001_2021-10-11.log. Including hours, minutes, seconds is still awkward.
There's a customer for everything. I've just never liked the aesthetics of the underscore. Also if your underscored thing gets put in some document and then underlined the underscores can become invisible.
A lot of this is personal aesthetics, for sure. Personally, I am not a big fan of camel casing. In code, I only use it for class names, generally. I don't find it particularly readable, and for filenames, not all filesystems are case sensitive, so best not to rely on case to differentiate files. Camel case does have the nice property of being more compact, as no character is required. That's its main benefit.
R traditionally uses the . as a legal character in identifiers. Once you get it used to not being syntactic, I found I actually prefer them to underscores.
Brother in arms. I just posted similar thing below.
Burn the witch!
> kebab-case
I hadn't heard that before and I love it.
If you hadn't heard kebob-case called that before there's a chance you haven't heard SCREAMING_SNAKE_CASE called that before, and I couldn't live myself if I didn't let you know.
that's hilarious, thanks for sharing that.
Perennially relevant xkcd: https://xkcd.com/1053/
1 reply →
Google considers it too violent apparently. In one of their recent changes to their style guide, they started recommending "dash-case" instead.
https://developers.google.com/style/word-list#letter-k
This guide is stupid. They recommend not using “janky.”
Tbf, dash-case is more descriptive. Kebab doesn't mean skewer everywhere
Same. I had tears in my eyes from laughing. For some inexplicable reason it seems incredibly funny.
I'm of the opinion that kebab-case is the best case for all identifiers, because it's easy to read and to type. As always, Lispers were right all along.
Kebab case is the often overlooked benefit of prefix notation and semantic white space in programming languages. Honestly the best case of all cases imo.
One glorious day we'll accept programming languages that require spaces around infix arithmetic operators so that we can make kebab case a reality!
Forth does something like this, by virtue of its reverse Polish notation.
In Forth, 'words' (which are roughly analogous to functions and operators) must always be separated by whitespace, as Forth doesn't parse out operators the way most languages do. In exchange, you get the ability to use symbols in identifiers, as Forth has no reason to single out symbols like + as being syntactically special. You can even use a number for the first character. (For that matter, Forth will even let you override the usual interpretation of a numerical literal, but that's always struck me as going a bit far.)
It gives you a + word, analogous to the + operator of most languages [0]. It also gives you a 1+ word, as an (admittedly slight) abbreviation of the sequence 1 +. [1] If you wanted a 2+ word, you could easily define it yourself.
(This property of Forth evidently wasn't enough to get it to take over the world, but it's still neat.)
[0] https://www.complang.tuwien.ac.at/forth/ansforth-cvs/documen...
[1] https://www.complang.tuwien.ac.at/forth/ansforth-cvs/documen...
Maybe Raku[1] is for you!
[1] https://raku.guide/#_syntax_overview (see section 1.7.1)
Lisps, especially Scheme with its `x->something-else` convention, have ruined naming in other languages for me.
I found that some_document_2021-01-01_v03.pdf works best because it keeps the same document next to its other versions alphabetically, keeps them in date order, and keeps them in a sub-day version order.
In my work, today's date would be 21K11, to save space over the longer date.
Are you working in some embedded system with tiny memory space or something? What's the use of saving one character? Just make it YYMMDD!
How do you distinguish 21K111 and 21K111?
Are you trying to catch GP on differentiating hours, were it to be appended to his time format (1st @ 11 vs 11th @ 1am)?
Notably he didn't promise any, but presumably one'd need a separator... Maybe, per his "K" usage of the month, one'd use the alphabet again. 11am would be "K" again... or lowercase just for giggles?
I don't think it reads very well, but I also think one'd get used to it pretty quickly.
3 replies →
As a side note, in the good ol' times of ISO9660 level 1-4 and the various mkisofs parameters, an underscore _ which is a CAPITAL -, may have given issues, only for the record/as a curiosity:
https://web.archive.org/web/20151007005513/http://www.911cd....
P.S. should anyone want to see/run the actual batch, a copy has been uploaded here:
http://reboot.pro/index.php?showtopic=18962&page=29#entry204...
> 2021-01-01
Yes on the date format.
Saves you so much time.
I don't bother with the century or the dashes, saves time...
211111_foobar_v1.txt
I am old enough that I still save before printing. I think it was Lotus 123 that engrained it for me.
Agreed on dates ordering problem but 20210101 is so much easier to type.
But much less easy to read!
Years that end in a 1 are awful when doing this, especially in October and November. We've had 20211001, 20211010, 20211101, 20211110, and now today 20211111.
I just tend to use $(date -Is) so I don't need to think what date it happens to be today. I guess -Id would work if you don't want the time part.
This used to be my default, and then I used Matlab, and "-" was interpreted as subtraction.
I use this style:
2021-01-01_what-happened_who-did-it_possible-reason