So many ways to code one thing, deciding what's best?

Question

Have you ever been in a situation where you code something and then find yourself wondering if you did it the best way. So you end up coding another way, and then find yourself again asking if you could have done it better. How do you determine when it is time to stop and move on to the next problem so you can avoid going in circles?

Answer 1

Do the simplest thing that works.

Answer 2

Try Test-Driven Development. Write good tests upfront. When the implementation code passes the tests, you are done. Even if you are not happy with the implementation, you can go back and write another implementation and you will have the tests to ensure that it works correctly. At this point you could profile the various solutions.

Answer 3

Define "best".

If it's the way that is:

1. readable
2. good performance-wise
3. maintainable
4. respecting the time-schedule of the project

then that's the "best" way to code it.

Answer 4

Does the current implementation work (well enough)? If so, then put it to bed and work on something else.
I find that whenever I learn a new way of doing things, I'm tempted to rewrite lots of old code to use that technique, which would be a waste of time. Use what you learn for your new projects, and leave the old ones in peace.

Answer 5

If it works, is fast enough, is readable and maintainable, then it is time to move on otherwise you will never finish your project (or keep your job.) We could all spend forever refactoring code.

Answer 6

When someone else can read it right-off because I've both a) commented it well, and b) used "normal" operations to achieve my goals.

I will often want to leave as soon as it "works". But "is readable" is more important, after "works".

Answer 7

The only way to code something properly will only be based on your requirements. You have to make sure that you are not over-engineering your code.

Just make sure that your code is testable and that the complexity is kept to a minimum based on "reasons for change". If you deal primarily on an e-Commerce website as an example, you might want to have an extendable pricing solution. However, you don't want to make other parts of the system as extensigble as the pricing for the simple reason that they will have really few reasons to change. A good exemple would be the tax system. You might build it so that it only deal with USA in an efficient way and later refactor the code if the business change to deal with other countries.

Coding stuff too early that is not used is a sure way to code garbage that won't ever be used.

Answer 8

If it ain't broke, don't fix it. You don't need to continually rewrite your code. Once you have it working according to specifications (including performance requirements) you have to weigh the cost of rewriting it, and potentially introducing new bugs, against the cost of leaving it alone. Just make sure that when you decide you're done, it's well documented.

Answer 9

I really like asking myself whether the solution I've just created is really the best solution. And I doubt that there is a definite answer to that question.

Decision for a solution should simply be based on constraints (available time, design, maintainability) so you probably just have to ask yourself, whether the solution at hand satisfies your constraints.

But never stop asking yourself, as it's the driving motor to produce better solutions.

Answer 10

Best:

Fulfills the specification today, tomorrow, next week, and next year, whether you are maintaining it or not in those timeframes.

Answer 11

I question myself all the time. However, there is no purpose on re-implementing the same thing over and over again. If you think you did it wrong, but it works, accept your failure and move on. You have learned something for the future. Next time, next project, you'll do it better (always, as you'll hardly ever do it in a way one may call it perfect). The only reason to ever touch the (bad) code again is

• Someone else tries to work with your code, but fails because it's so horrible. Time to take over his work (you should know the code, you have written it) and in the process try to fix it, make it more obvious, add better documentation, better variable/function/method naming ("speaking names"), more comments, and so on.

• It works, but it's too slow or eats up too much RAM. Time to profile it! Where is CPU time spent? Why is so much memory used? Find the weakest spots and fix them.

• It turns out that it does not really work, it fails under certain conditions or in certain situations, again, time to fix your code.

However, keep the following saying in mind (changed to fit for programmers): "Programmers never do the same mistake again, they'll always find new ones!". How often have I said, next time I'll do it much better and sometimes I had the chance (e.g. new features needed to be added and the code was so horrible to adopt, rewriting it to work as desired by this new features from scratch turned out to be faster than changing the old one) and of course, I never made the same mistake twice; but next time you write the same piece of code again, you come up with new problems caused by your new (though much more clever) implementation that the old one didn't even have (therefor it had plenty of other problems). Getting to the point where you can really say "I can't do it any better, that's the best that can be done" is an experience I'm still waiting for. I wonder if there's any code on earth that cannot be further optimized in terms of simplicity, performance, or flexibility.

Also the hard truth, that most programmers don't like to hear, is "sometimes good is good enough". The code might not be perfect, it might have its deficits. You might be able to do better than that... but programming is not a competition who can create the best code ever, it's about getting things work (usually for a customer) and when I tell my boss "Hey, I can improve this code to use only half that much CPU time, one quarter of its memory and it'll be so flexible, adding new features will be a question of hours instead of weeks", he might say "No customer ever complained that it is too slow. No customer ever complained that it uses too much memory. And the way it works right now is exactly the way we wanted it to work, so why would we add new features to something that works exactly like all our customers desire?". And he has a point there. If no product was allowed to ever hit the market, unless you could consider it 100% flawless, I guess the shelves in most stores would be rather empty.

Answer 12

best != perfect. perfect code probably isn't possible for mere mortal coders. good code is written to enable future maintenance. you won't get it perfect the first time.

Answer 13

Granted, you're not asking about Perl, but I think this applies to most languages in most situations, even if it's not an explicit design intention:

Perl is designed to give you several ways to do anything, so consider picking the most readable one.

-- Larry Wall in the perl man page

Answer 14

Sounds like yet another reason why version control is so important. Refactor and improve code as much as you wish, wherever you see need for improvement, but keep checking it in and commenting on every change. The log, plus peer pressure, should help you understand where you have been obsessive compulsive for no obvious reason, and where you have been improving the code base in a meaningful manner.