Re: How to understand huge code

On Mar 14, 2:52 am, Jack.Thomson...@xxxxxxxxx wrote:
Hi All,

I am working with C,C++ since past 1.5 years, I am also pretty good in
writing small programs. But when it comes to understanding big
projects, (Ex: Say I want to contribute in a open source storage
product) I feel very difficult understanding the complete code flow.

Any help on the approach, how to understand huge projects code.

---------------------------------------------------------------------------­-http://programmingsite.googlepages.comhttp://plainthought.googlepages.com

I am currently working on an old C++ program that was poorly
constructed. It is very difficult to understand code just by following
the flow. Indeed, you absolutely must request more information from
those who have been working in it. "What is this code doing? Why does
it do it that way? What do you think you could do to make it easier
for me to understand?" I am constantly asking the original writer of
the aforementioned program what his code is doing exactly. Without the
original programmer, you can only hope his/her comments are sufficient
(they rarely are).

Another big part of understanding code is being able to separate the
code that does different things. It is common to find code with
intermingling SQL, logic and sub-system calls. Simply gutting out a
method and just leaving the logic can lead to amazing clarity. I
prefer to gut it and convert the logic to psuedo code. Somehow,
writing it in a semi-programming language helps reduce clutter. I tend
to replace sub-system calls with an overall summary of the subsystem
call, applying the english equivalent to how the parameters are being
used and modified. Where the results of a method are used in multiple
places, I replace the result variable, again, with the subsytem call
summary. For things like SQL, I ask myself what the SQL is retrieving
and write something like, "Gets all customer information where their
purchases > $15.00".

I prefer to break down huge code from the top down and then the bottom
up when I get stuck. Code on top usually is more simple and has a
faster flow. Code on the bottom tends to be an implementation detail,
throwing variables around and entering and exiting scopes. In a good
system, the names are usually enough to tell you what the method is
doing . . . just ignore the rest.
.

Relevant Pages

  • Re: NEED TO GO FASTER
    ... Writing your entire message in UPPER CASE is considered shouting, ... entirely written in upper case, then it is very had to read (especially ... SQL is a set oriented language, ... Make sure the proper indexes are in place. ...
    (comp.databases.ms-sqlserver)
  • Re: Querying a DataSet/DataTable in .NET
    ... to writing an in-memory database engine. ... >>>I think it would be nice if we could have a SQL engine available on the ... >>> display only (I could put it in business objects so I can reuse the ...
    (microsoft.public.dotnet.general)
  • Re: Large dataset performance
    ... in SQL. ... Understand better set operations on SQL and ... application would be writing data to the database and this cannot ... of underlying principles. ...
    (comp.databases.theory)
  • Re: AVR Beginner Questions - Ports and Speed
    ... > much better than assembly for many types of tasks, but writing in assembly ... > architecture without understanding its assembly language, ...
    (comp.arch.embedded)
  • Re: OT: Was it really 25 years ago?
    ... But the writing, the science, the ... But there is something about participating in the process ... that we are lacking a whole layer of understanding. ...
    (uk.comp.sys.mac)