Actually , code comprehension is not easy in general even from the code programmer after some time , any way the best way to understand a code is breaking it into objects and classes and see the properties for each object and their running methods , if the method is too complicated you can copy it into some main program and make its parameters as inputs and see how it runs by "trace method" while you keep observing the changes in variables and final results.

Salaheddin Juneidi Can i term it as Object Oriented programming..i.e. defining your object part by part and then solving it???isn't it?

Hi there Raj,

I am a FORTRAN addict from the old school. When I want to grasp the structure of a certain code it depends whether I have written it myself or not.

When I produce the code myself, I first make a classical program analytic scheme.

This helps a lot in rationalizing ones own code and application. It is quite a job at first, but afterwards, especially when maintaining, changing or expanding the code, one starts saving a lot of timetime.

Secondly (and in FORTRAN77) I use many many comment statements (C in the first column) to document the code. Some of my codes therefore read like a book. Actually a kind of Manual to understand the code. Each step in the code is explained, all loops documented, all IF statements explained, all formulae documented and so on. Execution speed is not really downgraded by adding comments, at least not in Fortran77. Compilers still work like in the old days. When they see a C in the first column of a line of code, they skip that line and hence do not compile it into machine language. Pretty convenient. One does not have to be shy when commenting a FORTRAN 77 code. It does not impact on execution speed.

I don't care actually about object orented programming and all that shit, I go straight to my target when I have my analytic scheme ready.

I do use a lot of subroutines and functions in my code. It gives more structure to the code and allows you to use a subroutine or function more than once for different objectives. If that is object oriented programming, OK, so be it.

For example when one has a function which performs numerical integration, one can use that function for every integration needed in the code. So don't repeat code if you use it more than once, recycle it by making modules like functions and subroutines (in FORTRAN77). If this is modular programming, so be it.

I also don't care about user interfaces, because most of my applications are made for modeling and number crunching. I run the code directly under the operating system (Windows, Linux with VMware Player on top). I doubleclick the compiled code and a few seconds or minutes later I have my results in an ASCII output file.

ASCII data allow you to go where you want with it in the downstream output graphing, post-processing, or using as input for another code or model.

I consider a GUI as unnecessary ballast. But I can dig that some people that don't master the art of coding, need GUI's to run code. However, a GUI is ballast, and ballast makes a boat go slow. It is the same for code. The more GUI, the slower the code. One can miss that when the message is crushing numbers.

Hence, I am looking at the question asked by Raj, purely from my perspective. I admit that for more commercial applications, Java and the like, interfacing on the web and the like, are needed, to guide the user and to make web apps.

As said, that's not the way I use code and its not the way a I conceive code. I am from the old school, as put in the beginning of this short intro in my way of coding and making it comprehensible for colleagues.

Cheers,

and for the programmers, lot's of fun and no time to waste!

Frank

There are two aspects to code comprehension. First is "What" and second is "how".

If the output of the code is already known then focus is usually on how than what that code is doing. This how part constitutes the algorithm side of code. Whereas for completely new code without much documentation attached to it, both what that code is doing and how matter.

As Frank stated, if the code is having lots of comments then best thing is to follow the comments but with a caution to cross check with the code associated with. Lot of times, it has been seen that comments are stale and newer generation of programmers edited only the code may be due to feature addition or due to bug fix but did not edit the comments.

There are various tools available out there which aid in code comprehension. But the old is gold and that is Code Walk-through with manual notes (perhaps associated flow diagrams on white-paper).

Depending upon code size, it is good to start writing unit test cases (considering function as unit) and as Salaheddin mentioned, tracing the test case step by step.

When both the above methods are attempted one after another on small-small code snippets, the code can be better understood.

Offcourse if the detailed manual is present, it is like sugar in the milk and the process of code comprehension becomes comfortable journey.