Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Previously I was searching for a good TimeLine control for a WPF project. I found an answer in Here which direct me to this CodePlex project.
Now I want to change code to feed my culture needs. But there are some mismatches!
My question is:
How you interact with such thousands lines of code?
EDIT:
Any shortcut will be great!
You add comments to the source code when you have understood it enough to be able to do so. Refactor these comments vigorously as you understand more and more.
... and the code will thank you for it. ;-)
Take single action, debug (again and again) the code to find how that action is accomplished. Write down the same in simple language to get a better understanding!
Something that Joel Spolsky wrote way back when on his blog (can't find the article now) really stuck with me regarding this:
He said how code is not natural human language, but as programmers, we are easily lulled into thinking that it is, and that we should be able to read it as such. Consequently, a lot of us look at new code and expect to be able to just "read it" and understand it immediately, as if it was a block of text in English.
So I think the key is to basically just be slow, methodical, and scientific. And as others have said - comment it (and even refactor) as you go. Don't fall into the mindset of "I should just look at it and understand immediately".
Oh, and yes, I still fall into this trap myself sometimes. "Do as I say, not as I do", and all that. :)
SE-Radio interviewed Dave Thomas about this very subject
This podcast episode has many tips and techniques to enter the 'culture' of the project and understand how the original inhabitants lived.
I had to do this recently with a project of over 100,000 LOC. My first idea was that it's easier to see patterns from graphs of 100 or even 1000 nodes than from 100,000 lines of text.
So I spent 45 minutes and wrote a short (<100LOC) Python program to parse what I needed from it, and draw the object relationships. I generated Graphviz source, which is a really easy language to generate. (There's nothing special about Python here: Ruby or C# or Common Lisp or whatever could do it just as well.)
On other projects, I've seen people use Graphviz for module dependencies, call graphs, version history, all kinds of things. Greatest program visualization meta-tool ever.
(Maybe it's because I took compilers, but I find it weird that when a programmer is faced with a problem, the answer seems to always be "write a program!", except when the problem involves the source code to a program. :-)
Step through it in the debugger as it runs, its nearly the only way to understand a new, large code base.
Understand that there really are no shortcuts to grokking in fullness. (And if you have trouble with that phrase, your education has been SORELY neglected. It is from "Stranger In a Strange Land", by Robert A. Heinlein.)
Read it, one page at a time, one routine at a time. Add comments. Draw pictures of major data structures. Recognize algorithms. Draw upon previous knowledge.
Resist the temptation to crank up the debugger. The debugger viewport is too small: you see one line at a time, but you really don't see where you've been or where you're going.
Whatever you do write up as much as you can as you go along so no-one ever ends up in the same position as you have.
you need to use clues. get a clue of what you have to look for and extensively use the search functionality of your environment or IDE that can bring you to the desired section of the code that you need to make change to.
reading 14 thousand lines of java code does not make any sense. Search functionality is your life saver
Different people have different learning styles, so YMMV. The first thing I do in this situation is read the entire code base through at least once. That gives me a general idea of where everything is. Then I choose a section to examine in more detail. Data structures would be a good place to start. Once I have a general idea of what's going on, I do the same with another portion of the code that interacts with the first. After enough iterations, I have a good sense of how the code works.
The best way, as with all programming not just large chunks of uncommented code, is to break it down into pieces. This is both something you should do in your head as well as visually in the code. This may mean adding big bold comments or multiple line breaks. This helps while scrolling through it to see the pieces. Try to find the logical chunks of code.
Of course, as you understand bits, comment them for what you know at that time, possibly putting in notes about about something you don't understand.
I would also recommend not trying to understand the entire piece right from the start. Instead try to understand the pieces that you need to know right now and work on the rest later.
I would start by using the Leo Editor in @shadow mode with active use of cloned nodes. This allows one to add notes and comments for each section of code under study without changing the code, and the annotations will always be in context, next to the code it's talking about. Here's an example workflow the docs:
For example, when I fix a bug in Leo, I create an ordinary node to represent the bug. This bug node is my view of all the data in Leo’s source code that relates to the bug. As I discover code related to the bug, I clone their nodes and move them under the bug node. I’ll also add ordinary nodes as children of the bug node. These nodes contain the original bug report, descriptions of how I fixed the bug, test data, or any other notes I might want to keep.
Once I have created the bug node, I concentrate only on that node and its children. I can examine the bug node and its children without having to jump around the outline. Everything I need is in one place. When I get around to actually fixing the bug I can do so by changing the clones. Again, I do not have to jump around the outline. It doesn’t matter how big or complex the entire outline is: I am only dealing with the bug node and its children. This extremely narrow focus makes it much easier to fix bugs.
Draw diagrams of the source: the data relationships, the functional relationships, the object relationships. Determine aggregation, data flow, and code flow. Pictures are far better than comments for this, and can be kept separate from the code.
Before you refactor anything write tests. Lots of tests. Very specific tests to small blocks of code that are at least callable, as it'll depend on how your inherited mess is written.
The advantage to writing tests to begin with is that you need to have some kind of understanding of the code before you can test it, so every test you write will hopefully be a little bit of knowledge gained. You can also heavily comment the tests with your assumptions alongside the assertions.
By doing it test first, you don't run the risk of altering something in the code that has knock-on effects you can't know about. You'll also have a safety net when you do come to refactor the code.
I use tools like doxygen, to generate an overall class diagram, than adds my understanding of what each of the classes do.
Then I pick up some easy bug from the bug queue (before my manager assign a hard one to me :P), then run through that functionality into debugger and try to generate a rough data flow or code flow model.
For example export functionality in some software: so I try to understand how the source data is read, from where in the code (base interface) can I evaluate the data is read correctly using my class and code flow diagrams, which classes are responsible for which type of exports, etc. I think half of the understanding is done, once you have the class diagrams and flow charts.
Approach a trivial defect, e.g., a NullPointerException. Avoid anything regarding concurrency at first, anything that by its nature will involve understanding a lot of the code at once.
Once you've fixed a few bugs you'll probably have a pretty good idea. Works for me, at any rate.
Basically the action to write a clean code should start right from design. If we are coding in OOP language come up with a UML ,share with peers and get convinced that design is not ambigous . In any case we developers should get convinced that design solves the problem and not ambiguos.
When it comes to coding we have to make sure the design is getting converted to code i.e. an Entity to a class or struct , an operation to function etc.
And i went through a white paper http://queue.acm.org/detail.cfm?id=2063168 which talks about coding style or how we can use space, indentation , Font variation as most IDEs do we can use to write MUCH CLEANER code where we humans can understand as much as machines do. It stresses more on writing comment free code so that our code will appear as paragraphs itself.