|
Thanks!
-=- James
Tip for SUV winter driving survival: "Professional Driver on Closed Course" does not mean "your Dumb Ass on a Public Road"! Articles -- Products: Delete FXP Files & Check Favorites
|
|
|
|
|
Most often I hear "Wow - this thing is really broken"
cheers,
Chris Maunder
Remember that a lone amateur built the Ark. A large group of professionals built the Titanic.
|
|
|
|
|
Is there a real product out there that is completely devoid of bugs? Bug-free code only exist's in Walgreen's fictional city called "Perfect".
Maintainable code is well... maintainable. When bugs are reported, the code is easy to modify. Maintainable code should (in theory anyway) be easier to extend as well, and easier for other people to read. Unless you are looking for optimizations (fastest code or code that uses the least resources), maintainable code seems (to me anyway) the most logical goal.
|
|
|
|
|
we don't talk about "perfect" bug-free ...
i think the good IDE would prevent user from making bugs ...
agree ?
|
|
|
|
|
No, not by a longshot.
I can just see the IDE trying to figure out if you really wanted "2*r*3.14159" or "r*r*3.14159".
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I said "All of the above -- writing CORRECT code." That pretty much encapsulates all of the provided options.
When writing code, above all it must solve the need in design behind the code and follow the stated options, in other words, it should be correct. Each developer may come up with equally valid and correct code. Elegance is nice, but that can be sacrificed for optimization, robustness and extensibility. Measure twice and cut once [Design], play well with your environment, always have an error strategy, and above all have fun :P
Ian Mariano - Bliki | Blog
"We are all wave equations in the information matrix of the universe" - me
|
|
|
|
|
IMO, the only possible answer is 'bug-free code', since that phrase encompasses the other attributes listed.
Software Zen: delete this;
|
|
|
|
|
Bug-free code? What's that?
I actually wrote in, "Code that people will buy". You know, you can invent the greatest, bug free, most maintainable code in the world, but if nobody wants it, what good is it?
"Fish and guests stink in three days." - Benjamin Franlkin
|
|
|
|
|
That is in fact the most crucial requirement for a success or failure of a project. However, it should by right be done before coding phase like system study and survey.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
I disagree.
I selected "Code that can be understood by others" figuring if there were bugs, or it was too slow, or it had to be extended, or nearly anything else, that could be done by someone else if necessary.
|
|
|
|
|
Goes hand in hand with maintainable.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I disagree.
Bug free != efficient, fast or easy to maintain. Sure, you can put those attributes in the requirments doc, but if they aren't satisfied are they bugs or merely unimplemented features?
cheers,
Chris Maunder
Remember that a lone amateur built the Ark. A large group of professionals built the Titanic.
|
|
|
|
|
I'll weasel a little here based on wording. I was interpreting the phrase 'bug-free' as being equivalent to 'defect-free'. In the corporate culture where I work[^], defect-free encompasses extensibility, maintainability, understandability, performance, and resource efficiency.
An application that doesn't meet at least 'acceptable' levels in all of these areas will fail to meet the end user's requirements or expectations in some way. For our production-oriented customers (a surly lot), failing to meet their needs/wants/vulgar fantasies is Not A Good Thing.
Software Zen: delete this;
|
|
|
|