Not for your children (although that is important too since kids can be incredibly harsh and will pick on kids with names that they think sound different or odd)
This is to do with naming methods, properties, and just about everything else in your Xojo projects.
A good name indicates a number of things to anyone who reads the code. Purpose is the most obvious.
If all you had was a lot of methods named “foo” or “untitled” your application would be incredibly hard to figure out and maintain for very long.
So having a method named
SplitPropertyValuesIntoDictionary(jsonSource as JSonItem) as Dictionary
Gives you a decent idea what this method will do just by reading the full description and the names of the parameters.
Events have similar naming issues. They should convey what is happening when they are raised. “Action” has never been a great name for the event that is raised by a pushbutton when it is clicked on. Its not entirely horrid but it could be better.
might be better since that is what has occurred in a push button.
Some events happen DURING some other action. For instance when an expandable row in a listbox is clicked on you currently get a “ExpandRow” event – which might mislead you into thinking you have to write some code to actually DO the expansion like setting the rows expanded property to true as well as other code. Again the name isnt horrible but it could be better.
more closely reflects when the event is being raised; during the rows normal course of expanding. Again though this doesn’t convey much information about what is expected. Can you cancel the row from being expanded ? Without reading the documentation this name doesn’t tell you much.
might be even better as it tells you exactly what this event is for.
Now I know some will say “OMG thats so much typing” – yes – if you type every last thing out by hand. Learn to use Autocomplete and it will help you immensely and may even help you find other useful properties, methods etc that you may not know existed.
The better you pick names the more easily your code documents itself. I’m not advocating writing no comments in code but they should be about the general process being performed not the mechanics (unless the mechanics are really hairy)
see this excellent post about this subject