Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How To Start Reading Other's Code?

timothy posted about a year ago | from the first-hire-some-polish-mathematicians dept.

Open Source 254

BorgeStrand writes "I'm reviving an open source project and need to read up on a lot of existing code written by others. What are your tricks for quickly getting to grips with code written by others? The project is written in C++ using several APIs which are unknown to me. I know embedded C pretty well, so both the syntax, the APIs and the general functionality are things I wish to explore before I can contribute to the project."

cancel ×

254 comments

Test and Break (4, Insightful)

Jacky Alciné (2953293) | about a year ago | (#44023571)

If there's a lot of documentation, interpret it like your favorite religious text. Try to hit up some of the old developers from the VCS. Also, I'd like to help :)

Re:Test and Break (3, Funny)

Anonymous Coward | about a year ago | (#44023641)

If there's a lot of documentation, interpret it like your favorite religious text. Try to hit up some of the old developers from the VCS.
Also, I'd like to help :)

The Great Programmer commanded his bytes to carry their bugs to the bitstream and drown them, or 7 years of seg faulting would follow.

Join the Church of Emacs today!

Re:Test and Break (5, Funny)

ichthus (72442) | about a year ago | (#44023733)

And lo, yea though ye shifteth right 8 bits, counteth not thy sign as verily carried henceforth unto the int8_t.

Re:Test and Break (2)

aardvarkjoe (156801) | about a year ago | (#44024569)

If there's a lot of documentation, interpret it like your favorite religious text.

So it's got some pretty good ideas, but nobody really pays attention to what it says?

Describes the documentation for most projects I've worked on.

Start with the headers (5, Insightful)

Beryllium Sphere(tm) (193358) | about a year ago | (#44023587)

Knowing the data structures gives you the ground work for understanding what the code is doing. The data structures are a more direct description of the design decisions.

Re:Start with the headers (4, Insightful)

girlintraining (1395911) | about a year ago | (#44023683)

Knowing the data structures gives you the ground work for understanding what the code is doing. The data structures are a more direct description of the design decisions.

This approach assumes the programmer hasn't gone native. Great for managed code, but when the data structures are basically pointers being passed back and forth and calls to APIs deep in the guts of the OS... well, how do I put this: You're screwed. It's a crap shoot on if the programmer even knows why it works... sometimes in C++ you stop debugging the moment it starts returning sane outputs and consider yourself lucky you didn't have to fully grok wtf just happened. :/

A mandatory declaration. (0, Offtopic)

Anonymous Coward | about a year ago | (#44023729)

We will feast on what is inside!

Re:Start with the headers (1)

gl4ss (559668) | about a year ago | (#44024137)

well the headers are a way to learn what the pointers are pointing to...
using os libs isn't always referred as going native though.

here's a tip though, use an editor that lets you quickly jump to the definition of a thing(function, struct, whatever). it speeds up things a lot. even if you just end up in a header for some native lib you don't have the source for and that is uncommented.

Re: Start with the headers (0)

Anonymous Coward | about a year ago | (#44024441)

I hope that you don't write software where errors can result in a danger to life and safety.

Re: Start with the headers (0)

Grishnakh (216268) | about a year ago | (#44024465)

Well with stuff like Windows being used to run ships, you can be certain that poorly-written software being used in applications where it results in a danger to life and safety is probably the norm these days.

Maybe. (2)

Max Threshold (540114) | about a year ago | (#44024371)

That's assuming the original programmers followed the MVC pattern. Very often they didn't. That's when you start reading tea leaves.

How to read code (5, Insightful)

girlintraining (1395911) | about a year ago | (#44023595)

What are your tricks for quickly getting to grips with code written by others?

For me, it comes down to a lot of mountain dew, techno music, and hours of guru meditation. As you dissect each function, sketch out its relationship to other major functions. I take a two pass approach .. first, just look at the function call outs and the return values and make a rough sketch of the 'scaffolding' of a program. On the second pass, any function that you can't see the obvious application of, or appears obfusciated or complicated, dissect into functional units and sketch out what it does in your notes. I do this by actually physically drawing the relationships using something called a mind map.

Until you get used to it, actually writing it down, even if it's just a bunch of messy arrows to blobs of circled text... it will help job your memory and help things sink in until you have the necessary 'ah ha!' moment.

YMMV.

Re:How to read code (1)

BorgeStrand (1657179) | about a year ago | (#44023671)

Thanks! Are there tools that do this automatically? I haven't worked much with Doxygen and usually pick the programming environment most commonly used for the programming target. I've had some good experiences with Eclipse based editors but find the learning curve a bit steep. On the easy and less powerfull end I use Programmer's Notepad and grep in Cygwin.

But if there are good automated tools, I'll take the time to teach myself how to use them.

By the way, the code is for an open source windows driver.

Borge

Re:How to read code (0)

Anonymous Coward | about a year ago | (#44023741)

Understand can draw some nice looking call graphs.

Re:How to read code (5, Informative)

cdp0 (1979036) | about a year ago | (#44023743)

Are there tools that do this automatically?

Have a look at Scitools Understand [scitools.com] .

Re:How to read code (1)

ian-sdot (2953307) | about a year ago | (#44023835)

+1. I've been using Understand since 1998 across multiple code bases C/C++ and Java. The cross reference facilities are really impressive if you take the time to set up the classPath or include settings. It also has an impact analysis feature so that when you make a change it will show the modules that are impacted by that change. Useful for identifying how much testing will be needed.

Since this is an OSS project ... (5, Interesting)

hedronist (233240) | about a year ago | (#44023919)

Since this is an OSS project, can you suggest any tools similar to Understand that don't cost $995?

The only thing I could find was source navigator NG [berlios.de] , but I have zero experience with it.

CCVisu (3, Informative)

PLAST (416196) | about a year ago | (#44024037)

You can use doxygen to create a dependency graph and visualize it using CCVisu.

http://www.stack.nl/~dimitri/doxygen/
http://ccvisu.sosy-lab.org/
http://ccvisu.sosy-lab.org/manual/main.html#sec:input-dox

Re:Since this is an OSS project ... (2)

Bruce Stephens (6634) | about a year ago | (#44024085)

source navigator still works OK. doxygen can provide reasonable callgraphs (especially for C). DXR has improved dramatically recently---it's not just for Mozilla now. DXR requires the code to be compilable by clang, but doing whatever's necessary for that might be a useful exercise.

Re:Since this is an OSS project ... (0)

Anonymous Coward | about a year ago | (#44024257)

You can also use valgrind --tool=callgrind, interactive mode. Yes, it is usually for optimization but using it would give you an idea what functions get called (and the call graph) for certain types of user actions. One run won't give you an overall picture but you can use it to help understand which classes are doing the heavy lifting.

Re:How to read code (0)

girlintraining (1395911) | about a year ago | (#44023753)

Thanks! Are there tools that do this automatically?

If there were, we would have little need for programmers. Sorry, but sometimes paper and pencil is the best approach. :/

I've had some good experiences with Eclipse based editors but find the learning curve a bit steep. On the easy and less powerfull end I use Programmer's Notepad and grep in Cygwin.

Honestly, I wouldn't get too comfortable with a given IDE -- some of them (I'm looking at you, Visual Studio) abstract away and hide a lot of the code and it can make for some really confusing times for you. Just open up the raw .c or .cpp files with whatever is comfortable... anything with color coded formatting... and then just sit back and try to absorb it without any preconceptions.

Programming is a lot like sketching or other forms of art. It works best if you don't try and think about it. Thinking about is forcing it... and you'll find the best hackers tend to learn by osmosis... that is, they throw themselves in it, and trust that they'll absorb context and meaning as they walk through the functions and lines as they go...

Re:How to read code (-1)

Anonymous Coward | about a year ago | (#44023903)

Hey. Fuck You. You don't fucking read code or do anything else.

Re:How to read code (0)

Anonymous Coward | about a year ago | (#44024019)

tl;dr version: Call Graphing, Function Tree Plotting, and Dependency Analysis.

Find a good editor/IDE (1)

Anonymous Coward | about a year ago | (#44023597)

Find a good editor or IDE that allows you to quickly navigate the code.
Figure out how to build it
Figure out how to test it
Read the API docs. Understand the objects and how to interact with their interfaces.

YMMV, depends on how smart you are I guess.

The only way (2, Funny)

Anonymous Coward | about a year ago | (#44023599)

Look straight at the code for a few hours without moving an inch. After that its details should be printed into your brain.

Unit Tests (5, Informative)

Anonymous Coward | about a year ago | (#44023607)

If possible, I would try writing unit tests for the existing code. This tests your understanding of what you are reading and will come in handy later if you change the code. If unit tests already exist then I suggest that you read them since they will tell you the intention of each function.

Re:Unit Tests (1)

benjfowler (239527) | about a year ago | (#44023769)

Please, mod parent up. This is excellent advice, particularly when you're refactoring.

Re:Unit Tests (0, Insightful)

Anonymous Coward | about a year ago | (#44024433)

Mod parent down.

If you don't "understand" code, in this context this means you don't know what its good for (what requirements it fulfils), but only what it does (which is the information you're getting from reading the code). Therefore, it's impossible to write any test-case for it, except one that verifies that it does what it does. And that's pretty useless, unless your plan is to test the compiler.

Main or Bugs (0)

Anonymous Coward | about a year ago | (#44023611)

It depends on what you need to do. I usually start with main and trace through it slowly but surely. Usually it takes me a week or two to fully comprehend the pieces of the code to the point where I feel comfortable with making big changes.

Another approach is to find some small bugs that need fixing and fix them. Something that will force you to have to find what function the bug is in and then step through the code with a debugger.

Good luck!

Practice (0)

Anonymous Coward | about a year ago | (#44023613)

Lots of practice reading and writing C++ code. Reading decent books like the Addison-Wesley C++ series edited by B. Kernighan helps, although the snippets of code presented by the authors aren't representative of a real code base.

If there's any documentation, read that first. Usually there isn't much, or not nearly enough, and the code has been written by multiple programmers at different times.

Google for tutorials and sample code on the relevant external APIs.

Tried once to read MS C++ STL implementation (0)

Anonymous Coward | about a year ago | (#44023615)

I gave up !!!!
Same think can be said about my attempt to read EXT2 source code.......

Re:Tried once to read MS C++ STL implementation (1)

Immerman (2627577) | about a year ago | (#44023989)

In fairness I don't think I've ever read *any* STL implementation that wasn't hideous. Seems like non-trivial template programming internals are sort of like VB - without exhaustive self-discipline the result defaults to hideous abominations you pray you never have to look at again. And it doesn't help debugging that compilers all seem to be optimized to deliver maximally-obfuscated error messages if they encounter a problem related to templated code.

Don't get me wrong, I love templates and even engage in metaprogramming from time to time, but there must be a better way.

Read someone elses Perl code first (4, Funny)

jd2112 (1535857) | about a year ago | (#44023621)

Everything else will seem simple after that...

Re:Read someone elses Perl code first (1)

Anonymous Coward | about a year ago | (#44023705)

Have written a perl script to not my displeasure your comment.

+=^~#}{$&;"?!,.'

Re:Read someone elses Perl code first (1)

c0lo (1497653) | about a year ago | (#44024225)

Everything else will seem simple after that...

Everything? I doubt [wikipedia.org] it.

Re:Read someone elses Perl code first (2)

broknstrngz (1616893) | about a year ago | (#44024649)

Better yet, read your own 3 year old Perl code. Everything else will seem simple after that...

manage your mood (1)

Anonymous Coward | about a year ago | (#44023625)

They will be doing horrible, horrible things from your point of view. Manage your mood, to be able to stick to the goal.

Basic pointers (1)

rolandomartins (2953297) | about a year ago | (#44023649)

1) Start by understanding completely the target language, in this case C++. 2) Get a IDE that is able to provide full support for finding references and definitions in C++. For now only Netbeans CND is able to proper do that for Linux-based OS. Alternative for WindowsOS use Vision Studio. 3) Then you just have to start reading the code and build the mental map of the project.

Re:Basic pointers (1)

DarkOx (621550) | about a year ago | (#44023689)

You should have a look at Codeblocks. Its a nice IDE and it does a pretty good job. Runs on Linux

Read, read, and read (1)

Horshu (2754893) | about a year ago | (#44023651)

Read as much code of as many different styles as you can. Eventually, you will hopefully start just getting a feel for programming much like music, where different code has different styles. You'll see manifestations of different patterns and start to gain a deeper understanding of it (it can have an almost zen-like quality to it)...why certain patterns get used, why certain developers use patterns that don't make sense to you, what kind of developers the authors are. It took me years before I started to get a feel for reading other people's code, but I have an idea as to how good a programmer is and even what kind of everyday personality they have from reading their code. It really is like music. And one more thing: don't count on comments for guiding you through this; it's rare to come across well-commented code, especially in a professional environment (ironically enough).

Run, run, and run (1)

Anonymous Coward | about a year ago | (#44023693)

I disagree with reading too much code.

Run the code to see what it does. Add some printfs to validate the understanding of what the code is doing.

Doxygen (5, Informative)

mapinguari (110030) | about a year ago | (#44023657)

Even without Doxygen's specific format for comments, you can use it to graph object relationships, call-trees, etc.

You can generate docs limited to a few files or classes if you just want to focus on them.

www.doxygen.org

Re:Doxygen (1)

Anonymous Coward | about a year ago | (#44023773)

Doxygen is a steaming pile of poo. A poor substitute for actual, thought out, written documentation. Speaking as someone who has had to read doxygen generated docs a LOT, I can tell you that just reading the code is easier. They're practically worthless 99.9% of the time.

Re:Doxygen (1)

Immerman (2627577) | about a year ago | (#44024043)

Well what do you expect? Lazy programmers focussed strictly on functional components result in comments that are useless 99.9% of the time. GIGO. Have someone go in and incorporate decent documentation into at least your top-level comments and doxygen will collect them into reasonably well organized hyperlinked documentation that can be easily kept up to date by simply updating the comments when the associated code changes. Of course nobody will bother to do that so it will rapidly become useless again, but hey, tat's not doxygen's faule. Hire some decent technical writers to keep your comments up to date.

Yes, I'm lazy too, but when writing good code, especially interfaces, I spend at least as much time on the comments as the code. In fact I often write the comments first just to keep myself honest.

pretend you are the computer (3, Informative)

Laxori666 (748529) | about a year ago | (#44023667)

First, figure out how the code gets loaded and runs. Find the equivalent of the 'main' function. Then start tracing it, seeing what functions get called, how things are loaded, etc. What really helps here is an editor you can CTRL+click on a function on to go to its definition. When you hit a function that doesn't call any other unknown functions, then you can start understanding what it does without having to step into it. These are the basic functionality units. Then when you know enough of those, you can start going a level up, etc. Eventually a picture forms in your mind of just how things work. You can optionally skip over functions for preference of looking at them later if it seems pretty clear what they do based on the name & how they're called, but you might find important stuff in there later. This is how I go about it, anyway. It can be very frustrating and very confusing at first, but eventually the picture starts making sense, then things click in a most satisfying manner. That being said, the above is also the reason I can dislike complicated frameworks. There's so much indirection that it can take quite a while indeed until you hit something concrete. The mark of a good framework is, either it doesn't do that, or it does but soon enough you figure out its parts and then you can treat it intuitively.

Reformat, Reformat, Reformat (4, Insightful)

zieroh (307208) | about a year ago | (#44023675)

I find that going through some key functions (assuming you can find them) and reformatting them to your own liking can be helpful, commenting code along the way. Then if you want to get more aggressive, start cleaning up some code in minor ways that still stay true to the function's meaning. After you've done a bit of that, you should probably have at least a vague idea what's going on.

Re: refactor, discard, repeat (5, Interesting)

Anonymous Coward | about a year ago | (#44023781)

Find a function. Refactor it until you grok it. Discard the results.

Keep in mind that it will be VERY tempting to commit your changes, but you must throw away the work and chalk it up as a learning experience if you ever want to be taken seriously by the others who work on the project. Junior developers (and even some senior developers) often think they're doing everyone a favor by doing drive-by refactors, but they're not; they're just slowing down the entire team and coming across as that a**hole who keeps f***ing up the diffs and destroying the useful output of tools like git blame.

If you found any bugs in the previous step, make a patch with the absolute minimal change to fix each individual bug. IMPORTANT: Before committing the patch, first be sure that you can reproduce it in the old code, and that the test case is fixed by your new code.

Repeat the process until you understand the entire system.

With any luck, you will finish with a solid understanding of how the code actually works, and you will most likely also fix a few dozen bugs (if you didn't find at least one bug per kLOC, then "you're doing it wrong" or the code was written by an inspired genius with OCD). At that point, you will be the team's expert on how things work, and you will be in a position where you can start proposing simple refactorings that will improve the code quality.

Re:Reformat, Reformat, Reformat (1)

MAXOMENOS (9802) | about a year ago | (#44023861)

This is good advice. I've gotten to know the guts of some massive core systems mostly by cleaning up code, making minor bug fixes, and adding a new feature (10 digit SSNs instead of nine).

Openhatch [openhatch.org] is a great place to get started....

Try some good quality marijuana (4, Funny)

stevegee58 (1179505) | about a year ago | (#44023717)

It won't help you understand the code but you'll stop worrying about it so much.

Format / Edit the Code (1)

ionrock (516345) | about a year ago | (#44023719)

I've found the best way to learn a code base is to start editing it. There are almost always formatting details and names that don't feel right. Start changing those and see what happens. The process will force you to understand the logic and help you really understand the code. Even if you throw all your formatting changes away, you'll definitely learn something.

Hopefully, the project has tests as well that will let you see if your formatting changes break things, in which case you've begun to understand the relationship between different code blocks.

Don't (0)

Anonymous Coward | about a year ago | (#44023721)

C++ is a very very different language from C, it's way more powerful and so more complex: It will take time (a lot of it) to learn first C++. The C skills are pretty much useful as the first 50pages in the C++ book: you've still 850 more to go from there.

Start with the foundation... (0)

Anonymous Coward | about a year ago | (#44023731)

First I'd start by learning the library/apis it is using. Write a few test programs in them to solidify the knowledge. Work your way up, layer by layer... which is the way you'd write it in the first place.

Bug hunting (3, Insightful)

tinkerghost (944862) | about a year ago | (#44023755)

I recommend starting by working on the bug list. It gives you something to work on constructively and it also makes you look through all the code to track the problem.

Write your own documentation (1)

Required Snark (1702878) | about a year ago | (#44023759)

As others have said, read the code. Do this top down; start at the main function and look at the call tree.

As you are doing this, start generating you own documentation. If the code doesn't use DOXYGEN, add that. Reformat and add comments. Write external documentation. When you are documenting, think of what you wish the previous coders had done for you, and then do that.

This is the way I write code from the beginning, and it leads to better code. If I can explain what is going on then I know I understand it. If I can't explain it, then there is a pretty good chance that there are bugs. It's good practice whether you are taking over someone else's code or starting from scratch.

Reading code is hard (5, Insightful)

benjfowler (239527) | about a year ago | (#44023761)

The trouble with university education, is that most people who teach there are computer scientists, not software engineers with years of experience in the trenches.

If this were actually the case, there would be a recognition that reading code is far harder than writing it. And far more emphasis would be on coming to grips, understanding, and working on large code bases. There'd be more stuff on things like unit testing, breaking dependencies, troubleshooting, and refactoring at least.

Re:Reading code is hard (1)

Anonymous Coward | about a year ago | (#44024061)

The trouble with the lack of a university education, is that you drone on for a paragraph instead of simply saying "We need more emphasis on how to reverse-engineer code."

Substances and coding (4, Insightful)

spasm (79260) | about a year ago | (#44023775)

Find out what drugs the original coder was using when writing, and take the same.

Re:Substances and coding (2)

AmiMoJo (196126) | about a year ago | (#44024237)

In all seriousness it can help to find out what books he read and thus what bullshit design paradigms he was into. Also try to get his username on Stack Overflow so you can find all is questions to get an overview of the development process and the challenges he faced.

Re:Substances and coding (0)

Anonymous Coward | about a year ago | (#44024541)

Also try to get his username on Stack Overflow so you can find all is questions to get an overview of the development process and the challenges he faced.

I fucking hope you're not being serious.

C vs C++ (4, Insightful)

Rob the Bold (788862) | about a year ago | (#44023785)

You mentioned you have embedded C experience and the code of interest is written in C++. You didn't mention if you had any C++ or other object-oriented programming experience. I assume the C++ code uses the OO features of C++ that distinguish it from C -- but this assumption is not necessarily true.

So, if you lack OO experience and the code is truly OO C++ code, you might want to do a little reading up on the basics of OOP in order to spend less time spinning your wheels.

Rewrite some parts (5, Interesting)

eulernet (1132389) | about a year ago | (#44023793)

Here is how I work on legacy code:

1) I don't look at the whole picture because there are too much details, so I prefer to attack little by little.
2) I quickly check what I can rewrite in order to optimize the code. If I have no idea, I run a profiler, and take a look at the routines that take the most time.
3) once I understood or rewrote the most consuming parts (sometimes it's heavily optimized, but most of the time, I can make a real improvement), I decide what most important functionality I would like to add, and I just focus on that.
4) if I really need to have robust code, I write tests for the routines before optimizing them, so that I can validate if there are regressions
5) whenever possible, I use "assert" and put some bound-checking tests, in order to validate the ranges of certain values or conditions.

The important thing is to start by taking ownership of a small part of the code, then a bigger part, etc...
Take one slice at a time, not the whole pie.
And one last point: knowing every little detail is useless, concentrate on what is important for you: performance, functionalities, ... ?

Visual SlickEdit/ Emacs ctags help a lot. (1)

140Mandak262Jamuna (970587) | about a year ago | (#44023815)

At work I am a big fan of Visual SlickEdit. It builds complete tags of all the functions, variables, classes etc into tags. Allows me to find all callers of a particular function, definitions, references etc. In Linux it will work with gdb to do step through debugging. I believe most of the functionality is available in emacs, with its ctags. Though most developers in our company use Microsoft IDE, I build all my sln files using slickedit and edit using slickedit. It has good integration with version management tools too.

Re:Visual SlickEdit/ Emacs ctags help a lot. (1)

jasno (124830) | about a year ago | (#44024289)

SlickEdit has saved my ass time and time again. I'm a cheap bastard and I hate paying for software, but SlickEdit is worth every penny. I can't imagine dealing with a large codebase without it. Yes, I've also tried cscope+vim and ctags, and it's fine, but SlickEdit is faster and easier to deal with.

Debug (1)

Anonymous Coward | about a year ago | (#44023829)

I find it useful to follow the flow of control using a debugger. For C/C++, I like GDB in "TUI" mode because I can see the code easily.

If the program is multi-threaded, it's worthwhile to read up on how to handle threads in GDB. Understanding what's going on in a multi-threaded program can be especially difficult. Having the ability to switch between threads, to get backtraces (so you can see how that thread got where it is currently) and inspect its variables can be very informative.

Swearing helps (0)

Anonymous Coward | about a year ago | (#44023839)

Especially at the so-called engineers' deceased pet hampsters.

(going anon for this)

I start reading other's code with... (1)

Tracy Reed (3563) | about a year ago | (#44023841)

less

GET A HOBBY !! CODING FOR FREE IS FOR SCHMUCKS !! (-1)

Anonymous Coward | about a year ago | (#44023845)

'Nuf said !!

If you want to throw your remaining time away carry on !!

'Nuf said !!

If you have free time to throw away volunteer at the local mortuary !!

'Nuf said !!

If you need to learn something learn Mandarin !! Then go work at Shitty Wok !!

'Nuf said !!

But before embarking on your next life endeavor clear it through Slashdot because only there can you find your answer !!

'Nuf said !!

Keep Some Rules In Mind (5, Insightful)

Greyfox (87712) | about a year ago | (#44023859)

1) Just because your predecessor was paid to program doesn't mean he craps daisies and unicorns. I have often gone in with the assumption that the guy before me knew what he was doing. Quite often I find I was wrong.

2) Just because the code is awful doesn't mean it has no value -- No matter how bad it is and how difficult it is to read, if it works at all it has probably got years (maybe even decades) of bug fixes and feature requests. Until you have a handle on it, any little change could cause a catastrophic cascade of side-effects.

3) No, we don't need to rewrite it. See 2. A working program now is worth more than all the pie in the sky you can promise a year from now.

4) It takes 6 months to have a reasonably good grasp of any moderately complex in-house application. It could be a year before you get to the point where someone can describe a problem and you immediately have a good idea of where in the code the problem is occurring and what functions to check.

Maintenance programming is as much about detective work as anything else. The only clues you have about the previous programmer are his source files. Once you've read them for a while you can start to tell what he was thinking, when he was confused, when he was in a hurry. Most of the atrocious in-house applications have changed hands several times and each programmer adds their own layer of crap. You can redesign these applications a chunk at a time until nothing remains of the original code if it's really bad, but it's best to save really ambitious projects until you understand the code better. I heartily encourage the wholesale replacement of "system()" calls with better code immediately, though. In several languages I've run across these calls to remove files, when they could have simply called a language library call (Typically "unlink".) If the original programmer used system("rm...") you can pretty much assume that they were a bad programmer and you're in for a lot of "fun" maintaining their code.

Re:Keep Some Rules In Mind (1)

hedwards (940851) | about a year ago | (#44024189)

What, you mean doWhatImean( X ) isn't a valid way of coding?

Re:Keep Some Rules In Mind (0)

Anonymous Coward | about a year ago | (#44024629)

1) Just because your predecessor was paid to program doesn't mean he craps daisies and unicorns. I have often gone in with the assumption that the guy before me knew what he was doing. Quite often I find I was wrong.

Corollary, just because each individual member of a good team knew what they were doing when they added to a piece of code, doesn't mean the resultant output isn't utter ****. Sometimes someone needs to look at the bigger picture of the code and notice all the additions are badly hacked into place.

Maintenance programming is as much about detective work as anything else. The only clues you have about the previous programmer are his source files. Once you've read them for a while you can start to tell what he was thinking, when he was confused, when he was in a hurry. Most of the atrocious in-house applications have changed hands several times and each programmer adds their own layer of crap. You can redesign these applications a chunk at a time until nothing remains of the original code if it's really bad, but it's best to save really ambitious projects until you understand the code better. I heartily encourage the wholesale replacement of "system()" calls with better code immediately, though. In several languages I've run across these calls to remove files, when they could have simply called a language library call (Typically "unlink".) If the original programmer used system("rm...") you can pretty much assume that they were a bad programmer and you're in for a lot of "fun" maintaining their code.

Pretty well true of almost any time system() is used, whether or not it is for removing files. Then there are tricks like trying to de-quote filenames before passing them through the shell (think filenames with parentheses), instead of carefully avoiding system().

Document it (1)

ItsIllak (95786) | about a year ago | (#44023891)

Chances are that no-one else has and doing so will help you understand it as well as producing some useful output to get the project going again.

Use the tools Borge (0)

meta slash (633499) | about a year ago | (#44023893)

Reading other people's code is a punishment that one must master if you hope to grow as a programmer.  My favorite approach these days is to use callgrind and kcachegrind, walking up and down the call stack for each stimulus I can muster.  I often build a custom client to send malformed requests for these tests, it usually becomes part of my unit/regression tests.  Then I make note of the most prominent function names and data structures.  I construct an outline as if I were writing a book.  GDB is also a fantastic tool for understanding software.  You can learn a lot about code merely by setting a break point in malloc or read.  Don't be afraid to use 'set var' to explore an interesting test case.  strace, particularly with -c or -ff, can give you a quick idea of what a program does.  Eventually I start to change it.  First I use indent or some IDE to fix the whitespace, then I start to refactor. Eventually the code begins to look more like something I wrote than what I inherited.  That's how I know when it's time to hand it off to someone else ;)

Re:Use the tools Borge (3, Interesting)

drinkypoo (153816) | about a year ago | (#44023983)

Reading other people's code is a punishment that one must master if you hope to grow as a programmer.

So what is the reward for reading comments which are unnecessarily set in monospace type?

Architecture Recovery (1)

prefec2 (875483) | about a year ago | (#44023899)

You can use static and dynamic analysis to gain knowledge on the structure of the program. Static analysis can be done with tools like Modisco (however, Modisco is not for C++ I guess). For the dynamic analysis, you need to add a monitoring feature to the code. This can be done with AspectC++. Instrument entry and exits of public methods (if it is OO code) or structural blocks detected by the static analysis.

However, if the program is rather small, then you can do the analysis also by hand.

Re:Architecture Recovery (1)

H0p313ss (811249) | about a year ago | (#44024053)

Try grabbing the demo version of RSA, (Rational Software Architect) [ibm.com] , it's great for turning Java and C++ code into UML models and has a neat way to explore models through diagrams.

The trial version is free for 30 days.

I am sure there are open source tools out there for this, but nothing so complete.

I usually do this (0)

Anonymous Coward | about a year ago | (#44023905)

Start a text file. what you want to do is this: basically putting code into English (or your primary language)
function A
        calls function B
                function B
                        cleans and persists the data
                        returns the clean version
        puts the clean data from b() into htm

Reading AND writing code puts it into your head in two different places, which is strangely useful.

                     

easy.... (2)

Idimmu Xul (204345) | about a year ago | (#44023965)

echo "i am here";

or print or console.log or printf or ...

It's hopeless. (0)

Anonymous Coward | about a year ago | (#44024029)

Abandoned pile of C++ code ... well, if you've got a self-defeating personality disorder, you may try to make it work. Or even do whatever you want to be done.

Normal response would be to forget it and start from a clean slate.

Forgetting about C++ as well would do much towards keeping you sane.

work (-1)

Anonymous Coward | about a year ago | (#44024047)

$85 an hour! Seriously I don't know why more people haven't tried this, I work two shifts, 2 hours in the day and 2 in the eveningAnd whats awesome is Im working from home so I get more time with my kids. Heres where I went,

www.Dub50.com

Use an IDE with a debugger (1)

namgge (777284) | about a year ago | (#44024049)

Learn to use a debugger with a nice interface for exploring call stacks, data structures, threads, etc. Then, get the mystery code to do something simple. and put a breakpoint at the point its about to complete the task. (Try grepping for a string you see in the output.) Work up the call stack putting a breakpoint at the start of each procedure that is being called. Now repeat the task and look at each procedure as it is invoked.

This will be a slow and painful process. Make sure you don't have anything better to do with your life before embarking on it.

Good luck.

Namgge

you dont! (1)

ddfire (1114249) | about a year ago | (#44024065)

i just start fixing problems or adding features and learn the code on the go... you dont need to read all the code from the start...

Try and error (1)

drolli (522659) | about a year ago | (#44024109)

If a function is to arcane to be understood in 10 Minutes, start breaking it down into smaller *documented* functions while maintaining the same test results. Good chance that this will also help the project directly

Re:Try and error (1)

superwiz (655733) | about a year ago | (#44024203)

If your code needs comments, it needs re-factoring. If the code is not self-documenting, it's worthless.

Re:Try and error (1)

drolli (522659) | about a year ago | (#44024303)

Yea. Sure. Ideally speaking, yes. However i found one line about hte intent of creating a function not too much. But yes, breaking it down *is* refactoring (Could still be that you arrive at a function which is so fucked up its better to start from zero than to break it down)

Add Comments (0)

Anonymous Coward | about a year ago | (#44024119)

Add comments to the parts that aren't clear as you're reading through the code.

Two steps (1)

michaelmalak (91262) | about a year ago | (#44024127)

Two steps:

1. Make an act of thanksgiving that you're not dealing with code written by someone trained in FORTRAN, where all variable names are two characters long and all function names are six characters long. "You can write FORTRAN in any language." If you do happen to be dealing with FORTRANesque code, give up now.

2. Become familiar with the idioms of every programming language, of every programming paradigm (structured, object-oriented, functional, event-driven, dataflow, etc.), and of every programmer educational background (high school/self-taught, CS degree, startup pressure cooker, etc.). If you don't have time to do that prior to starting on the current project, then let your attempt to reverse engineer the current project serve as a building block for the next time.

Kno your languages (1)

paysonwelch (2505012) | about a year ago | (#44024157)

The first thing is that you need to know the language you are working in. So if you are coming from a C background, it's similar but you should pick up a book on C++ (or whatever language you happen to be working in). Secondly it takes practice. Every day I am working with other people's code to fix problems. Once I find the problem area I have to sit and digest what's going on line by line, and usually add comments, where were not there to begin with. Lastly learning how to effectively read other people's code is one THE BEST skills you can have as a developer. Anyone can read their own code but to work as a team you need to be able to read other people's code and not get turned off by it. Small rant, most people who can't read other people's code seem to think that no one else knows what they are doing and that their code is sacred and they are the best coders ever, which is rarely the case and usually the opposite.

Write Tests (1)

GiganticLyingMouth (1691940) | about a year ago | (#44024187)

Write unit tests for the code and develop a regression test suite for it. This in itself can help you understand what's going on, but then also when you later start re-factoring or changing the code, you can be sure you're not breaking other parts of the code in subtle ways (or at least if you do break it, you'll know sooner than later). This will also help anyone else who might contribute to the project. Your mileage will vary depending on the size of the code base of course.

make it move (4, Insightful)

superwiz (655733) | about a year ago | (#44024197)

It's just how your brain works. It's a lot easier to examine a piece of mechanical machinery when it's in motion. You notice more. Do the same with the code. Run it. Run components independently. Put plenty of log statements or if it's feasible, watch under a debugger. But don't try to look at stale code just sitting there. You'll notice more as it moves.

i usually start with the beginning (0)

Anonymous Coward | about a year ago | (#44024235)

just sayin..

Is it under version control? (0)

Anonymous Coward | about a year ago | (#44024333)

If it's under version control I would go with the commit history to see what they were thinking as the project progressed.

King's route to mastering algebra ... (2)

Kittenman (971447) | about a year ago | (#44024389)

This calls to mind the story of the king who was in a class for learning algebra, and after realizing it was hard, he took the teacher aside and said 'I'm the king - show me the easier route'.

There's isn't one. Sit down and read it. Then re-read it. Then think. Then read it again. Think again. Repeat.

This is a naive question. (1)

dragonk (140807) | about a year ago | (#44024427)

I would start by finding a chair. Seriously. The only way to read code is by reading code. The more code you read the more you realize the futility of any method other than -- sitting in a chair and reading the code.

Re:This is a naive question. (0)

Anonymous Coward | about a year ago | (#44024647)

exactly.

you can read it through linearly.

or follow call chains until you know some of the lower functions well

or just scan it through quickly and shop when something looks a little funny and dig into why its that way

or just pick up a bug and focus on that, the next one wont take quite as long

or most likely, do all of those things and over time you develop an understanding of the codebase

pure magic

Free ebook: Object-Oriented Reengineering Patterns (0)

Anonymous Coward | about a year ago | (#44024431)

This free book by Prof. Serge Demeyer gives a good introduction to software re-engineering.
Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz, "Object-Oriented Reengineering Patterns," Morgan-Kaufman, 2003.

The book is available as free .pdf download the author's page: http://win.ua.ac.be/~sdemey/
http://www.iam.unibe.ch/~scg/OORP/OORP.pdf

print statements (2)

decora (1710862) | about a year ago | (#44024553)

print statements are the greatest debugging tool ever invented.

it will work on any piece of code, any language, any type of situation. you can trace anything.

UML (1)

eggstasy (458692) | about a year ago | (#44024565)

Well, if it's not documented, write the documentation. Skip the automated crap. You need to do this yourself in order to ensure that you understand it.
That's why people take notes in classes, etc.
I'd start with a class diagram, some sort of high-level flowchart, and grouping modules into layers.

Be aware of object oriented code (0)

Anonymous Coward | about a year ago | (#44024597)

If you only have done C but no C++ or Java, there is one important thing you will have to learn: Interfaces between code. Codified as object hierachies and in headers. If you know C you will think: so my interfaces are just what the code does and what information it needs, so from reading the interfaces I know the code, and you could not err more. Due to the overhead of C++ and Java classes the interfaces are some entity of their own. They cannot be simply changed and usually will be there earlier than the code. So you will see interfaces that lack essential information that code will get elsewhere, interfaces passing information not needed. You will see "glue code": some code only written to make code behind one interface talk with code between another interface.You will find modules that interface with nothing else but glue code. You will find so many classes doing nothing (except connecting other classes that could not be rewritten to talk to each other) that you will end up needing some source code browser just to navigate the class hierachies. And no, this is no sign of bad C++ code, that is inherent to the language and if you dive into some bigger C++ or Java project, it will inevitably look like this.

Build it and run it (3, Insightful)

Java Pimp (98454) | about a year ago | (#44024613)

You will never fully understand the code just by reading it. My approach is to ignore all of it until something needs to be changed. When you need to change something, add a feature, etc... find where in the code the functionality is and tweak it a bit. See what happens. Tweak it some more. See what breaks. You will start to get a deep understanding of a focused section of the code and not have to worry (yet) about other unrelated areas. Start with small changes first. Larger changes may require a deeper understanding of the architecture and how pieces interact. This will come in time. After a few iterations of this and you will eventually become intimately familiar with all the pieces of the code.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...