A road named NoNameUno

The industry measures programs from different perspectives. Mainly a software design place would look at how best the specification and design have been implemented or realized, a quality assurance place would try to break the promise of a program using various means. And if a program is of any significant market impact,  standard bodies, reviewers, analysts, and others will test its guts out... They all seem to have a predefined matric to measure against: Correctness, performance etc., etc.

But here I'm interested from a purely programming point of view. There is  a lot of programs that needs to be designed / maintained / customized etc., etc.  So what are the basic things to look at to measure the goodness of a program ? Here the matric is not easily measureable, and that is what interests me most mainly because that there is a 90% or more probablity that one would end up in a project where most of the code/program already exists and (s)he need to catch up with the rest.

There are lot of methods being followed in different places. Some are manual and code walk thru, and there are others who has softwares ( yet another set of program(s) ) that verifies and try to find basic flaws in an implementations. And people often go at length to find defects in algorithms used in a program. Here our emphasis should be little different. And the reason for this is that hardly any developer's program runs in isolation. They usually work with other people's implementation of other modules. And mostly developers moves from one project to another quite frequently.

Assuming high level language used for a typical implementation, I always look for the following -

1) How easy would be to replace some of its parts?. Here parts could be sub routine, block of code in a sub routine, a macro etc. The reason for this is that people tend to think in term of parts ( divide and conquor ) when it comes to repare or understand anything.

2) How well the comments explains about the implementation. Here well does not mean number of lines in the comment. And if too many things are done in a routine, even the implementor would not be able to comprehend it within the comments.

3) How many lines of codes  are there in the largest subroutine?. Here if a sub routine goes more than 50 lines it should not be considered as a good subroutine. More like 30 lines should be the max, except in few cases where 50 should be maximum. Change these numbers as you please, but don't go to hundreds :-)

4) How many things a function is trying to do?. If a function does too many things, it would not be a good function for maintenance.

Once I get a feel about a program using above stated four steps, I try to go into the detail specific to the language used, and overall quality of a program. But they are for other topics.