[developer2]

>> How they can assume or think that two programmers going to solve the problem in "same" ... way!

It takes a lot of restraint and stepping back from being in "first-person developer mode" to understand that someone else's unique approach is quite likely valid. I purport to be able to do so but I still find it incredibly difficult to ignore my brain's initial instinct to start pointing out the supposed flaws in someone else's structure, when the simple fact is my own code for the same problem would probably be filled with the same holes - just in a different form.

Honestly, there are only a few metrics that really matter when it comes to quality code:

1. Does the code accomplish the task it's supposed to? I mean really, this is practically the only thing that really matters in most cases. Simply: if deployed, will it work?

2. Are there no glaring security problems with the implementation?

3. Does the code not excessively overuse resources (cpu, memory, network/system calls, etc.)? Real excess beyond what is reasonable, not micro-optimizing.

4. Is the code not a complete mess? No serial use of copy/paste, crazy spaghetti mess, or inability or blatant refusal to follow basic coding standards?

That's it. Deploy that shit, and move on to the next problem. ;)

[antoaravinth]

This is exactly what I was thinking! The points that were written is just as what I had in mind. But I guess still your missing one important point on testing. The code should work if deployed, but at the same time, we need to have through testing for the same.

I always start with reading test cases rather than source code directly. Thats the way it should be (IMHO).