VariableOrFunctionNamesAreNotSentences. I_Wish_More_Developers_Would_Realise_This_Before_My_Code_Reaches_900_Characters_Per_Line_Long.

Seriously, rely on namespacing and context more, you wouldn't normally communicate using maximum verbosity, you rely on context to convey the precise meaning. The same should apply to your programming.

Yes, very much.

I think it indicates more about personality and coding style than direct experience level.

Good naming conventions may indicate experience, a good mentor or simply a methodical person. I have also seen fairly chaotic code come from highly-experienced people who were in a rush or simply a fast-and-loose programmer. The code will probably indicate whether someone's a stable or volatile.

Conventions may indirectly demonstrate experience levels though, since the conventions someone uses can hint at the era and language they first learned to code.

How you name your functions doesn't necessarily demonstrate that you have skill or lack thereof, but rather, the names that you use should serve as a good example of how that variable or method should behave.

So if I wrote a method called stringify, without you knowing the inside of the method you could probably deduce that it would convert something to a string. However if I named this method convert instead, it's a much more abstract term and you would probably have to read the method body to find out its functionality.

Good variable names should describe their contents and should mean that you can hold off commenting your code with filler; it looks nice but isn't necessary:

function sum (a, b) {
  // Add the two numbers together
  return a + b;
}

This code would be clearer if the parameters describe what they are:

function sum (numberA, numberB) {
  return numberA + numberB;
}

The code is more verbose, but it's clearer that both of the arguments are numbers. You could also use something like Flow as a type system, which would make this explicit:

function sum (a: number, b: number) {
  return a + b;
}

I tend to prefer this style over using block comments, as they can end up being overly verbose. For example, the same code using something like JSDoc:

/**
 * Add two numbers
 * @param {number} a
 * @param {number} b
 */
function sum (a, b) {
  return a + b;
}

It's also good to use naming conventions when appropriate. For example, many Node-style callbacks are represented as cb:

function foo (cb) {
  return cb(null, 'foo');
}

And e is often an acceptable identifier for an error:

try {
  functionThatThrows();
} catch (e) {
  console.log(e);
}

There are others, and sometimes the language necessitates the usage of short variables so as to not confuse your variable/method name with a global keyword - e.g. fn is often used for a generic function, or str for string. Don't go overboard with custom short names though; remember at least in JavaScript there are tools you can use to compress identifiers for production code, e.g. https://github.com/mishoo/UglifyJS2.

And one thing that is a big help; don't deviate from the standard practices in an ecosystem when it comes to naming things. So for example Ruby uses snake_case for method names whereas JS projects use camelCase. In my view it's best to use these conventions, because it will keep your code looking consistent with other libraries that you may be using. It's also easier for debugging, as you won't need to remember which style you used for any given method (if you used more than one).

It's been said before, but I'll say it again--the clever solution is often not the right solution. If you write some code when you are at the peak of cleverness, how can you expect to debug or even understand what you've written 6 months later? Be kind to your future self (and collaborators, in a team setting) by developing good habits. Small improvements really add up.

I'm learning JavaScript, but have had my fingers in code for a while. I've noticed a few different naming conventions, depending on the crowd I collaborate with, though I'm still getting better at naming variables myself. From what I've seen, variable naming conventions have more to do with the language you're using and your goals in writing the software than experience as a programmer.

Older coders, and coders of older languages tend to be more descriptive about the type their variable will represent. I believe this comes from languages where hungarian notation was used, or languages where variables of different types are declared differently. I find this wordy and unnecessary in JavaScript where the types aren't so strict - and it could actually be actively misleading if the variable changes type after it's created!

Another group of people I code with are Code Golfers, people who try to write code to be as small as possible and still run. Their naming conventions usually involve naming all variables in your code single letters, alphabetically, starting at a. This can be pretty confusing when you first look at a piece of code, but it focuses you to be so much more aware of the structure of your code, so I can see why they do it (saving bytes, and help focus on the design)

In my own programming I used to create variable names that were plural too often, I'd use tags instead of tag, or people instead of person, and over time I find using the singular form often reads a lot better later when you're using the variables.

var tags = document.querySelectorAll('div')

for (i in tags) {
  tags[i].innerHTML = 'Hello'
}

// vs

var tag = document.querySelectorAll('div')

for (i in tag) {
  tag[i].innerHTML = 'Hello'
}

You can see how writing tags makes sense when you're setting the variable - you're looking for multiple tags, but later in the logic it just feels cleaner to work with tag[i] instead of tags[i] when you're modifying a single tag.

I've also seen plenty of variables like isActive or isLoaded which would return either true or false, and phrasing that kind of a variable makes it really nice to write logic like:

if (isActive) { // do stuff }

I still feel like I'm at the start of my programming journey, so I'm looking forward to when I have the insight that comes after making enough mistakes you know which ways are better and which are worse!

In my experience, you can tell the difference between a complete beginner and someone with more experience from names only. Compare the following examples and decide for yourself:

fn sayHello() {
  let mut i = 0;
  let helloText = "Hello World <3";
  while i < 10 {
    println!("{}", helloText);
    i += 1;
  }
}

vs

fn sayHello() {
  let mut counter = 0;
  let textToPrint = "Hello World <3";
  while counter < 10 {
    println!("{}", textToPrint);
    counter += 1;
  }
}

there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

..... you can name things declarative, imperative, class context, module context, acronyms, verbose (my personal fav -> but without autcomplete you gonna hate me)

I have this discussions for over 10 years now, I know what I want and that I cannot say if you're good or experienced by the name of a method .... The only thing I can say is as soon as i see names like

_13_S

, which are not auto generated, that at one point in the near future I'm going to want to hit you .... ;)