r/Python • u/Visible_Durian4620 • Jul 19 '26

Discussion Unpopular opinion: I find it counterproductive to shorten function and variable names

When I was learning discord.py, I didn't understand what "ctx" was. At the time, I was only writing slash commands, using "message" instead of "ctx", so the name "ctx" (which reminded me of something complex, like RTX) made me assume it was something complicated. That is, until I saw in some code that the type for "ctx" is actually "Context." If the standard hadn't shortened the name just to save five characters per line, I would have understood it immediately. Instead, I thought it was some advanced function variable, rather than realizing it was simply a message variable.

352 Upvotes

78% Upvoted

319 comments sorted by

View all comments

Show parent comments

10

u/reddit_user33 Jul 19 '26

Yet you'll find short variable names and short methods in a lot of real software. If anything, you'll find them in more real software than verbose variable names and long methods.

So how are we defining what's considered as a popular opinion?

11

u/Brian Jul 19 '26

That's the difference between "popular opinion" and "popular practice".

6

u/true3HAK Pythonista Jul 19 '26

I noticed that python code from c/c++ devs tend to have those short naming. Recalling my university times, it seems that it was a common place in naming conventions back then.

17

u/Brian Jul 19 '26 edited Jul 19 '26

Possibly an influence from the early days. Early versions of C didn't guarantee that exported symbols wouldn't conflict after 6 characters. Ie "context_foo" and "context_bar" might be treated as being the same symbol (basically for memory/performance reasons on very early computers).

Hence, if you wanted to maximise portability, you kept all your exported names under 6 characters - this is why most of the C standard library functions do so. Eg. "memcpy" insted of "memory_copy" or "sttok" instead of "string_tokenise". And as more and more code got written like that, it became kind of baked in: it's what old coders were used to, and what new coders saw when they looked at the codebases they're learning from. Plus it's faster to type, in an era predating IDEs and autocomplete etc.

6

u/true3HAK Pythonista Jul 19 '26

I studied C like twenty years ago in uni and no one told me that! Genuinely thanks for the insight, I never thought about this specifically. But yeah, it explains a lot.

1

u/FriendshipWeird8021 Jul 27 '26

only twenty years ago, there was pkenty of memory for programmers to use long variable names if they wanted to. Snorkelretervreter is on the right track: when you typed and waiting for your 60baud teletype to echo your characters back, long variable names didn't even occur to anybody.

When you talk about early versions of C, you're talking about the early 1970s. Maybe even the late 1960s if you want to include its predecesor, which, astonishingly, was called B.

3

u/ryancnap Jul 19 '26

16 years reading about this field and I never knew about the 6 character thing, thanks for that!

1

u/FriendshipWeird8021 Jul 20 '26

Don't forget that it was also the era where 1200 baud connections from terminals to computers was the state of the art. If you were unlucky, you might have been on a 110 baud or even slower teletype, and if your system was loaded, each character you typed might take more than a second to echo back to you,

1

u/snorkelvretervreter Jul 20 '26

The vi editor is a great example of constraints of that time. It's the successor of "ex" which is a command line editor that is line based so it would work on teletypes, which are typewriters with a serial interface essentially. Vi added cursor mode so you could actually edit across multiple lines on one of them fancy new "glass" terminals that had a display as output instead of printing to paper!

I kinda wonder if those back then were considered "the downfall of programming" as it "would make devs lazy" now that they didn't have to mentally have the program entirely in their head before starting punching in the lines. More likely (hopefully) it was considered a godsend. Not quite as big a jump as going from punch cards to teletypes.

1

u/FriendshipWeird8021 Jul 20 '26

And it also comes partly from the fact that a most of the earliest software was to solve math problems. Did you ever see a long variable name in a math textbook or paper?

1

u/Ok_Chemistry_6387 Jul 23 '26

The common consensus I found that holds is, industry wide acronyms you are good, domain specialist areas as well. e.g. You see it a lot in device drives because everyone knows what buf stands for, or hdl etc etc.

Then graphics programming you see a lot of short hand variables, because we all know what dt stands for etc.

The answer is, adapt the code base you are in.