|
appPath doesn't say nothing to me except that this is a path and suppose to be some sort of string, thought it doesn't have. We, for example, have paths defined in Database, so the path can be actually a long variable - ID in DB. See? Now I saw appPath and have NO idea what you mean by that, I have to go and search where it was defined, and if you hate HN, you won't use "m_" declaration for class members also, so your variable can be define anywhere. This increases programming time of your product for example.
BUT if you had declared your variable lpszAppPath , I can be sure that this is a string (LPCTSTR ), or if you declared nAppPath (in our particular case) I know that this is an ID to path in Database.
Simple as is
Philip Patrick
Web-site: www.stpworks.com
"Two beer or not two beer?" Shakesbeer
|
|
|
|
|
appPath tells me that it's the path to some sort of application; the details would depend on context. However, that gives me significantly more useful information than, say, lpszText , which tells me the datatype, but not how the stupid thing is used.
HN requires the developers to keep all occurrences of the identifier consistent with its datatype. I'd much rather go back to its definition, where I can see in detail what the compiler thinks it's supposed to be, than risk making a bad assumption.
But we've gone way off topic here.
|
|
|
|
|
Well, noone talking about lpszText , but about lpszAppPath , which tells you type AND what this variable for.
UltraJoe wrote:
I'd much rather go back to its definition,
I suppose that you mean a small project, maybe 1-2 classes/cpp files in it. But think about something bigger. Example is not very far - in my company, there are like 30 different modules (.dll and .exe) written by different people. And you use someone else's module and you have no idea in it, you just use it. So to know the type you should find where the variable is declared. It can be global, it can be member of class or just local to the function. Using your method, you can't do that without searching for definition, which can take a lot of time, or maybe you should go to that programmer who did the module and ask him? I would fire you for disturbing people by asking such questions lol, or maybe that programmer who has no idea in HN, depends on situation.
I tested that on my own skin, we had some people who liked to call their variables like database_connection . Yeah it says what is that, but what type? ADO Connection object? MFC connection? Just a connection string? And is this a pointer?
Philip Patrick
Web-site: www.stpworks.com
"Two beer or not two beer?" Shakesbeer
|
|
|
|
|
Philip Patrick wrote:
Well, noone talking about lpszText , but about lpszAppPath , which tells you type AND what this variable for.
Okay, I'm probably not playing fair by changing examples in mid-stream; I should've used lpszText from the start.
Still, I'd much rather search for the definition (more on that in a second) than trip over the semantics of a line of code by trudging through all the Hungarian junque. For me, the understandability of the code decreases exponentially as I see more "lpsz" garbage.
Numerous people have noted that searching for a definition can be tedious. I disagree; it won't be tedious IF the project is organized well, not just in terms of classes or a single file, but also in terms of what goes into what files. An undecorated name is either an argument to the current function/method, in the class or a superclass thereof, or a global . (No, I'm not trying to claim that globals are good, nor am I condemning them. Completely different subject.) That makes 3 places to look, and that's it. More often than not, I'll need that file anyhow, for comments relating to the variable (when necessary), or other information that won't come from Hungarian Notation anyhow.
|
|
|
|
|
Totally right, the format enhances transparency.
Only well formatted and commentented code enables to work other programmers than the original coder on the source.
AND: in well formatted code experienced programmers see the quality or bugs at first side.
|
|
|
|
|
All code must go through a development/debug/maintenance cycle.
Right.
In the land of Oz. I've preached that to various companies (like Robot Research, eventually bought by Sensormatic), or like Integration Partners, when I worked for them. Management barely understand why a debug cycle is necessary ("can't you just program it without bugs???") and I've never been able to convince any manager that a product needs to be funded for the maintenance cycle, let alone a phase-out cycle.
I'm sick of it all, which is why I'm a consultant now. And I'm sick of it enough that I'm naming the bozo places I used to work for, otherwise, there will never be accountability.
As far as style goes, other than getting the naming convention right, it's cheaper to buy a code formatter than to get two people, let alone 10 or 20, to agree on style.
Marc
|
|
|
|
|
Poor programmers usually suck at both code formatting and code performance.
If you see a bad looking code you can be sure it will give you a headache.
|
|
|
|
|
George wrote:
Poor programmers usually suck at both code formatting and code performance.
It depends!
I like to indent a la MS-stlye, I use a lot of blank lines to separate program functionality etc. I hate Java-formatting style
However I have collegues that do not use blank lines, use Java-indentation etc. But, their code is good, just does not look nice to me.
Best regards,
Alexandru Savescu
|
|
|
|
|
Alexpro wrote:
It depends!
Of course!
Alexpro wrote:
However I have collegues that do not use blank lines, use Java-indentation etc. But, their code is good, just does not look nice to me.
Well, I am not talking about Java-style vs MS-Style. I am rather talking about having and not having a style. Some people really can make a code look unreadable, because they don't format it at all.
|
|
|
|
|
bla bla bla whaterver dude bla bla bla
|
|
|
|
|
I guess you are a spew coder then?
Tim Smith
"Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution."
Hoare - 1980 ACM Turing Award Lecture
|
|
|
|
|
I agree with that statement.
I think its a matter of pride. I want it to look good and work good.
If my seniors and principles look at my code or go through a code review and it looks like garbage and confusing then i did not do my job!
My job is to write clear and concise code that works according to spec.
mike
Mike "Badvox"
|
|
|
|
|
You obviously have never programmed in assembly where all code looks like meeningless sh*t
|
|
|
|
|
It does?
When doing assembler you just have to be even MORE carefull about formatting and clarifications, otherwise you will most likely end up with a thousand lines of unusable garbage.
I have seen asm code that was just one step from C, and other code that was a pile of s**t, mnemonics and numbers.
"After all it's just text at the end of the day. - Colin Davies
|
|
|
|
|
George wrote:
Poor programmers usually suck at both code formatting and code performance.
I could out indent and out format you into the next solar system. Why? From my HTML work I have learnt to format like the devil. It means a lot in HTML.
But no way in hell I could out programme you in C++.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
The greatest thing you'll ever learn is just to love, and to be loved in return - Moulin Rouge
Alison Pentland wrote:
I now have an image of you in front of the mirror in the morning, wearing your knickers, socks and shoes trying to decided if they match!
|
|
|
|
|
I am a zealot for coding standards, but no-one in their right mind can say that formatting is equally important to performance, I mean, which does the user *see* ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
That depends on what you are looking at.
If you are looking at the here and now then by all means current performance means everything.
But if you look at the lifetime of an application the extra time it takes to maintain the poorly formatted code could add a lot more time than the few extra cycles you save by using a particular way of doing things.
Personally I go for readability, as you could tell from my stance on casting etc Then again 90% of what I have written are database applications where communicating with the server takes far longer than saving a few cycles will be worth.
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
But if you look at the lifetime of an application the extra time it takes to maintain the poorly formatted code could add a lot more time than the few extra cycles you save by using a particular way of doing things.
I think you missed my point.
James T. Johnson wrote:
If you are looking at the here and now then by all means current performance means everything.
Current performance IS everything. But to be honest, what I was trying to say is that I do not see the dichotomy, but if I had to choose, performance is the winner.
James T. Johnson wrote:
Personally I go for readability, as you could tell from my stance on casting etc
I hope you're being ironic.... A major reason I hate all that casting is that C# is hard to read at times because it's too verbose.
Overall my point ( obviously poorly made ) is that there is no dichotomy but if a false one is to be imposed by the poll, then performance is obviously number one, although I think performance is likely to *improve* if the code is well formatted, because it's easier for people to go back and change other peoples code to make improvements if it is easy to read.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
I think you missed my point.
Probably
Christian Graus wrote:
I hope you're being ironic.... A major reason I hate all that casting is that C# is hard to read at times because it's too verbose.
I don't find it that hard to read; but it depends on how you are doing it.
If I have to cast, I prefer to store the result in a variable so I don't have to cast again.
I also prefer to have only one or two member access per line.
Not my style
((BarRow) ((Foo) fooCollection[4]).Rows[3]).Baz();
My style
Foo foo = (Foo) fooCollection[4];<br />
BarRow barRow = (BarRow) foo.Rows[3];<br />
<br />
barRow.Baz();
Which I think is the kind of formatting vs performance that the survey was asking about. Here a few cycles are wasted because it stores the results of each line in a variable; only to be used once.
I would think that a good optimizing compiler would see that this is the case so it would compile down to the better version; but I've seen weird bugs with the VC6 optimizer (a simple 'center in window' type function was messed up).
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
Christian Graus wrote:
Current performance IS everything
Well, let's see. If you have function refreshing the window which takes 1e-6 seconds, how much time (max) would you like to spent to improve the performance 10 times?
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection - Protection from what? Zee Germans?
|
|
|
|
|
Tomasz Sowinski wrote:
Well, let's see. If you have function refreshing the window which takes 1e-6 seconds, how much time (max) would you like to spent to improve the performance 10 times?
It doesn't matter what I say, does it ?
As I said before, in the false dichotomy between pretty code and performance, performance is more important. That does not mean we need to keep optimising when performance is perfectly acceptable.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Performance is always less important with modern computers.What is more important is that it doesen't crash!
|
|
|
|
|
I'm agree with you. If the app don't work well, really isn't important how fast it crash.
------------------------------------------------------
May be you think "He's crazy", but i'm not the only one.
|
|
|
|
|
Christian Graus wrote:
A major reason I hate all that casting is that C# is hard to read at times because it's too verbose.
Good God, somebody finally admitted it! And all that casting must be typed as well!
MK
|
|
|
|
|
In actual fact, Eric Gunnerson from Microsoft recently admitted on the C# board that even the C# team thinks you need to cast too much.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
|
|
|
|
|