Peter via Dng said on 10 Oct 2025 15:01:27 -0700

>From:    Antony Stone <Antony.Stone@???>
>Date:    Thu, 9 Oct 2025 23:49:17 +0200
>> ... can extend ... /home/antony/data to /home/antony/taxes and 
>> /home/antony/household and /home/antony/music etc.  

>
>Therefore files such as these.
>/home/antony/taxes/income/2024
>/home/antony/taxes/income/2025
>/home/antony/taxes/property/2024
>/home/antony/taxes/property/2025

Trouble is, you'll have not only ~/taxes, but ~/MyDocuments, ~/music,
~/development, ~/MyCopyrights, on and on and on. If you had all of
those under ~/d, then you could just back up all of /d and not take
responsibility of remembering to name all your various categories of
data. Adding a /d costs you one directory level and two characters:
It's a bargain.

>
>According to Niklaus Wirth, replace some slashes with camel case.
>Fewer directories. More files per directory.
>/home/antony/TaxesIncome2024
>/home/antony/TaxesIncome2025
>/home/antony/TaxesProperty2024
>/home/antony/TaxesProperty2025

Replacing slashes with camel case (or is it CamelCase?) is a bad idea:

1. As directories get upwards of 500 files, lookup becomes slow, at
least on EXT4. If they're in a tree, you can typically have less
than 5o files or subdirectories in each directory, and lookup
becomes lightning fast.

2. Using the Linux hierarchical filesystem as a hierarchical database
makes development of programs to deal with your data much easier to
write, more efficient, and more intuitive. You won't need to parse
camel case, which is harder than subdirectory relationships, and
more important, you won't need to remember whether you called it
NovemberTrademarkNotebook or NovemberTradeMarkNoteBook. When data is
hierarchical in nature, I recommend representing it with a directory
hierarchy.

Niklaus Wirth was for sure a smart guy who gave us a lot of great
customs and principles, but I'm pretty sure he's wrong on this one.
Perhaps back in his day there were severe limits of subdirectory depth,
but I think those days are gone.

SteveT

Steve Litt

http://444domains.com