Thanks,
CK

Pls get in toch if you have any doubts
Thanks,
Ashish Madan.

Stanley Garland

1: There are a great many problems for which there is no complete set of solutions and the goal must be to find the greatest possible subset of solutions and/or find maximal and minimal values (speaking somewhat metaphorically, though this can be literally true). Often code is presented as solving for all cases when in fact the programmer has adjusted the problem space from his viewpoint, and thus codes in a incorrectly, and arbitrarily, reduced solution space. The most common form of this is precluded by the thought process which goes something like “Well, in 99.9% of cases, we can ignore variable x”. Which is fine until variable x hits some resonant or asymptotic value and your solution is incorrect and, much more harmfully, presumed to be correct. As has been said above, it is vital to know where your code is lacking.

2: My first point is an additional reason why your first requirement, thorough domain knowledge is absolutely essential. As you may be able to tell from the above, I am a physics student and it very quickly becomes obvious that in my field there are those who can code, those who grasp abstract concepts well and those whose math skills are outstanding. Any 1 of those 3 can do well in physics, so entwined is programming with our field, but to approach Mozart, one must have all 3 in abundance. Needless to say, this is something almost never seen.

Like you say, software is maleable and I think there is value and strength in taking the time to say “I know this isn’t right, but it is least wrong, Perhaps the difference is semantics, I think it’s important none the less.

Perfect code would be more necessary for components that will be reused or maintained over time, or even components with such complexity that the initial development could benefit from careful design and implementation.

In a commercial project there is frequently the thought that some component ‘may’ be reused later, but the financial success of the current project will determine the future for subsequent projects. In the end, ‘good value’ code is more important than perfection. Perfection may get its chance to occur as a maturing process over time and open source can help commercial and noncommercial projects achieve this.

I’d also say that the ‘perfect code’ may have a very limited context. What is the ‘right’ way to solve a problem may not be the right way later, eg. optimal quick sort on single CPU vs multi core. And the problem itself may shift eg. goals and requirements for LOD system.

One final thought is that it is good practice to separate interface from implementation, allowing either to be tweaked or matured over time to obtain better value. At different points in time you may achieve a perfect interface or perfect implementation (for a given platform), bonus if you can get both together!

Still, I think the tenets you’ve raised are good goals for perfect code, though point 3 is subjective. The way you optimise a timing problem for a game is not necessarily the same way you would solve a timing problem for a safety switch. A game can have a timer resolution of a few tens of milliseconds while a safety switch must have a tighter resolution. Then again, it’s all based off the original problem anyway.

I’m curious to hear whether you think that test driven development (ie. Writing a test as the problem and then the code to solve that test with the ultimate goal of putting it all together as the overall solution) brings us closer to the ideal of perfect code, or whether it draws us away from it.

Using your criteria,

1. Solves a problem
2. Without bugs
3. In an optimal way

It is quite possible to have two pieces of code, one of which is more optimal than the other, (less lines of code, faster, easier to understand, cross-platform, generic etc..) and therefore more perfect.

I think that the above criteria specify nessesary, but not suffient conditions for perfect code.

But sometimes good code is good enough