11–20 of 60 posts
Considered that most of the world uses "little-endian" format for date writing ( https://en.wikipedia.org/wiki/File:Date_format_by_country_(n... ) how comes ISO 8601 was set on "big-endian"? Not so practical for anything else but file naming IMHO...
BRAFWTNEGASSAY doesnt make any sense. To distinguish between the filenames you actually have to read the full filename, and with such long filenames chances are they won't fully be displayed, so that you have 2013-06-26_BRAFWTNEGASSAY_Plasmid-Cellline-100-1MutantFrac... For the first four files.
Keeping cruft out of your filenames seems like a much, much better way to name files. Also, most systems keep track of the creation data, no need to keep it in the filename. I think it's better to give files an id.
Those filenames look terrible to me. BRAFWTNEGASSAY doesnt make any sense. To distinguish between the filenames you actually have to read the full filename, and with such long filenames chances are they won't fully be displayed, so that you have 2013-06-26_BRAFWTNEGASSAY_Plasmid-Cellline-100-1MutantFrac... For the first four files. Keeping cruft out of your filenames seems like a much, much better way to name files.…
True, but often it makes sense to put date into the filename as well. For example, notes for an event that happened on a certain date. You might write the first draft at that date and then edit/move it later. It's still strongly related to the date the event took place, but the filesystem ctime and mtime will be different.
My only real concern is with left-padding numbers with 0s when you don't know in advance how big the numbers are going to get. Do you pad to 2 or 3 digits or...
Those filenames look terrible to me. BRAFWTNEGASSAY doesnt make any sense. To distinguish between the filenames you actually have to read the full filename, and with such long filenames chances are they won't fully be displayed, so that you have 2013-06-26_BRAFWTNEGASSAY_Plasmid-Cellline-100-1MutantFrac... For the first four files. Keeping cruft out of your filenames seems like a much, much better way to name files.…
You could have named it differently: 2013-06-26_KUTKLOON7_Plasmid-Cellline-100-1MutantFrac
Creation date can sometimes be lost if you copy/move the file between different mediums
Those filenames look terrible to me. BRAFWTNEGASSAY doesnt make any sense. To distinguish between the filenames you actually have to read the full filename, and with such long filenames chances are they won't fully be displayed, so that you have 2013-06-26_BRAFWTNEGASSAY_Plasmid-Cellline-100-1MutantFrac... For the first four files. Keeping cruft out of your filenames seems like a much, much better way to name files.…
I agree. Maybe at some point, and in his example I think it makes sense to just change some of those '_' to '/' and boom, you now have folders.
Considered that most of the world uses "little-endian" format for date writing ( https://en.wikipedia.org/wiki/File:Date_format_by_country_(n... ) how comes ISO 8601 was set on "big-endian"? Not so practical for anything else but file naming IMHO...
Second "little endian" dates are inconsistent because the year is still big endian. If you want to remain consistent you would have to write the current year as 1720 (or even 7120!) because the years (or decades) are smaller than the century. To achieve the consistency of ISO 8601 with little endian time you would also have to write seconds before minutes and minutes before hours.
> avoid [...] accented characters It's certainly good advice and I definitely avoid using non-ASCII characters in filenames in practice. But I can't help thinking that advice like that is why support for Unicode is still buggy in many places. I see nothing fundamentally wrong with using non-ASCII for filenames (and the slides don't give any reasoning), if only random software wouldn't mangle encodings, sorting order,…
I like to call this middle endian.