What is the right way of reading a code?

[ImDinesh Sharma]

Situation could be anything for example

I asked someone a question and he/she wrote the answer in code

or

I am reading some part from a codebase

or

Learning with a code example.

Regardless of how big the code i am seeing to understand, i wanna get it in my brain the right way so that i do not mess up with my head.

Where to start, what needs to be noticed, although i know that it depends on the code but i m looking for a general thought process that should occur when looking at it and try to get it.

Also this is my second day hanging around here and i started to feel that i have come to exactly where i wanted to be. THANK YOU KATHY FOR MAKING THIS FANTASTIC COMMUNITY, IT REALLY HELPS THANKS A LOT

[Campbell Ritchie]

Welcome to thee Ranch

Read the code from top to bottom, and read all the words as they appear to be written. If anything is unpronounceable, then report it back to the writer as an error.
I don't believe you learn much from reading code, but only from writing lots of code.

[Liutauras Vilda]

Welcome to the Ranch.

I'm not sure there is some "right way" of reading code, I guess that a lot depends on the situation and the person who looks at the code.

ImDinesh Sharma wrote:Where to start, what needs to be noticed, although i know that it depends on the code but i m looking for a general thought process that should occur when looking at it and try to get it.

In my opinion, first you need to know what are you looking at, meaning you need to understand what the problem was and what was meant to be solved with the specific part of the code, so you could compare whether problem's description and its expected solution is reflected in the code part. That's one.

Two. TDD mindset people I think tend to start looking at tests, so the problem description and meant solution of it is also reflected and covered in the test suite. Now, that's barely the case in practice, unfortunately though.

ImDinesh Sharma wrote:Regardless of how big the code i am seeing to understand, i wanna get it in my brain the right way so that i do not mess up with my head.

Three. I think that is the exact symptom if the code weren't readable, so you get headache. The code you are looking at at the very moment supposed to be a fairly small part which clearly tells what it does, meaning some higher level concepts communicated, then presumably some method calls which accomplish some sort of smaller tasks of a bigger whole.

[Liutauras Vilda]

ImDinesh Sharma wrote:THANK YOU KATHY FOR MAKING THIS FANTASTIC COMMUNITY, IT REALLY HELPS THANKS A LOT

One important note. I think you are quite right that Kathy Sierra at some very first moment was the one who worked on CodeRanch, at that time I think it called a JavaRanch. However, for the past few decades this community is led by Paul Wheaton who also owns CodeRanch.

[Campbell Ritchie]

Liutauras Vilda wrote:. . . , so the problem description and meant solution . . . .

Good point. If there isn't a good description of what a method should do (=documentation comments), send it back ad complain. The documentation comments constitute an important part of the method. I read somewhere recently that code is written once and read many times, so its legibility is very important.

[Randy Maddocks]

Campbell Ritchie wrote: I read somewhere recently that code is written once and read many times, so its legibility is very important.

So very, very true. Consider a situation where a developer writes code and includes meaningful, clear comments, then leaves a company and some time later another developer has to work with same code to apply updates, etc...If the comments are lacking/confusing it could make what may be a simple task much more complicated and frustrating. I have been tasked over the years with updating programs that were several years old, and if the previous developer took the time to include relevant comments, and put some thought into the logic and structure of the code (read: logical, concise methods and meaningful variable names), it made things go much smoother. But if comments were missing or useless (e.g. "This getter method gets value"), and the logic hard to follow....  

[Campbell Ritchie]

Randy Maddocks wrote:. . . "This getter method gets value" . . .

But that may be all there is to say about a getXXX() method. Once you get beyond straight plain simple getXXX() methods, you are up the creek without a paddle if there are no decent documentation comments. Should one say it is a case of taking the time to write such comments, or call it being professional enough to use documentation comments as a guide to writing the method and keeping those comments?

[Randy Maddocks]

I am thinking of situations where comments are inserted simply for the sake of inserting comments, rather than taking the time to add comments that have some thought behind them, that offer some insight into what the purpose of the class, method or variable, is. Regardless, I find comments can be invaluable if properly used. I look at them as kind of like time capsules, information we can look at down the road and get a feel for what is going on, saving time and frustration.