|
..but maybe its extensible in that the way that you can add classes and objects to the project... but the internal messaging is so screwed up... it's not maintainable and takes a lot of figuring out and experimentation to get it to work.
 )
|
|
|
|
|
See my thread titled "Some inter-relationships" above. To express it precisely, extensibility implies maintainability but not vice-versa. In other words if it's not maintainable then i twon't be reliably extensible.
Kevin
|
|
|
|
|
What about the reverse?
Maintainable is also extensible.
And what about some other possible views?
Maintainable is also being easily readable by others.
Maintainable also means it is easier to fix bugs..
|
|
|
|
|
I disagree. It might be a complete mess, and yet it might be clear that you just have to copy a chunk of mess and tweak it to add a new feature.
On the other hand, if it's easily maintainable then it's easily extensible.
|
|
|
|
|
Stupid users are incredibly good at finding bugs 
|
|
|
|
|
I think that extensible is maintanable, but not the reverse.
First, I don't agree that multiplying the existing bugs procedure to add new feature makes the product extensible - said so, it turns that each product is **somewhow** extensible, wich deteriorates the term.
In the same time we can call each product maintanable - i.e. it could be maintaned, **somehow**.
So we call a code, maitanable if it takes a relatively small amount of time to keep it running and extensible if it takes a relatively small amount of time to keep the product growing.
And since a growing product has to be running, but the reverse cannot be said - a product can be well-running and still adding a new feature could be close to impossible - this leads to a conclusio states at the beginning.
|
|
|
|
|
...modular = more extensible and more bugfree, so I work towards that as much as possible.
|
|
|
|
|
I have done bug fixing of well known software for years. Bugs are inevitable. Important is that how quickly we can detect and fix it. More experience you are less the chance of occurrence of common bugs. Practically it's impossible to simulate all possible problems at the time of writing. It's applicable to all programmers. Here maintenance issue commes into picture. It's very painful to detect a simple bug if the code is not organized and even more painful to fix it completely without any regression. No body can fell necessity of maintenance if code size is small. Once source code size exceeds 100MB fix of a bug leaves more bugs in product. I have the sweet/sour test of fixing bugs in 400+MB source code.
Partha K Chakraborti
|
|
|
|
|
I agree! In the passed I've inherited some large and maintenance unfriendly projects (in C). One required that if you made a change in one of three arrays you had to make changes to the other two, which where in different files. I combined them into one large array and provided a set of functions to access the data. In that way when a new feature had to be added, I only had to go to one place to make the changes. All the functions, that used to have direct knowledge of there respective arrays, no longer needed to have that knowledge, to function without change. The result: code that could be modified in 15-20 minutes, as opposed to hours.
INTP
|
|
|
|
|
|
one of the other
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
Thats was me
If you vote me down, my score will only get lower
|
|
|
|
|
So you are the one who keeps answering CListCtrl 
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
Mr.Prakash wrote:
So you are the one who keeps answering CListCtrl
Nope. I am the one who replies without a CListCtrl!
Also, you will see that 3 people did put CListCtrl 
If you vote me down, my score will only get lower
|
|
|
|
|
Roger Allen wrote:
Nope. I am the one who replies without a CListCtrl!
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
bug free is a stupid option, no one intends to write a buggy application, it all depends on the skill of the progrrammer wheather he is able to produce bug free application...
A programmer can not aim for fast code with bugs!!!
I vodet for code that uses least resources, as i have been programming since 8086 machines, writing TSR software that leaves very less footprint in the 1mb memory has taught me to write least resource consuming apps and free up memory when not required.
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
I agree.
What is "a bug free" program? If we write a complex application, nobody(not even Microsoft) has the resource to test for all possible test values, hence it is highly unlikely we have a bug free program.
I am glad that the poll shows that maintable code is number 1 choice, otherwise I would be worried.
|
|
|
|
|
Mr.Prakash wrote:
it all depends on the skill of the progrrammer wheather he is able to produce bug free application...
Yep, I'm sick of seeing people blame bugs on everything but human capability.
Regardz
Colin J Davies
Attention: It's finally arrived, The worlds first DSP.
|
|
|
|
|
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.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
