Considering most IDEs can autocomplete basic things like function names, would it be beneficial (for learning purposes at least) that a language avoids ENTIRELY any abbreviations?

For example, let's take some of C's printf family.

Instead of fprintf, printf and sprintf, the new function names would be something like print_formatted_to_filestream, print_formatted and print_formatted_to_string respectively.

C was written in a time your screen couldn't handle much chars. That's probably why the abbreviations.

I'm in for without abbreviations

No, it shouldn't. It's just noise when reading that stuff. You're only noob for a while.

Can't wait for more grumpy oldfarts defending the likes of "strncmp" and such due to the great vowel-shortage 1940 to 2010..

@Fast-Nop you seem to hate vowels, are you secretly Polish?

First of all, you're not only writing code, you're also reading it. In fact, you only write the code once, but you (and probably other people) will read it many times. And reading 30 characters just to know whether the function prints to a file stream or to some other type of output quickly becomes a major pain in the ass. The longer it takes to read the code, the harder it is to pay attention to what the code does.

Second, the more characters there are in a function name, the more likely it is to get matched for autocompletion, ultimately making autocompletion less useful.

I understand your thought that code should be optimized for reading rather than typing fast.

But when it comes to the most commonly used features, like printf, it's so easy to learn this word on an intuitive level. But I cannot inuitively remember the longer word you mentioned here.

I'm fine with languages having long names for unusual functions, but for commonly used ones I prefer short words.

@jiraTicket This. I want niche stuff used once in a blue moon to be descriptive, but stuff constantly used to be (realistically) as short, yet still meaningful as possible. Heck, if anything it's such a commonly used function that printf should be abbreviated *more*, not less.

@AlmondSauce yes, ideally "printf" would be "print" 😊

@jiraTicket Or "p" 😉

I'd also wager that even if most devs in wordy languages like Java get an intuitive memory for long names that are commonly used - there's still a vibe that it would be nice if they were shorter. And in general dev happiness measurements, satisfaction increases when the standard libs use short and sweet naming for most common features

That being said I wouldn't want a new rarely used feature like "print info about garbage collection" to be named "printIaGB"

I am in support of the idea that code can be read like sentences. Or at least sentences a child could muster together.

Though I fully acknowledge the original famous person that came up with this point gave up on it.

But that's why I think properly named long function names are good.

If you don't know what sprintf does, you should read the docs anyway in case there are caveats that aren't immediately obvious just by thinking about the function's purpose. Additionally, there are naming patterns that allow a seasoned user of the language - the only people who should ever venture to assume the behaviour of a function without at least glancing at the docs - to infer its purpose when reading code. I'm not a C dev and only spent like a week in my life writing C, but I correctly guessed that the extra 'n' in "strncmp" means "up to length n".

I think a better solution is inline docs and IDE support for them for every language. This way if you haven't seen a function before you can quickly access a brief description of what it does, except because the author isn't pressured to compress this description, it can also include frequent mistakes and other useful information.

If you look at any Rust library, you'll find brief, vague and extremely general names, the intent clearly being that the user can type a few characters related to their needs, fuzzy find every function that includes those characters, and read the (heavily crossreferenced) inline docs to figure out which one they need.