myVariable vs lcMyVariable 1

[Neil Toulouse]

I think this is just a case of what you prefer, but I am with notation all the way.

If you are maintaining code from others, having the 'lc' or whatever, gives you an indication of what the coder was trying to achieve, especially when you need to debug! If you hit a bug you can hover over the offending variable and see, for example, an lcString giving a value of 1 instead of "1" and see immediately the cause of the bug.

If you want elegance, you've got "beautify"!

...but seriously put the elegance into your application interface instead, that's where it always seems lacking!

Neil

I like work. It fascinates me. I can sit and look at it for hours...

 

[Mike Lewis]

Neil,

I think this is just a case of what you prefer, but I am with notation all the way.

I agree with that, although people in my situation don't always have a choice -- it's sometimes a matter of going with the client's preference.

My own preference has changed from not using Hungarian to fully embracing it. Maybe it will change again one day.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[tvign]

Mike:

I understand you situation. I am not bound by clients.

Neil and Craig:

Taking Craig's example,

lcX = gcY + frmZ.Something()
...a wealth of information is now apparent.

Not necessarily apparent unless all variables and functions are stongly typed. If they are not and are polymorphic, then it actually obfuscates.

Say, gcY = date() and frmZ.Something() returns 3, then no error occurs at that line!
Nor will an error occur if both are numbers.

So, lc,gc doesn't help. To say a variable is character doesn't make it so. It reveals only intent as Neil pointed out.

Neil:

As far as putting elegance into the application interface, bravo!