|
|
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.
|
|
|
|
|
Mr Morden wrote:
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.
I agree 100%. Except in cases where the code represents an unfamiliar algorithm, i tend to mistrust "how" documentation even when it exists. "Why" documentation can be vital however, especially after the code has been left to rot for a while...
Mr Morden wrote:
A lot of prototypes have become full blown projects, and the existing, crappy code has been retained.
Sadly, this is true. But one of the primary advantages of a prototype is to prove a concept or test an interface without committing the time to it that the full-blown project will require; not to say you should write *bad* code in this situation, but merely that it isn't the priority. IMHO, this is one of the best arguments in favor of using tools to build the prototype that cannot (or will not) be used to build the final application (i.e., using VB/C#/HTML for prototyping, C++ for the project).
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
That is my sentiment exactly.
I also believe that the context in which the application will perform also makes a difference. The way that a redering loop is formatted in a game or a ray-tracing loop is very important for performance. I am willing to give up a little bit of readablility in order to squeeze out a few extra frames-per-second.
However, if you are dealing with a windows user-interface, speed is not as important. I would much rather have a cleaner formatted code to work with.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
