Is anybody else using ridiculously long variable names?

I do as a way to self-document the code. Many people who I have worked with love this because the code is easier to read, easier to understand, and becomes more maintainable. Just my two cents.

Yep. I used to not do this, but now, self documentation and clear understanding of how that variable should be used is awesome.

In Rust I've even started doing something additional which is use the shadowing feature. This was always a big no-no in other languages, some don't allow it, others do something different, but in Rust it can be used safely to reduce the explosion of variables in certain contexts. This helps reduce the need for distinctions between variables, allowing for shorter names.

Make sense to me. Just avoid names like "longinteger1". This doesn't mean anything.

What kind of horribly constrained environment are you running on that you're worried about long variable names making your binaries too big.

Group variables that all track the same thing into an object.

So you csn have saved_state.tracked_picture.

Makes it clear what group something is in and what the name of that data is meant to be.

Much easier to parse.

I can highly recommend reading the "Meaningful Names" chapter in Clean Code for practical and useful advice on this topic (some good notes here http://www.itiseezee.com/?p=83)

Yes, more so when they are used infrequently e.g. maxAllowedInvalidAuthenticationAttempts. Autocomplete is your friend. I try to make it very explicit and not just a long word bag. I use short generic names when context is obvious: index, count, max, min.

Only for globals or where you really, really need it. For locals and lambdas, I try to use 1 or 2 char vars. Usually the first letter of whatever the type is. XmlNode -> xn. Event -> e. Longer if needed, but hopefully that's rare.

Really long names in functions just make reading harder. I am not sure it makes things actually clearer. Can someone understand the code without actually understanding the function? Can they make an edit?

Yes. I had an application that had to interact through REST services with a second application. Three specific variables needed to be passed back and forth. Unfortunately, they were given entirely different names in the different systems so I ended up with:

    firstSystemNameAKAsecondSystemName

Nobody was confused.

My general rule is that the greater the scope -- lexical or runtime -- of a variable, the more descriptive its name (which often means longer but not always!)

So, for a short lived variable, I'm personally ok with it being short, as in, some random bit of python:

  # strip the last char from everything in a list
  some_list = [s[:-1] for s in some_list]

IMHO, I don't really think it matters what 's' is here, and I don't think it would would be that helpful if given a more meaningful name. The cognitive load is small.

Conversely, variables that live a long time and/or operate globally are better off with a longer name.

However, I would observe that your example might suggest a coding issue, the tipoff being 'and'. If a single variable is handling two chunks of state, then perhaps it's doing too much and you might be better off with something like:

  val documentSavedOnDiskJsonStates...
  val pdfSavedOnDiskJsonStates

Not huge savings there, but perhaps also things might get clearer encapsulating these things in a class, with methods like (just making stuff up):

  document = Document.getFromDisk()
  document.jsonStates()

Not saying that this is always the correct approach or valid in your particular case, just making the general observation that IME highly modular code tends to require fewer really long names.

Variable name length should be proportional to scope. Lambda parameter, or loop iterative? Go with x or i. Global variable? Make it descriptive.

Always, only use x, y, z, etc. when they are descendants of the variables with big names.

Because autocomplete.

Really don't understand the binaries implication.

Objective-C user checking in: yes.

Code is for humans to read and machines to execute. So as far as it is readable, I won't change long variable names. I've used long names many times, when it is deserved. Most of the times it is longer function/method names, or constants or configuration variables.

However, if a method/function is too long (i.e. too many lines in that single method/function) then it is very likely to have longer variable names within the scope and that method itself is likely to be a good candidate for refactoring. Sometimes the same applies to configuration variables (for example- stuff you read from a json config)

During development it is helpfull; also, if the code is not being commented thoroughly as the programming continues, the LongZOMGxVarNamesLikeThisToIllustrate variable names which have served their purpose, help in doing the commenting nicely and may or may not be shortened at that time.

It depends.

I'm skeptical `documentAndPdfSavedOnDiskJsonStates` is a useful variable name. Without context it's hard to say. It sounds like you have a couple of collections of states (state names?) for various document types.

PDFs are already documents, so that seems redundant. It already sounds like `savedDocumentStates` and `thumbnailStates` would be adequate--but again, without any context, it's impossible to know if that would be adequate.

(Personally I'd have a type => state mapping and skip them altogether, and use a different form of classification altogether.)

If you've got a developer with previous Objective-C/Cocoa/iOS experience they'll be used to having crazy long method / variable names.

You can find a list of examples here: https://github.com/Quotation/LongestCocoa

Edit: I just had to quote the longest one: "outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch:"

Longest and oldest I remember: `we_need_to_sort_interface_list` circa 13 years ago: https://github.com/freebsd/freebsd/commit/fdbb382f1cbb42ab48...

Aww, looks like someone renamed it a decade later: https://lists.freebsd.org/pipermail/svn-src-head/2013-Februa....

Yes, this happens all the time. In some language it's more common than others. Here are some arguments against it:

http://journal.stuffwithstuff.com/2016/06/16/long-names-are-...

I end up doing this because I'm either using Eclipse or Vim + YouCompleteMe. Every programmer should get their autocomplete story in order so we can all hop on the long variable name train :)

A Nickel's Worth's guide on variable naming seems like a relevant read here:

https://a-nickels-worth.blogspot.ie/2016/04/a-guide-to-namin...

the wider the scope, the more explicit you need to get to disambiguate the meaning of something. long variable names are just a hint that your scope is too wide and a wide scope usually means:

- high coupling

- lack of encapsulation

- action at a distance

- wrong level of detail

Therefore it's a code smell. Imagine we referred to each other as "multicellular organism from the kingdom animalia phylum chordata clade synapsida class mammalia order primates suborder haplohrini family hominidae genus homo species homo sapiens sapiens".

I found one today in Go source code: https://golang.org/src/net/fd_windows.go variable name: hasLoadSetFileCompletionNotificationModes

> documentAndPdfSavedOnDiskJsonStates

1. Why is it the document and the PDF? Are they the same thing? if so, pick one term and use it consistently.

> SavedOnDisk

2. Disk is the default place to save things.

> Json

3. JSON isn't an interesting label, as it gives you no ides of the data structure. If this is a hashmap with a bunch of document titles and booleans with their save status, then that should be obvious.

This thing seems to be save state for multiple documents, right?

So I'd replace:

> documentAndPdfSavedOnDiskJsonStates

with

    documentSaveStates

or

    pdfSaveStates