Is anybody else using ridiculously long variable names?

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!)<p>So, for a short lived variable, I&#x27;m personally ok with it being short, as in, some random bit of python:<p><pre><code> # strip the last char from everything in a list some_list = [s[:-1] for s in some_list] </code></pre> IMHO, I don&#x27;t really think it matters what &#x27;s&#x27; is here, and I don&#x27;t think it would would be that helpful if given a more meaningful name. The cognitive load is small.<p>Conversely, variables that live a long time and&#x2F;or operate globally are better off with a longer name.<p>However, I would observe that your example might suggest a coding issue, the tipoff being &#x27;and&#x27;. If a single variable is handling two chunks of state, then perhaps it&#x27;s doing too much and you might be better off with something like:<p><pre><code> val documentSavedOnDiskJsonStates... val pdfSavedOnDiskJsonStates </code></pre> Not huge savings there, but perhaps also things might get clearer encapsulating these things in a class, with methods like (just making stuff up):<p><pre><code> document = Document.getFromDisk() document.jsonStates() </code></pre> 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.

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.

Code is for humans to read and machines to execute. So as far as it is readable, I won&#x27;t change long variable names. I&#x27;ve used long names many times, when it is deserved. Most of the times it is longer function&#x2F;method names, or constants or configuration variables.<p>However, if a method&#x2F;function is too long (i.e. too many lines in that single method&#x2F;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)

It depends.<p>I&#x27;m skeptical `documentAndPdfSavedOnDiskJsonStates` is a useful variable name. Without context it&#x27;s hard to say. It sounds like you have a couple of collections of states (state names?) for various document types.<p>PDFs are already documents, so that seems redundant. It already sounds like `savedDocumentStates` and `thumbnailStates` would be adequate--but again, without any context, it&#x27;s impossible to know if that would be adequate.<p>(Personally I&#x27;d have a type =&gt; state mapping and skip them altogether, and use a different form of classification altogether.)

Yep. I used to not do this, but now, self documentation and clear understanding of how that variable should be used is awesome.<p>In Rust I&#x27;ve even started doing something additional which is use the shadowing feature. This was always a big no-no in other languages, some don&#x27;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.

TL;DR - It depends ;)<p>The examples you provided (with some context gleaned from your other comments) look like they&#x27;re probably too long and tack on unnecessary domain specific detail (e.g. jsonStates).<p>Both variables in your example would likely be better off describing the use of the variable rather than the contents. E.g. use ageInYears rather than yearsAliveInt. Taking it to your example, perhaps something along the lines of convertedDocument would do, this is significantly shorter than your example, but perhaps conveys enough info for your ongoing usage.<p>This is covered to in Clean Code [1]. &quot;The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used.&quot; The notes on the naming chapter at [2] are quite good as well (as noted elsewhere on this thread by @runesoerensen)<p>I like to follow the principle in naming variables that if I could read the code to a non-technical user verbatim and have them understand the code, it is &quot;good code&quot;. I.e. does reading the code out loud as a sentence make sense, or do the verbs and nouns I&#x27;ve chosen act as a barrier to understanding.<p>EDIT:<p>Ward Cunningham said that last part better: “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”<p>[1] Martin, Robert C. (2008-08-01). Clean Code: A Handbook of Agile Software Craftsmanship (p. 18). Pearson Education. Kindle Edition. <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Clean-Code-Handbook-Software-Craftsmanship&#x2F;dp&#x2F;B001GSTOAM" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Clean-Code-Handbook-Software-Craftsma...</a><p>[2] <a href="http:&#x2F;&#x2F;www.itiseezee.com&#x2F;?p=83" rel="nofollow">http:&#x2F;&#x2F;www.itiseezee.com&#x2F;?p=83</a>

