Ask HN: Why is the source folder called 'src'?
Many languages and frameworks advocate (or even enforce) a standard folder structure that includes a 'src' folder.
I always found 'src' to be quite "ugly" and also possibly confusing to beginners, who might think it's an abbreviation of a multi-word phrase instead of a contraction. In the end, it only reduces the word by 3 letters.
Why isn't it simply called 'source'? Does it have historic reasons? Or is it just laziness? 'src' has inertia carried over from Unix. Unix systems have kept the source is /usr/src since since at least the late 70s. That's in keeping with the general terseness of Unix. Similar to how only errors are reported; successful execution means nothing is printed by default but a new prompt. And it's why most of the original file system manipulation and text editing commands are 2 or 3 letters long. Tradition now, I guess. Originally, way, way back in the day, there was good reason to be so terse. The first UNIX machines had literal teletypes for terminals; printers with moving parts. Every extra character meant wear and tear, paper, ink, and especially, time. Per https://unix.stackexchange.com/a/10816/6388, referencing https://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE18, "Source code may be place placed in this subdirectory, only for reference purposes" One presumes calling it "src" is in historical alignment with UNIX using short names wherever possible to reduce typing (and the possibility for typos) See also: "ls" (list files), "mv" (move), "cp" (copy), "/usr" (userland-specific items), "/bin" (binaries), and on and on My best guess is that `src` is shorter than `source` and thus faster to type. UNIX was also introduced in the 1970s when you frequently were working with a 110 baud modem and/or a printing terminal. That's why UNIX uses very short command names like 'rm' and 'ls'. "White space is as important to code as silence is to music. Without them music is noise and code is an impenetrable wall of text." -Nils M Holm That's white space. Difference between source and src is more like a 1/8 note vs 1/4. Probably true for Lisp, but gofmt would disagree. Writing a formatter for lisp would be a piece of cake, as the syntax is very simple I meant to refer to how gofmt doesn't destroy information (to a human reader) whereas a Lisp formatter would probably make well-formatted comprehensible source much less so: conceptual chunks can't be inferred from syntactic ones--well maybe with GPT-3. I feel like long names were popularized with Java and books like Clean Code (2008). Today you see names like "destinationAccountForTransfer". 10 years back it was common to see "destTransfer". 15 or so years ago you might see "szDest" instead. The general "clean coding" rule is longer names for global and/or big namespaces and shorter names for localized, smaller ones. For example, a local variable that's defined in the current function or block can have a very short name, whereas for a module-wide function you'd pick something longer and clearer. Even more so for something that's globally accessible to the whole program, or exported as an API. Shortening was probably driven by storage constraints - 3 bytes saved multiplied out by a few hundred references becomes a real saving on a 1.2Mb floppy disk. One of the reasons I hate the command line is that it causes all sorts of tiny hacks like this as you need to type everything out. Tab is your friend You can type `src` easily with one hand, `source` requires two. Not _the_ reason, but a reason for not changing. Minor sarcasm above.