I’m currently writing a plugin for an open-source tool that will let me use LDAP as a backend store. Rather than let it become vaporware, I’ll just post a note about it and what it does once I’ve submitted the patch.
In the meantime, I’ll note that having a clearly defined standard for naming things is always a win. Whether it is a coherent scheme for your variables or your systems, it’s one less thing you need to think about. It allows those who are familiar with the environment to make assumptions — it raises the bar of complexity you’re able to handle without memorization, and frees up your internal registers for what is actually going on, either in the code or network topology.
In that vein, I finally got around to looking up some examples of Apps Hungarian for use in the aforementioned project. As soon as I had finished refactoring to use the new AHN names, the entire project seemed (somehow) much clearer:
for ( strCatalog, mpKeyValue ) in mpCatalogMpKeyValue:
# You can guess what everything is here pretty easily
First and foremost, any subconscious uncertainty about what a variable is used for disappears. It’s a palpable weight off your shoulders when you’re long into a parsing loop and have a dozen variables in use at multiple levels at any one time. I’m one who prefers verbose languages (think: C#). So if I can add the biggest win of that verbosity back into a language like Python simply by being disciplined in how I name my variables, it’s totally worth it.
You are joking, right?
By the way, please be a good Python citizen and go read PEP 8 (http://www.python.org/dev/peps/pep-0008/), especially because of underscores_for_variable_and_method_names.
So what on Earth does ‘mp’ stand for? Method pointer?
Map, but that doesn’t make the code more readable or more beautiful. I tend to follow the “if you cannot see the use of a variable right away your method is too long” school, but that’s coming from C# and Java. Anyway: Eeek. With my background this gives me the creeps
Ben:
I tend to agree with the assessment of function length, and perhaps the example is poor. A better one might be marking “unsafe/user strings” as
usSomeVariable.Which is necessary, particularly when your stack is a mile high and an inch across — and you’ve pretty much lost all relation to how far you are away from user input…
Robin:
No, I’m quite serious.
What you’re doing isn’t apps hungarian, it’s
systems hungarian:
http://www.joelonsoftware.com/articles/Wrong.html
can’t be bothered to read your link… i just hope you chose the right ms-hungarian (a.k.a. apps hungarian), not the wrong one (a.k.a. systems hungarian):
http://www.joelonsoftware.com/articles/Wrong.html
fraggle:
The mp prefix is from the original writeup for Simonyi’s Apps Notation. The choice of “strCatalog” is poor imagination on my part, of course, “stkCatalog” or “hksCatalog” or whatever is just as well for that case.
But it’s a one-line example in a blog post/I don’t care that much about making it perfect.
James: if you are trying to differentiate between different types of strings, perhaps you could use different types for the strings?
As an example, Django has a SafeString type that the template system assumes has already been escaped when inserting into the page. Override a few operators to prevent accidental mixing of safe and unsafe strings, and you have something much more effective than a variable naming convention.