I can highly recommend reading the &quot;Meaningful Names&quot; chapter in Clean Code for practical and useful advice on this topic (some good notes here <a href="http:&#x2F;&#x2F;www.itiseezee.com&#x2F;?p=83" rel="nofollow">http:&#x2F;&#x2F;www.itiseezee.com&#x2F;?p=83</a>)

If you&#x27;ve got a developer with previous Objective-C&#x2F;Cocoa&#x2F;iOS experience they&#x27;ll be used to having crazy long method &#x2F; variable names.<p>You can find a list of examples here: <a href="https:&#x2F;&#x2F;github.com&#x2F;Quotation&#x2F;LongestCocoa" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Quotation&#x2F;LongestCocoa</a><p>Edit: I just had to quote the longest one: &quot;outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch:&quot;

&gt; documentAndPdfSavedOnDiskJsonStates<p>1. Why is it the document <i>and</i> the PDF? Are they the same thing? if so, pick one term and use it consistently.<p>&gt; SavedOnDisk<p>2. Disk is the default place to save things.<p>&gt; Json<p>3. JSON isn&#x27;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.<p>This thing seems to be save state for multiple documents, right?<p>So I&#x27;d replace:<p>&gt; documentAndPdfSavedOnDiskJsonStates<p>with<p><pre><code> documentSaveStates </code></pre> or<p><pre><code> pdfSaveStates</code></pre>

Using them: Yup. Even though I only use an 80 character terminal. I prefer line breaks over having no clue what a function does&#x2F;variable is. Sometimes it takes me an hour to realize the algorithm I am looking at is something I already know.<p>Debating: Definitely. Some Java (not C-style) constructs simply <i>require</i> 100+ character terminals to be readable. Their community has(have not) absolutely adopted IDE&#x27;s with exceptional auto-completion. 10 C++ programmers, 10 development environments (unless you have a fantastic system administrator). So for a mathematician translating their symbols into syntax, one letter is enough. A maintenance programmer understanding a legacy system...Longer names, &#x2F;please&#x2F;.

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.

Longest and oldest I remember: `we_need_to_sort_interface_list` circa 13 years ago: <a href="https:&#x2F;&#x2F;github.com&#x2F;freebsd&#x2F;freebsd&#x2F;commit&#x2F;fdbb382f1cbb42ab486d1f7812f0f78c0317b799#diff-bb6d5274442cdd13b81de7e39c3368fbR249" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;freebsd&#x2F;freebsd&#x2F;commit&#x2F;fdbb382f1cbb42ab48...</a><p>Aww, looks like someone renamed it a decade later: <a href="https:&#x2F;&#x2F;lists.freebsd.org&#x2F;pipermail&#x2F;svn-src-head&#x2F;2013-February&#x2F;045058.html" rel="nofollow">https:&#x2F;&#x2F;lists.freebsd.org&#x2F;pipermail&#x2F;svn-src-head&#x2F;2013-Februa...</a>.

I&#x27;ve been working on some legacy code which has been fun lately, and a lot of the functions are like get_something_one_way in one model, then another model will be like find_something_the_same_way - for instance get_store_by_slug, and find_product_by_slug -- this annoys the crap out of me... use find or get and standardize functions..everything should have a standard to make it easier to know what you&#x27;re looking for.. I like to use find --when I&#x27;m querying the database, and get when I&#x27;m querying an external API or when I&#x27;m proxying an api from a model.

Yes, this happens all the time. In some language it&#x27;s more common than others. Here are some arguments against it:<p><a href="http:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2016&#x2F;06&#x2F;16&#x2F;long-names-are-long&#x2F;" rel="nofollow">http:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2016&#x2F;06&#x2F;16&#x2F;long-names-are-...</a>

A Nickel&#x27;s Worth&#x27;s guide on variable naming seems like a relevant read here:<p><a href="https:&#x2F;&#x2F;a-nickels-worth.blogspot.ie&#x2F;2016&#x2F;04&#x2F;a-guide-to-naming-variables.html" rel="nofollow">https:&#x2F;&#x2F;a-nickels-worth.blogspot.ie&#x2F;2016&#x2F;04&#x2F;a-guide-to-namin...</a>

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.

Make sense to me. Just avoid names like &quot;longinteger1&quot;. This doesn&#x27;t mean anything.

I found one today in Go source code: <a href="https:&#x2F;&#x2F;golang.org&#x2F;src&#x2F;net&#x2F;fd_windows.go" rel="nofollow">https:&#x2F;&#x2F;golang.org&#x2F;src&#x2F;net&#x2F;fd_windows.go</a> variable name: hasLoadSetFileCompletionNotificationModes

I end up doing this because I&#x27;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 :)

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:<p>- high coupling<p>- lack of encapsulation<p>- action at a distance<p>- wrong level of detail<p>Therefore it&#x27;s a code smell. Imagine we referred to each other as &quot;multicellular organism from the kingdom animalia phylum chordata clade synapsida class mammalia order primates suborder haplohrini family hominidae genus homo species homo sapiens sapiens&quot;.

Group variables that all track the same thing into an object.<p>So you csn have saved_state.tracked_picture.<p>Makes it clear what group something is in and what the name of that data is meant to be.<p>Much easier to parse.

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

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 -&gt; xn. Event -&gt; e. Longer if needed, but hopefully that&#x27;s rare.<p>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?

Brevity is the soul of wit - I try not to make long variable names if I can help it.

Objective-C user checking in: yes.

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:<p><pre><code> firstSystemNameAKAsecondSystemName </code></pre> Nobody was confused.

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

Always, only use x, y, z, etc. when they are descendants of the variables with big names.<p>Because autocomplete.<p>Really don&#x27;t understand the binaries implication.