|
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!
|
|
|
|
|
diaphanein wrote:
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.
Yep! Practice does not make perfect, it makes habit. Practice doing the right things leads to a habit of doing things "the right way".
diaphanein wrote:
Just because we have fast hardware, doesn't mean the coder should use it as an excuse to be lazy and write poor code.
I could not agree more!
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
|
|
|
|
|
It is really a matter of concrete applications. If you develop software for internal use, buying better hardware can sometimes be more cost effective than investing into high-performant software.
On the other hand, if you are selling software on the market, performance is important.
|
|
|
|
|
Writing a resurce-efficient ofcourse. I mean what if you have a bugless code but there is no computer which has the resources to use that program then what good does your program do? Nothing.
|
|
|
|
|
Well, if no computer has the resources to run the program, how did the programmer test it?
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
You missed my point. No matter how bugless your program is there is no point if only a supercomputer is needed to run it. Like if we had pc:s like 200mhz pentiums and you shoud run the Longhorn in it. What is the point in it?
|
|
|
|
|
I don't understand what you are trying to say.
Mordok wrote:
Like if we had pc:s like 200mhz pentiums and you shoud run the Longhorn in it. What is the point in it?
Ummm.... I don't think a 500Mhz P2 could run Longhorn, let alone a 200Mhz Pentium.
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
It appears so. It was a symbolic language. The better code is the one that is simpler, less resource using if you compare two codes.
For example if you have a code that has few bugs but a memory usage of few megs and cpu usage only few percents. The other uses cpu 100% because dum desing and complexity but has no bugs. Whichone is better? You can use both but the other works better due to its simplicity, youknow the bugs always can be fixed and there is no such thin as bugless code if you do huge programs.
Another example. Let's assume that there is no bug's in Longhorn, but there are bugs in XP.
Like in this situation you sayed your self:
"Ummm.... I don't think a 500Mhz P2 could run Longhorn, let alone a 200Mhz Pentium."
XP uses less resources hence you can use these same resouces in somewhere else. Now if I use Longhorn and it takes all my resources to have it work what use it is for me? I can't do anything, although there in no bugs. But in XP I can.
I didn't assume that Longhorn would work in 200Mhz cpu.I don't assume it will work decently with my athlon either.
Do you see my point? First do it as simle and as efficient as you can. That it self remowes the bugs that comes from useless complexity. Then you have not as much bugs to fix.
Bugs are often revealed in testing, but you can't test it forever because your code doesn't then benefit anyone and you couldn't because you die in old age before it. Bugless program is a nice ideal but in large programs it's hard if not completely impossible to achieve. Then you'll come back to that resource efficient is a better thing.
ps. I HATE to write this long writings.
|
|
|
|
|
There is nearly no poll without at least one "CListCtrl"-vote.
Would you please be so nice to a clueless CP-newbie an tell me what's up with that CListCtrl... is it the visual implementation of 42, the answer to everything? 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
