Reminds me of the o-ring on the challenger

Does anyone have any good advice on variable naming? Here’s some of my rules I try to live by:

• camelCase
• use prefixes
• prefixes should be one word followed by an underscore.
• 10 character limit or 3 word limit, not counting the prefix
• functions should be prefixed with the file in which they’re defined, ie utils_FooBar
• file names should be one word
• Start Bools with is
• Don’t use not in bool names.
  • This has farther-reaching implications that will keep you from making confusing code most of the time (I’m sure this will be controversial, but it works no matter what they say)
• start output with _
• Globals should be g_VARIABLENAME
• use the least amount of words possible
• but being too verbose can draw attention - use this to aide in readability
  • calc_ImportantValueThatWillDecideTheUsersView is better than calc_SumYears if the variable is more important than the others.
• Even the greatest variable names are not replacements for documentation
• Even the most readable code is not replacement for documentation.
  • Force yourself to love documentation.

Edit: I realize I was speaking about function-naming with the prefix stuff.

For variables, I still use prefixes, but for variable type. Even if you define the variables as types, it’s still incredibly useful. For instance,

a string is s_MyName,

enumerable is e_MyType,

A number is int or double or whatever i_MyAge or d_MyWeight

This might be obvious for custom objects, but I’d still do it like this p_Person or per_Person.

Seriously it does make a huge difference

Watch a Video or read something because it really is an invaluable tool. But here’s a crash course:

Debuggers, or IDEs, let you step through your code in slo-mo so you can see what is happening.

1. Set a breakpoint - Click to the left of a line of code so a red dot appears. Run your program, and the IDE will execute to that line, then pause.
2. Look at variables’ values - While the execution is paused you can hover over variables before that line to see their value.
3. Step through the code - See what happens next in slo-mo.
   • Use “Step Into” to enter into a function and see what that code does.
   • Use “Step Over” to not go into a function and continue in the current spot after the function has done its business.
   • Use “Step Out” to exit a function and pick up the execution after it has run. Use this when you’re in too deep and the code stops making sense.
4. See whats in the heap - The heap will list all the functions that you’re currently inside of. You can jump to any of those points by clicking them.
5. Set a watch - Keep a variable in the watch so you can see what its value is at all times.
6. Set a condition on the breakpoint - If the breakpoint is inside a big loop, you can right-click on the red dot to create a conditional breakpoint, so you write something like x===3 and it will only pause when x is 3.

There are many other things an IDE can do to help you, so def look into it more if you want to save yourself a lot of insanity. But this is a good starting point.

If you’re developing for the web use F12 to open web tools, and when an error happens, click the file/line number to see that point in the Sources tab, and you can debug there.