|
I personally find it more efficient to just get the bug-free code out of the way first. In my case, this would be a class or certain functions hacked together -- certainly not very pretty to look at.
But after the class has been tested, I rewrite it in a more elegant, understandable fashion. This includes changing the comments to be somewhat more descriptive of what's actually going on. Often when it's rewritten in this easier-to-understand fashion, it's easier to optimize for speed or footprint. 
|
|
|
|
|
Vega02 wrote:
But after the class has been tested, I rewrite it in a more elegant, understandable fashion.
Why rewrite something that works and have been tested?  You'll just have to retest it again.. it certainly doesn't sound like a more efficient way as opposed to writing "pretty" code from the beginning.
--
Ich bin Joachim von Hassel, und ich bin Pilot der Bundeswehr.
Welle: Erdball - F104-G Starfighter
|
|
|
|
|
There's an argument for doing a quick 'spike' implementation not following the usual standards of error checking, coding, etc, in order to check whether an approach works.
I'm incapable of doing this: I always end up doing a real implementation, even for a spike.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
It takes considerably longer (in my opinion) to do it that way instead of making it ugly but bug-free the first time. If a file can be made functional - though not optimized or understandable - quickly, then other developers can immediately take that and begin using it in code. In this manner, you can continue to optimize the original file for later inclusion while simultaneously giving others access to its functionality so that they can test their own components.
Also, retesting something like this isn't as hard as it may seem. Remember that functional code is already there and fresh on your mind. All a developer has to do is clean it up a bit and perhaps add safety checks, i.e. try-catch statements.
But as you said, Jörgen, writing pretty code from the beginning is always preferable.  If a coder can pull this off, I tip my hat to him, but this is a feat I've rarely seen accomplished. This isn't to say that we shouldn't follow good programming practices, though, like documenting functions and their parameters from the get-go.
Thanks for your reply!
|
|
|
|
|
if a function has a well defined interface;this comes in, this comes out, then rewriting it to acctualy make the code more understandable or faster or whatever, makes sence. For the user it should make no difference. Though it is not always so. Calling external resources that may introduce new errors.... etc etc
my two cents
Gupta Team Developer 3.1
VC++ 2003
Oracle 8i
W2K-XP
|
|
|
|
|
This is also definitely an error source. Function A written and tested, programmer tidies it up.
As it was only some cosmetic changes, no proper retesting. BANG - ugly bug.
I've seen it far too many times (and even done it myself  ).
|
|
|
|
|
Bug free? Are you kidding?! Thats almost impossible. 
If you write code that is maintainable, as you discover bugs, you can fix them easily. Some aspects of maintainable code are readability, well thought out, organized, and effecient. Each of these contribute to maintainability.  Funny, but it looks like these cover almost all the other options except maybe speed. 
If you learn to write maintainable code from the get-go, you don't have to ever re-write.  Instead, you maintain the code. (Some of us call this refactoring.)
|
|
|
|
|
Elegance is my #1 goal, but it doesn't correspond precisely with any of the items on the list.
I'm not interested in readable code if it's not elegant. Contrast with brute force methods which are very easy to understand, and possibly are bug-free as well. But they are not elegant.
Elegance almost always brings maintainablity, extensibility, readability, and speed, but these are side-effects, not the goal.
|
|
|
|
|
What exactly are you meaning by elegant?
|
|
|
|
|
>What exactly are you meaning by elegant?
Hard to describe exactly, but it's the opposite of 'clumsy', or 'quick and dirty'.
It's code where anyone that reads it will look at it and say 'nice!' There's something intellectually satisfying about elegant code. It achieves a lot in a few lines of code.
How much of my code is actually like that? Not much. But it's still the goal. Every time I refactor my code, I'm trying it make it more elegant.
|
|
|
|
|
yeah .. bug free then elegant is my style too, so no shame to the customer .. right ?
Hell demands contribution and Prime will deliver it
Not bad eh ....
<marquee scrollamount="2" scrolldelay="50" align="middle" behavior="alternate">-=[ Prime ]=-
|
|
|
|
|
It seems a bit odd that a goal which is almost universally regarded as being practically impossible for non-trival applications (Writing Bug-Free Code - currently at 27.05%) is number two on this survey.
Shoot for the sky, I suppose...
Charlie
if(!curlies){ return; }
|
|
|
|
|
I can write bug free code!
Sub New()
End
Exit Sub
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
Yep. That certainly qualifies as non-trivial. 
Charlie
if(!curlies){ return; }
|
|
|
|
|
Hm, it won't compile in MSVC++ 6.0
|
|
|
|
|
By the way, your signature produces bug-free code but I think it's more maintainable this way:
if (!curlies)
return;
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
I opted for extensibility in this case. I spent two extra keystrokes on the infrastructure so it'd be easier to add statements later.
Charlie
if(!curlies){ return; }
|
|
|
|
|
Yes, but anyway you'll have to then change your code to:
if(!curlies)
{
...
return;
}
Unless you want to keep it all in one line.  And that was my main point, from a debugging stand-point (maintainability), it's better to put if statements in 2 or more lines... although I think some of today's debuggers highlight the instruction to be executed rather than just the line they're on.
Also, I like the space between the if and the opening parenthesis since it helps to distinguish it from a regular method (for better maintainability).
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
It needs to work, therefore be bug free. Number two it needs to be easy to maintain and read in case it is ever useful or used by someone else.
Those are my points and my reasons for my choice. 
C++ - Pure, Simple, Makes Sense.
C# - Microsoft's idea of Pure and Simple
|
|
|
|
|
Bugs are a thing that is very common when writing code, so I think number two is indeed the best option to choose first. If your code is easily maintained, you can fix the bugs fast and optimize it easily too.
"Every rule in a world of bits and bytes can be bend or eventually be broken"
|
|
|
|
|
Not only that, it will also be easily extended. And - in response to user feedback - it stands a chance of being a usable piece of software sooner or later
|
|
|
|
|
diilbert wrote:
It needs to work, therefore be bug free.
Experience has taught me, that working software and bug free software aren't the same thing. Bug free real-world software is impossible, unless you have a rather narrow definition of what a bug is.
Michael
CP Blog [^]
|
|
|
|
|
I suppose there will never be a bug free product. It just depends on how you look at it. I look at bugs as something an average user will come across when using the software. If the average user finds a problem the software is not working the way it should.
C++ - Pure, Simple, Makes Sense.
C# - Microsoft's idea of Pure and Simple
|
|
|
|
|
diilbert wrote:
C++ - Pure, Simple, Makes Sense.
C# - Microsoft's idea of Pure and Simple
 I like your signature, but in all fairness, C++ is not exactly pure, and is anything but simple.
|
|
|
|
|
Nemanja Trifunovic wrote:
C++ is not exactly pure
class C {
C operator++(int) = 0;
};How about now? 
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
