|
The wait is over... some are born with money, some just don't give a f about anything, and some marry young and rich. I('ve) know(n) the 2 first stereotypes. I'm trying really hard to fulfull the last to 50%. 
--
Ich bin Joachim von Hassel, und ich bin Pilot der Bundeswehr.
Welle: Erdball - F104-G Starfighter
|
|
|
|
|
Yup
and CP helps me achieve that (tons of fine code here)
so CP helps me make more money  its more powerfull than i thought 
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
|
|
|
|
|
is like asking, who would you rather loose, your mom or your dad?
...but, if i had to answer the question, the OBVIOUS answer is bug-free code. The single most important thing about code is, whether or not it works. Yes, we can all appriciate a well-designed, well-coded Types... but if the mofo doesn't do what it's suppose to, then who the hell cares?!
|
|
|
|
|
I disagree.
Take this case:
You have a good application, "that does the job". Almost. As a matter of fact,
measurement would show that the top 95% features are working perfectly, but
that there might be a bug in some of the bottom 5% of the feature set.
(This, by the way, IMHO, almost an industry standard. Do you thing that
MS Word ships when there is 0% bug ? Haha. I think not!;P)
Given a program that is easy to maintain, its easy to fix the bug.
As a matter of fact, for a small shop like where I work, its the only way
to know of the bug! I test my stuff all the time, but some of the features
are not used or almost never used. Its cheaper to have me work on newer
features that will generate sales and bring money in that spending eons
looking for bugs in features that we almost never use. Don't get me wrong,
those feature that are no longer being used a lot were tested a long time
ago, when they were written. But sometimes, well, I like to say that, like
our in our universe, where a pair of electron and positron gets created
simultaneously, a feature and a bug gets created simultaneously by me,
from time to time.
That is not to say that I make a lot of bugs. Its just for the sake of argument:
I'd rather be able to fix it because its so well written and obvious that it
makes one happy to be happy to see and fix a bug than spending 1,000,000,000
years testing an application. (Note that a large application may end up with
a lot of features)
|
|
|
|
|
good point.. hence why I said "stupid question". for this to be a valid arguement, more information would be necessary. We can argue endlessly maintainability against working code.
(but i rather have working code... i usually present the application to my clients, not the code... if the sh*t doesn't work, they could care less how modular the code is)
|
|
|
|
|
hehe... consider this, you need to present beta-1 of your code tomorrow 9am... which would you rather have? working code? or maintainable code?
I guess it's a consultant thing...
besides, if the code is harder to maintain, that just means more billable hours.  NOT THAT I'M A CODE-PIG BTW! I love granularity.
|
|
|
|
|
I find that "billable hour" are not billable. 
It seems to me that nowadays, billable products or features are the way to go. I honestly evaluate how long something is going to take, and my bill goes with my evaluation.
|
|
|
|
|
My choice is: Writing code that can be understood by others
If it can be understood by others then it's been written in a clear enough manner that maintainability should be no problem. Chances are that this will also enable extensibility (though not necesarily). If it's easy to understand then it will be easy to find the places where optimisations (speed/resources) can be performed, and more importantly it will mean that you can get others with better skills than you to do some of the work. We're not all good at all things. And finally, easy to understand will mean it's easy to trace and debug, meaning the inevitable bugs will be easier to fix.
I'd like to say I write fast, efficient, bug-free code but I know that's a lie. I try to write code that makes sense, is easy to reuse, sensibly commented and structured enough so that others can work within my framework without breaking anything or being forced to use work arounds. All the rest should, given available time and resources, follow.
cheers,
Chris Maunder
Remember that a lone amateur built the Ark. A large group of professionals built the Titanic.
|
|
|
|
|
Well Chris, I think your opinion is worth a little more than two cents.
Chris Maunder wrote:
I'd like to say I write fast, efficient, bug-free code but I know that's a lie.
At lest you are honest.
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
My answer was also 'Code that could be understood' and spookily for very similiar reasons.
Must have something to do with teamwork!
Kevin.
|
|
|
|
|
Chris Maunder wrote:
My choice is: Writing code that can be understood by others
Great man thinks alike.
<font=arial>Weiye Chen
When pursuing your dreams, don't forget to enjoy your life...
|
|
|
|
|
Especially when they are schizophrenic...
>Great man thinks alike
regards,
Paul Watson
Bluegrass
South Africa
Ian Darling wrote:
"and our loonies usually end up doing things like Monty Python."
Crikey! ain't life grand?
|
|
|
|
|
Chris Maunder wrote:
My choice is: Writing code that can be understood by others
As long as you don't write in Perl or COBOL, you should have no problem.
Regards,
Alvaro
Give a man a fish, he owes you one fish. Teach a man to fish, you give up your monopoly on fisheries.
|
|
|
|
|
Code that works -- since that's what my customer wants to see (and the customer is the one writing the check).
As far as readable, I used to have a prof who said, "If it was hard to write, it should be hard to read!"
--G
|
|
|
|
|
Glenn E. Lanier II wrote:
Code that works
Where's the job security in that?
cheers,
Chris Maunder
Remember that a lone amateur built the Ark. A large group of professionals built the Titanic.
|
|
|
|
|
I use to have a prof that would say,
"Gee. we must be stupid (the prof and I),
because you write code that I can read and understand,
just like I write code that you could read and understand."
You have to be a genious to read the code from this other guy.
Look at this paragraph here (shows me a piece of C++), its the same
as here and here and here. Looks like it as been pasted over
a dozen times.
Also look at those variable names. "sh*t" "f*ck" "tabarn*k",
what do they mean ?
Indeed, I am happy that you are a simple minded fellow, it makes
your code very easy to read and understand.
(of course, the prof meant that the other code was difficult to
read, requiring a genious to understand is not a sign of a program
written by a genious. its a sign of a bad job)
|
|
|
|
|
because IMHO it implies that it's then easily extensible and maintainable. And the latter implies that there are fewer bugs.
Regards
Thomas
Disclaimer:
Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
My thoughts exactly. If the code is not understood it will not be maintained well and as you say become buggy.
I do not mind getting old. It beats all the other options that can think of.
|
|
|
|
|
I would think that "EXTENSIBILITY" comes from design.
For example, I may have a "LOCKED DOWN" application where
a feature is not "EXTENSIBLE" for one reason or another.
(say I never expected to need expandability)
Still, I can always re-write it. Its not a shame to rewrite
a small feature when its requirement changes.
If I have an application that is expected to "change"
or to "expand" in one area or another, I spend additional
time to make sure that whatever feature in question is
indeed expandable.
For another feature, less likely to change or to be expanded,
I write the simplest, most easy to understand version possible.
This way, if it needs to be changed, anyone should be able to
take over from there.
At the begining of my career, I would spend huge amount of time
to write code that would be super easy to adapt to change. I was
wrong. I never forsaw the proper need to change. Instead, I added
overhead to a smallish application that changed its scope and forced
me to jump through extra hoops to get where I was going.
After a while, I figured out that "less is better". When I write a small
C++ class, I try to leave out any feature that are not 100% required.
Why spend time to work on a feature that will not be used ? Chances are
that I will not have time to test and debug the extra work. When I finally
think that I need the extra feature, It may turn out that I have to re-write
the original code anyway.
Belive me, less is better.
|
|
|
|
|
By that I mean "easy for me to maintain" since I'm the only person who has to maintain it.
That means:
- If there are any bugs I can find them and fix them.
- I can easily extend it.
- Others don't need to understand it (but that would be a bonus).
Fast and resource-efficient are much less important goals with modern hardware but my background (I'm really old ) has made such targets second-nature anyway.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Phil J Pearson wrote:
Fast and resource-efficient are much less important goals with modern hardware [...]
Oohhhh... Be careful with that argument; that is the Java argument many of us have been hearing for quite some time now... But people have been trying to improve Java's performance for years. 
Ever wonder why you would need to improve the performance of something? Well, I am sure that it is not because the performance was great in the first place...! 
-=- 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
|
|
|
|
|
This is a great point. Performance is a state of mind, a style almost. If you learn how to write code that is efficient, you can almost do it without thinking.
In .Net, there are some things that you can do that just need to become a force of habit. Things like not using an enumerator to iterate through arrays (have you looked at the IL generated when using a foreach on an array? ick.). Things like caching objects, caching collection counts (if you're sure they're not going to change) make a small, but in the longer term noticeable effect, especially if it saves you 4 calls inside of a tight loop.
Personally, I came into the software business from the hardware side of things. I see programmers excusing poor code as, "Well, the hardware is fast, so my code will be." Just because we have fast hardware, doesn't mean the coder should use it as an excuse to be lazy and write poor code.
|
|
|
|
|
While I agree that performance is important, it's not always reasonable to make extremely fast code until after you have the app up and running and know where your performance bottlenecks are. But that gets right back to easily maintainable code. When you get to the phase that you are doing performance benchmarking and have isolated the areas where you need to concentrate on, then the "maintainable code" will pay off because it will be easier to modify.
Ditto for bug-free code. While that is certainly desirable, all complex code will have bugs. If those bugs aren't caught until after the product ships, then it could be months if not years from the time you wrote the code to the time you get a bug report on it and have to go back to fix it. If it isn't easily maintainable, then that becomes a headache, and you spend a disproportionate amount of time figuring out what on earth you were doing -- instead of quickly fixing the bug and getting back to writing easily maintainable fast bug-free code...
|
|
|
|
|
Sorry, but it sounds like you (as many others here) are treating "Fast Code" and "Maintainable Code" as if they are mutually exclusive None of the options have to be mutually exclusive of each-other, that is simply how people choose to view it.
It is entirely possible to produce high-quality, maintainable, and well-performing code; you just have to foster the discipline to do so. Problem is, many of us, from the get-go, learn to do things the "it works" way, instead of the "it works well" way. For example, did your first Hello World! program use printf(...) or puts(...)? Ask yourself, which one is the better choice -- which one works and which one works well?
As far as going back to older code, it has been a loooooong time since I went back to older code and thought: "what the hell was I doing here?" I have since created a heavily-commented coding style that leaves no doubt (to me or to others). Again, a good habit, like commenting, leads to better quality code overall.
Peace!
-=- 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
|
|
|
|
|
Ralph Walden wrote:
But that gets right back to easily maintainable code. When you get to the phase that you are doing performance benchmarking and have isolated the areas where you need to concentrate on, then the "maintainable code" will pay off because it will be easier to modify.
Ditto for bug-free code. While that is certainly desirable, all complex code will have bugs. If those bugs aren't caught until after the product ships, then it could be months if not years from the time you wrote the code to the time you get a bug report on it and have to go back to fix it. If it isn't easily maintainable, then that becomes a headache, and you spend a disproportionate amount of time figuring out what on earth you were doing -- instead of quickly fixing the bug and getting back to writing easily maintainable fast bug-free code...
Spoken like a true veteran!
It takes a lot of experience to realize this simple
but universal truth!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
