Ask Slashdot: Best Programs To Learn From?

First time accepted submitter camServo writes "I took C++ classes in college and I have played around with some scripting languages. We learned the basics of how to make C++ work with small programs, but when I see large open source projects, I never know where to even start to try and figure out how their code works. I'm wondering if any of you have suggestions for some nice open source projects to look at to get an idea for how programming works in the real world, so I can start giving back to the FOSS community." Where would you start?

Comments

Pick small libraries/utilities

[Nethemas the Great]

The more lines of code the more difficult to get started as a general rule. Just find a small library that provides support for something you have an interest in. Tinker with it.

Re:The kernel

[kthreadd]

Off you go

Oh yeah, Good ol' BSD kernel. The best one in town.

Really good question.

[Georules]

I have often wondered the same thing. People tell me, "read the code and submit patches!" It may sound like hand-holding to experienced developers, but many new coders could really use an introduction to becoming a part of a community around a project.

Re:Really good question.

[LateArthurDent]

I have often wondered the same thing. People tell me, "read the code and submit patches!" It may sound like hand-holding to experienced developers, but many new coders could really use an introduction to becoming a part of a community around a project.

I wouldn't call myself an open-source developer by any means, but I've submitted patches to open source projects on occasion, and it wasn't too hard, even back when I had no experience with any large program. The trick is in the approach. Here's my recommendation:

Don't just download the code and start reading trying to figure out how everything works. That's when you drown in too much information, become frustrated, and decide you can't do it. It's a large, complex program. If you don't have a purpose, you can't navigate it. Instead:

1. Find an open source program which you use and like. This helps keep you interested.
2. Pick some small bug that annoys you, or a small feature you wish your pet program had that it does not. Emphasis on small here, you don't want to commit yourself to rewriting large portions of code. First, that would be overly challenging; second, the main developers of the project are unlikely to trust a huge infusion of code from someone who never contributed before, unless you can show that it really kicks ass. That's going to lead to a lot of talking back and forth, when you really just want to code.
3. If your program uses an issue tracker, go there and see if your bug / feature is listed, and if anyone else is working on it. If so, you can post there and offer to work with that person, if they're willing to help you out. This can also save you headaches, as the posts might explain that the simple bug you've chosen has an underlying complex reason which makes it a hard to solve problem.
4. Try to find the location in the code responsible for the small area which you want to change. Knowing your way around gdb or a frontend to gdb can be helpful here.
5. If you start getting lost in the code and can't find what you need, contact a developer, tell them what you want to work on, and ask if they can lead you in the right direction as to where in the code you should be looking at. I generally find that it's a lot easier to ask a developer a specific question about a specific problem than a generic, "how can I help out?" The latter will typically get you a response such as, "check out the issue tracker, pick something, and go for it." It's a good answer, but it feels daunting for a beginner. So contact the developer with a purpose and specific questions, and they'll generally be extremely helpful in guiding you through your problems. If you've demonstrated that you tried to read the code on your own first, they'll also be much more likely to take the time to offer you more detailed guidance.

The code *you* wrote a year ago ...

[perpenso]

Besides looking at the code of others be sure to look at the code you wrote a year ago and haven't looked at since. You should learn something about good comments and documentation. You probably will have ideas on how to better implement things. There is some truth to the notion that programmers don't really like the code they wrote for a project until they have thrown it out and rewritten it from scratch for the third time.

Good luck with that

[ultranova]

I took C++ classes in college and I have played around with some scripting languages. We learned the basics of how to make C++ work with small programs, but when I see large open source projects, I never know where to even start to try and figure out how their code works. I'm wondering if any of you have suggestions for some nice open source projects to look at to get an idea for how programming works in the real world,

I think you already do.

This is the difference between C and C++: in C, whatever the code of a function says it does, it does; in C++, whatever the code of a function says it does is subject to be changed by templates, operator redefinitions, etc. Because of this it is impossible to make small changes without reading and understanding the entire codebase first.

Basically, if you want to get involved in a large C++ project, you either have a tour guide or very good documentation or make the huge investment of learning the entire superstructure of the program before making any changes to any part of it. It's kinda interesting how C++ encourages this kind of greater dependency between different parts of a program than C.

Re:The kernel

[walshy007]

Um the "kernel" (by which I assume you mean Linux) is not written in C++. It should be, but it isn't.

There are reasons the kernel doesn't have any c++ in it (link is about git, but same deal for the kernel).