Comments on: An observation on names As far as naming variables, I have a tendency to "split" the information in two parts where necessary (example: level names): a "computer part" and a "human part". This allow an "automatic/rational" way of storing information, as well an easy search by the human eye. For example: World1Level1Room4_TheAttic or in short W01L01R04_TheAttic Thus, strings will be sorted and it is easy to see the information - the eye will just search for _XXX. @Fabrice : while you have a small gain in completion, you give up an important semantic information. This is the "total time" not the "time total" and while you may be accustomed to it, a new programmer to your code may end up with the wrong interpretation of your variable. In code, I went from "clever" and "fast to type" approach to "always semantic first" approach. For now, it has never bitten me in the back, although my code lines are a bit longer now :) Well, I think it depends on people... As far as naming variables, I have a tendency to “split” the information in two parts where necessary (example: level names): a “computer part” and a “human part”. This allow an “automatic/rational” way of storing information, as well an easy search by the human eye.
For example:
World1Level1Room4_TheAttic
or in short
W01L01R04_TheAttic
Thus, strings will be sorted and it is easy to see the information – the eye will just search for _XXX.
@Fabrice : while you have a small gain in completion, you give up an important semantic information. This is the “total time” not the “time total” and while you may be accustomed to it, a new programmer to your code may end up with the wrong interpretation of your variable. In code, I went from “clever” and “fast to type” approach to “always semantic first” approach. For now, it has never bitten me in the back, although my code lines are a bit longer now :) Well, I think it depends on people…

]]>
By: David Neubelt/2011/02/12/an-observation-on-names/#comment-749 David Neubelt Sun, 13 Feb 2011 19:51:45 +0000 Lars: with Visual C++ you can use “debugger visualizers” to automatize the lookup, it helps a lot: David: You would still miss out on the runtime benefits of strings, like easy debugger integration. I'd rather have an easy to access string than some unique integer I'd have to look up through some auxiliary tool, particularly if you do not happen to have direct access to the database for that particular build. Of course, there's a flip side; if you're looking at a post-mortem minidump, it's way more likely that you have all the information you need in an integer than a string that may not be in the dump. David: You would still miss out on the runtime benefits of strings, like easy debugger integration. I’d rather have an easy to access string than some unique integer I’d have to look up through some auxiliary tool, particularly if you do not happen to have direct access to the database for that particular build.

Of course, there’s a flip side; if you’re looking at a post-mortem minidump, it’s way more likely that you have all the information you need in an integer than a string that may not be in the dump.

]]>
By: David Neubelt/2011/02/12/an-observation-on-names/#comment-726 David Neubelt Sat, 12 Feb 2011 23:28:53 +0000 I once inherited a project that was doing something very dumb. It was using a hash function as the *only* way of comparing strings.This mostly worked, except when there was a clash, which was simply fixed by changing the name until it worked...I fixed it by replacing the hash function with a function that reallocated strings into a controlled area of memory. Upon insertion into this area duplicate strings were merged. This new address of the string was used as a hash replacement.Pretty simple way of giving very fast static string compare test. I once inherited a project that was doing something very dumb. It was using a hash function as the *only* way of comparing strings.This mostly worked, except when there was a clash, which was simply fixed by changing the name until it worked…I fixed it by replacing the hash function with a function that reallocated strings into a controlled area of memory. Upon insertion into this area duplicate strings were merged. This new address of the string was used as a hash replacement.Pretty simple way of giving very fast static string compare test.

]]>
By: Fabrice Lété/2011/02/12/an-observation-on-names/#comment-724 Fabrice Lété Sat, 12 Feb 2011 14:49:30 +0000 A good point, never really considered that angle on it.A quick think over the names I've dealt with recently don't show any areas where it would help, but certainly worth keeping in mind for the future... A good point, never really considered that angle on it.A quick think over the names I’ve dealt with recently don’t show any areas where it would help, but certainly worth keeping in mind for the future…

]]>