|
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 )
|
|
|
|
|
Why should we care about users?
Let's kill them all and just code for coders!
- - - - - - - - - - - - - - - - - -
Memory leaks is the price we pay \0
01234567890123456789012345678901234
|
|
|
|
|
It's not about the user; it's an issue of life-cycle cost. I've probably maintained as much code as I've designed, and have wasted many manhours of precious time slogging through perfectly functional, but very ugly code. There may be programs that are written once and delivered, without anyone ever having to revisit them. But I'll bet they're rare. And the poor sap who has to implement the changes required over time is almost never the same programmer that wrote the original.
On a related note, those who do program maintenance need to be very clear in documenting the changes made, and the reasons for the changes, for the next guy in the maintenance queue. It's not strictly necessary that maintainers retain the original style, but it helps!
<marquee>"Knock, knock." "Who's there?" "Recursion." "Recursion who?" "Knock, knock..."
|
|
|
|
|
I agree with you 100% on all fronts. My point really was that there is no dichotomy, the idea that we could spend the time we spend making the code pretty improving performance is plain wrong. I was really trying to say that I had to choose performance over pretty code in the poll, but that the question itself is flawed.
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 )
|
|
|
|
|
|
Christian Graus wrote:
I mean, which does the user *see*?
The user "sees" the result of the work that in continually done in and on the code. The quality of the work done might just reflect how it was written in the first place.
If you were tasked to make a bug fix to some code, which code do you believe you would do better on? (you cannot reformat any of the code before working on it of course, because that would imply the importance of formatting...)
<br />
std::vector<SomeObj*>::iterator i=m_vecObj.begin();<br />
std::vector<SomeObj*>::iterator e=m_vecObj.end();<br />
while( i!=e ){ for(DWORD a=0;a<*i->m_dwLimit;a++) SomeFunc(*i); i++; }<br />
<br />
typedef std::vector<SomeObj*> VectSomeObj;
typedef VectSomeObj::iterator VectSomeObjIter;
<br />
VectSomeObjIter iterObj = m_vecObj.begin();
VectSomeObjIter iterEnd = m_vecObj.end();
<br />
while( iterObj != iterEnd )
{<br />
DWORD dwCallLimit = (*iterObj) -> m_dwLimit;
<br />
for( DWORD dwCall = 0; dwCall < dwCallLimit; dwCall++ )
{<br />
SomeFunc( *iterObj );
}<br />
++iterObj;
}<br />
I believe that most developers would choose Example 2 over Example 1. Wonder why? If someone cannot understand the code that they have to make changes to, what the user is going to "see" are crashes and other problems. And since code tends to "live" a lot longer than we would like, welcome to the reality of Software Development.
Besides: how many times have you (or anyone else reading this, for that matter) went back to some 6 month, 1 year, 2 year, or 5 year old code and wondered what the hell it was trying to do? Well, if you write code like Example 2, that is less likely to ever happen again (at least, it is for me).
Peace!
-=- James.
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.4 Now!]
|
|
|
|
|
I think I need to go and do a basic English class. It appears no-one understood what I was trying to say.
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 )
|
|
|
|
|
Christian Graus wrote:
It appears no-one understood what I was trying to say.
Hmmm...
>> but no-one in their right mind can say that formatting is
>> equally important to performance, I mean, which does the user *see*
Reads like proper English to me...  Now, if what you wrote was not what you meant... 
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.4 Now!]
|
|
|
|
|
Sure thats true the customer may never see the code.
What about if you are a consultant and you or your company distribute the source code along with the release build?
What then?
The customer reviews it and then swiftly fires you!!
Or you are at work and the people that have to fix your bugs go through your code. They cant read a single line because it sucks so bad and then they come find you to lynch your ass.
Mike
Mike "Badvox"
|
|
|
|
|
Would someone just shoot me please ?How many times on this damn thread do I need again to point out that I am NOT saying that code layout does not matter, I am saying that I think the question is flawed, but if there WAS a dichotomy then you'd have to choose performance. There isn't, both are important, and you'll note the title of my post was 'I am a zealot'. I AM fanatical about code formatting, I don't think it has anything to do with performance in terms of being an either/or choice, but if it WAS in some wierd parallel universe, then you'd have to choose performance.
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 )
|
|
|
|
|
Writing complete and thorough documentation, with long, descriptive variable names and a well thought out class structure is vital to code that is expected to live a while, but for proof-of-concept work often it just gets in the way. The longer it's going to be around, the better it should be written...
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
Shog9 wrote:
Writing complete and thorough documentation
Doesnt work for two reasons.
1) It usually gets out of date pretty quickly. Now you're going to tell me it should be kept up to date. Maybe, but there are a lot of reasons that it isnt, the number one reason being time pressure.
2) No one really reads it anyway. Maybe thats because it isnt accurate, but it's more likely because programmers can find out what the code does by reading the code, and feel more comfortable there.
I've come to an epiphany lately that documentation should not describe how a class works, but rather what it does and why it exists. What and why does not get out of date as quickly as how.
Shog9 wrote:
with long, descriptive variable names
Just descriptive ones will do me. Of course if they need to be long to be descriptive then they should be.
Shog9 wrote:
a well thought out class structure
Simplicity is paramount. A small class is good to, if possible.
Shog9 wrote:
The longer it's going to be around, the better it should be written
True, but there's no reason why code shouldnt be well written no matter what it's reason for being. A lot of prototypes have become full blown projects, and the existing, crappy code has been retained.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
