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: Best Programs To Learn From?

timothy posted about 3 years ago | from the besides-aa-of-course dept.

Programming 329

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?

cancel ×


Sorry! There are no comments related to the filter you selected.

The kernel (0, Funny)

Anonymous Coward | about 3 years ago | (#37340872)

Off you go

Re:The kernel (0)

Anonymous Coward | about 3 years ago | (#37340896)


Re:The kernel (5, Insightful)

kthreadd (1558445) | about 3 years ago | (#37340914)

Off you go

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

Re:The kernel (1, Interesting)

Hazel Bergeron (2015538) | about 3 years ago | (#37341442)

No, it isn't. It's been maintained by a sequence of cliques via contributor-mentor relationships and is badly documented, with certain subsystems displaying a horrible lack of orthogonality.

Linux, on the other hand, is well worth studying - it's really been written for practical engineers by practical engineers, arranged and documented so that anyone sufficiently competent can contribute. Don't forget the O'Reilly books on understanding the kernel and writing device drivers.

Re:The kernel (3, Informative)

serviscope_minor (664417) | about 3 years ago | (#37341330)

Um the "kernel" (by which I assume you mean Linux) is not written in C++.

It should be, but it isn't.

I mean, it's full of objects with derivation and virtual functions, and structs on which constructors and destructors have to be called for everything to remain in one peice. Seems odd not to use a language which is every bit as efficient, has a familiar syntax and yet does a large number of common tasks automatically and without errors.

Oh, and the other thing is that linux has the vtable inside the classes rather than a vptr, presumably because they syntactic overhead of a vptr is too high. C++ is by default significantly more memory efficient in this regard.

Re:The kernel (2)

interval1066 (668936) | about 3 years ago | (#37341684)

The Linux Kernel is mostly C, with a little ML on critical parts. I think some modules are written in C++ though, and if you want to do this I think the kernel is not a bad choice and recommenced starting with a simple text driver, you can find examples for this around the net. Start with a simple module written in C, learn how to build it correctly and fit it into the kernel, then adapt it to C++, then publish the source on some web site. Presto- you've just given back. Then tackle a real task, maybe a usb driver to some fob or doohickey. Move on from there to ... i dunno, contributing to some oss robotics thingy.

Re:The kernel (0)

Anonymous Coward | about 3 years ago | (#37341616)

I just wants to know who writes the funny little messages next to the title of the submission. AA? Rich!

Pick small libraries/utilities (4, Insightful)

Nethemas the Great (909900) | about 3 years ago | (#37340890)

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:Pick small libraries/utilities (2)

Garridan (597129) | about 3 years ago | (#37341320)

I'd suggest the opposite. Most often, a small library is written and maintained by a single developer. There are relatively few bugs to be found, so you can only add features. The developer of the project might not be keen on the features you want to add (especially if you're an inexperienced developer).

Compare to a large project, like Sage. There are lots of bugs, lots of features on the todo list, and an active, thriving community. There's documentation and community support to help new developers get started on the project, and a "beginners" tag that gets used in the ticket system.

Re:Pick small libraries/utilities (0)

Anonymous Coward | about 3 years ago | (#37341436)

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.

Like Qt [] .
See, that's the smallest - only two letters :)

Seriously, Qt Creator is an IDE that may make me switch from C# to C++. It is fast, runs on almost every platform, and is available under LGPL so it's possible to develop both open and closed source projects that use it.

Write a large project yourself (2, Insightful)

Rakshasa-sensei (533725) | about 3 years ago | (#37340908)

Nothing more to it, the gradual expansion of your own project will teach you the techniques you need... or you'll drown.

Re:Write a large project yourself (2)

Octorian (14086) | about 3 years ago | (#37341224)

And as your codebase grows, I strongly recommend taking breaks to read books on design patterns, clean code, unit testing, etc. Without learning the various architectural techniques out there, any codebase will devolve into spaghetti the moment you try to implement any mildly interesting features. However, you won't see the obvious need for those techniques until your project reaches that point.

Re:Write a large project yourself (0)

Anonymous Coward | about 3 years ago | (#37341288)

...And do it in Java because submitter will most certainly drown, because he sounds like he took one intro to programming class (which happened to be taught in C++) and thinks he's a badass. Just he wait until he sees those tangled messes of typedefs and preprocessor macros and pointers and references and overloaded operators and rude, elitist FOSS zealots telling him to GTFO.

-- Ethanol-fueled

Re:Write a large project yourself (1)

elsurexiste (1758620) | about 3 years ago | (#37341298)

That was the whole point of this question: he wants to learn from master practitioners before making mistakes i.e. drowning.

camservo: I don't know of a particular program to learn, but I found great pleasure reading the JVM's source code. I do recommend to be suspicious of everything you read. You may find code that doesn't look right, e.g. excessive use of Header Interfaces [] . The best thing to do is ask other people why they used it there.

Re:Write a large project yourself (1)

denshao2 (1515775) | about 3 years ago | (#37341602)

I definitely agree with this. I have learned far more by creating my own projects than I have from taking classes, reading books, or reading other people's code.

Bad answer (1)

Anonymous Coward | about 3 years ago | (#37341686)

Obviously doing stuff on your own is a good way to learn, but 1) it is certainly not the only way to start 2) HE ALREADY SAID HE WANTED TO DO THE OTHER THING.

Learning by maintaining someone else's existing code is not stupid. It isn't. Really. It's not even stupid, even if the code you're maintaining is bad. You can learn good things from bad code. And you can learn good things from other people.

Really good question. (5, Insightful)

Georules (655379) | about 3 years ago | (#37340932)

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. (3, Insightful)

Nethemas the Great (909900) | about 3 years ago | (#37341058)

If you want to really help start with QA testing and filing bug reports. Graduate to identifying the bug in code (and reporting your findings). Graduate from that to actually fixing these bugs and submitting the fix. Not only will you be helping the project but in the process you will be making connections and establishing yourself with the development team. Very few groups will give you the time of day if one day you--a total unknown--just happen by and drop a bunch of code in their lap.

Re:Really good question. (1)

dkleinsc (563838) | about 3 years ago | (#37341450)

The other way you can win some trust is in the realm of documentation. For instance, if you discover (via code) that there's some incredibly useful option that's mentioned nowhere in the docs, you can write a blurb on it and see if they're interested in adding it to their online docs.

Re:Really good question. (2)

swan5566 (1771176) | about 3 years ago | (#37341128)

Agreed. This is an ancient, ongoing problem with FOSS, and IMO the #1 area they could do themselves a huge favor by improving. I mean, they cheer any anytime someone joins and contributes to the FOSS bandwagon, and boos anytime someone succumbs to "the man". It's baffling how they can't seem to put two and two together a lot of the time.

Re:Really good question. (1)

Garridan (597129) | about 3 years ago | (#37341236)

This is something really nice about Sage. There's a strong community that does a lot of hand-holding, and we frequently convene at "Sage Days" where there are always a few new developers. We set 'em up with an account on trac, teach them how to use mercurial queues, build Sage, etc. Most importantly, we mark tickets as "beginner" tickets that don't require deep knowledge of the project.

Re:Really good question. (4, Insightful)

LateArthurDent (1403947) | about 3 years ago | (#37341290)

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.

Re:Really good question. (0)

Anonymous Coward | about 3 years ago | (#37341378)

Small issues are a great place.
I've submitted a few tiny bug patches.
Some where small typo type bugs, others were wrong default configurations for some devices, added USB identification tags.

Nothing big, but it was a bug I experienced, I patched it locally, but by pushing it upstream I never had to repatch my own version with the same fixes.

Just from a personal laziness it made sense for me.

Re:Really good question. (1)

LateArthurDent (1403947) | about 3 years ago | (#37341566)

Nothing big, but it was a bug I experienced, I patched it locally, but by pushing it upstream I never had to repatch my own version with the same fixes.

That's exactly the type of thing I advocate. Not only does it mean that things work better for you, but you also get this nice sense of satisfaction from knowing you've contributed something to the whole, instead of just using the work from others. It's a valid sense of satisfaction too. Even if you don't become a regular contributor, you've given back something that was valuable.

Also, if you start off like that and if you keep submitting small patches to the same program, you start to become more and more familiar with the code, from simply performing the exercise of looking around for the cause of your problem. Eventually, submitting larger patches will be easily within your reach, if that's what you want to do.

Start with slashcode (3, Funny)

Anonymous Coward | about 3 years ago | (#37340934)

And then do the opposite.

Works every time.

Re:Start with slashcode (0)

Anonymous Coward | about 3 years ago | (#37340984)


Start with the advice of Slashdot posters, and then do the opposite.

Re:Start with slashcode (1)

cforciea (1926392) | about 3 years ago | (#37341304)

And on that note, I'd suggest refusing to give me a bag full of money as a good starting point.

Re:Start with slashcode (1)

2names (531755) | about 3 years ago | (#37341332)

...but if this person listens to you, and does the opposite, which is to not listen to you...GAAAAH! My head esplode.

Easy: Short and Sweet.... (0)

Anonymous Coward | about 3 years ago | (#37340940)


Node (2)

Mensa Babe (675349) | about 3 years ago | (#37340944)

I suggest diving into Node [] . It is written in a very competent way, it's fast, small, efficient, nicely documented, does the IO correctly so no messy blocking function calls and threads synchronization madness, and is pretty young so the code base is not too big for one person to understand. Thanks to npm [] it is also very easy to write modules that are small, clean and have minimum boilerplate code so it's not like writing Java. There is a lot of code to be written so you may find writing and publishing your own useful modules pretty soon. Good luck!

More (1)

Mensa Babe (675349) | about 3 years ago | (#37341174)

One more thing: don't actually look at the npm source [] because it is extremely complicated, just use it as a utility which is easy. For good examples of Node modules to learn from take a look at Connect [] , Express [] , Socket.IO [] , Cradle [] and many other modules [] that you may find interesting. Have fun!

Wesnoth (1)

Digana (1018720) | about 3 years ago | (#37340962)

Wesnoth [] has some of the most beauutiful C++ out there (yes, there is such a thing as beautiful C++). If C++ is what you want to work with, I recommend you start looking at their stuff. Play the game first, of course, so you can start to get a feel for what sorts of things it does. Then you should be able to start guessing where things in the code may be. Step through the code with a debugger too, of course. I find that "ok, I'm gonna try to make the code do this", i.e. starting with a specific goal, setting breakpoints, and stepping through the code is the best way to get comfortable with an unfamiliar codebase, no matter its size.

Re:Wesnoth (2)

pak9rabid (1011935) | about 3 years ago | (#37341126)

Step through the code with a debugger too, of course. I find that "ok, I'm gonna try to make the code do this", i.e. starting with a specific goal, setting breakpoints, and stepping through the code is the best way to get comfortable with an unfamiliar codebase, no matter its size.

Very true. With very large projects, this really is your only option.

Re:Wesnoth (0)

Anonymous Coward | about 3 years ago | (#37341444)

If this [] is an accurate sample of Wesnoth then I have to respectfully disagree. It might be above-average quality for a C++ application, but plenty of middleware libraries are of much higher standard.

Easy! (4, Informative)

aglider (2435074) | about 3 years ago | (#37340972)

For C++ I would suggest Qt [] .
For C I would suggest Minix3 [] .

Re:Easy! (1)

CarsonChittom (2025388) | about 3 years ago | (#37341088)

Can you articulate why you chose those?

Re:Easy! (1)

Octorian (14086) | about 3 years ago | (#37341190)

Qt is very cleanly written and well commented where it matters. Most F/OSS code tends to have no comments of any sort, for some reason.

Re:Easy! (1)

dreemernj (859414) | about 3 years ago | (#37341526)

I've never looked at the source for Qt, but, when I was first looking for how big pieces of software got coded, the MINIX source was easier to read than a programming textbook IMO.

MINIX started as an educational tool and now is also being developed to be an OS for real world use on low resource systems. So it has thorough, useful comments, and it compiles into a stable and usable system. I learned a lot from it.

ALSA (0)

Anonymous Coward | about 3 years ago | (#37340990)

Some of the ALSA utilities are of a nice size to work on. Also, some of the LADSPA filters are a little out of date with respect to how ALSA expects them to behave, and could use some work. AND, they're nice tidy bite-sized.

From stuff I've seen... (3, Funny)

ilsaloving (1534307) | about 3 years ago | (#37341004)

If you want examples of 'real world' programming, take a bowl of spaghetti, add some additional ingredients that you wouldn't normally expect to see in spaghetti, and then fling the whole thing against a wall.

That's what the vast majority of modern day code looks like, especially if the organization that wrote the code tried to outsource the development effort 'to save money' at some point during the dev cycle.

Re:From stuff I've seen... (0)

Anonymous Coward | about 3 years ago | (#37341186)

You work at crummy companies I guess. The code at the organizations I've been at has been, for the most part, pretty good (Of course with a few crufty corners of crap code that every project has)

Re:From stuff I've seen... (1)

Cro Magnon (467622) | about 3 years ago | (#37341302)

You work at crummy companies I guess. The code at the organizations I've been at has been, for the most part, pretty good (Of course with a few crufty corners of crap code that every project has)

Most of the code where I work is okay, but I've certainly encountered code that I called "spaghetti code with meatballs". Some of it was around for years because everyone was afraid to touch it.

Re:From stuff I've seen... (0)

Anonymous Coward | about 3 years ago | (#37341188)


assemble the first GNU/Hurd distro (0)

Anonymous Coward | about 3 years ago | (#37341008)

You'll be famous. Featured on Slashdot, osnews, etc. every 6-12 months or so.

Re:assemble the first GNU/Hurd distro (0)

Anonymous Coward | about 3 years ago | (#37341260)

The Debian project already have a testing/experimental distro:

They're hoping to release a 'stable' version with the Wheezy release.

Goals? (1)

immakiku (777365) | about 3 years ago | (#37341016)

Why do you want to do this? Are you just curious or trying to get something on your resume? This is an important question because a diversity of advice can be given without knowing the answer to this.

I'm not an expert and probably not qualified enough to answer this question, but in my experience, you can't just start looking at a large project on your own and expect to get anywhere. As an example, any undergrad level OS course will only dig you skin-deep into the Linux kernel. The way I imagine things to work is, someone with more experience in the project you want to work on will help you get started contributing and learning the code base. Alternatively if you use a product extensively and know exactly what you want to contribute and why, you go in with surgical precision and try not to screw it up.

Re:Goals? (0)

Anonymous Coward | about 3 years ago | (#37341364)

Alternatively if you use a product extensively and know exactly what you want to contribute and why, you go in with surgical precision and try not to screw it up.

Since you're probably equally unqualified to give advice to medical students, I was wondering if you too would tell a medical student to practice surgical techniques he is interested in but are probably over his head, and "try not to screw it up"?

And to answer the submitter's question; if you want to read a relevant book about FOSS programming, I would suggest The Communist Manifesto by Karl Marx. (And anybody who mods this post Troll should get a sense of humour!).


Anonymous Coward | about 3 years ago | (#37341026)

Bill Gates created it. Or was in a nearby room or something.

More info here: []

Best Programs To Learn From? (0)

Anonymous Coward | about 3 years ago | (#37341028)

>large open source projects, I never know where to even start to try and figure out how their code works.

Nobody knows where to start reading in a large project. Just ask for an architecture diagram or ask overall questions until someone can be bothered to draw one.

If you want to start programming on "real" projects only now, I'd suggest growing your own new module which you always wanted (maybe just by connecting two already-existing modules from some projects). At least I find it much much easier to learn by growing something new than by changing the existing architecture - that's out of the question until you have a grasp of how things are done in the big _in that one project_. And most of the time you don't need to know the big picture in order to add something new.

Note that C++ is notorious for having more than one way to do it (hah, understatement) so be aware that two different C++ projects can be very VERY different and can look as if they are in another language and/or paradigm altogether.

(Java is much less open-ended and so almost all Java projects look alike, and most Java programs are much easier to read than C++ programs).

As for can-learn-from-C++-programs, look at the Qt framework.

Irrlicht 3D engine (1)

Rogerborg (306625) | about 3 years ago | (#37341048)

Linky [] . It's easy to build, well structured, covers a wide range of discretely organised functionality, has simple demo apps, and you can immediately see the result of tinkering with it.

Graphical Text Editors (1)

bigredradio (631970) | about 3 years ago | (#37341052)

A good place to start might be simple programs for editing text from the GUI. Starting with something like Kjots, gedit, or Kwrite is a good way to see how to build a simple interface and read/write files. Pretty simple and a step up from Hello World!.

Libc++ (0)

Anonymous Coward | about 3 years ago | (#37341070) The coding style is very straightforward and the code is small

The code *you* wrote a year ago ... (4, Insightful)

perpenso (1613749) | about 3 years ago | (#37341076)

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.

Re:The code *you* wrote a year ago ... (1)

Hatta (162192) | about 3 years ago | (#37341462)

This is typical of all creative types. They never like the work they did last year. This has nothing to do with the quality of the work and everything to do with the psychology of creativity.

How Programming Works in the Real World (0)

Anonymous Coward | about 3 years ago | (#37341078)

Beg and scrape and kowtow until someone on the steering committee deigns to allow you commit access.

Within the next twenty minutes you will probably:
-Commit some minor change, like fix a typo
-Cause a flame war over some bug you leave a comment on
-Get your commit stomped by someone submitting a load of useless garbage for other people to clean up

Scratch your own itch... (1)

jafo (11982) | about 3 years ago | (#37341104)

The best program to learn from is the one that you have some idea for improving, something you use and can make better. The first patch I made to open source software was for bash. At the time I was use HP-UX at work and Linux and HP-UX at home. The KSH under HP-UX would do "tab expansion" with Esc-Esc, and it was killing me going between Esc-Esc and Tab (neither worked on the other). I first tried making a macro for it, but found that I had to change the C code to make it work.

So, don't look for the prettiest code to just read -- get in the game and poke at something you use. :-)

If you like music and/or want to DJ, hack on Mixxx (0)

Anonymous Coward | about 3 years ago | (#37341262)

Mixxx [] is an open source DJ mixing program that's pretty easy to hack on (and it's in C++). If you like music and/or have any interest in DJing, Mixxx is definitely something you could look into. Like the parent poster said though, you have to scratch your own itch. If you don't find a C++ project cool or interesting, why bother hacking on it?

Also, don't be shy to ask questions on IRC. Find the IRC channel for whatever project you think is cool/useful and just ask someone which .cpp file you should look on to hack on feature X. You just need the end of the string...

Your Own (3)

clinko (232501) | about 3 years ago | (#37341108)

A tip I always give:
1. Start writing something you want. (It'll keep you interested)
2. Google the SMALLER hard parts (String Parsing, data models, misc functions, etc)
3. Use that code. (No one is going to blame you for copypasta on your own project.)

Eventually you'll understand how the copied code works. After a few projects you end up writing your own version because you're better than "that guy you copied from".

Re:Your Own (1)

dkleinsc (563838) | about 3 years ago | (#37341494)

3. Use that code. (No one is going to blame you for copypasta on your own project.)

Just be careful, if you distribute whatever you come up with in this process, that you follow the licensing rules - if it's GPL'd stuff you're copying, release your stuff under the GPL. If it's BSD, do whatever you want with it. If it's just on a forum somewhere, it's probably public domain and you can do what you want.

I am looking (1)

ifreebudget (2457034) | about 3 years ago | (#37341118)

I am looking for volunteers to help me out with my open source project. Search for it on sourceforge using my nickname. It is java and even has android port if you are interested in programming for that platform. The project field is kind of "unsexy" so I am having trouble finding volunteers to work on it, or maybe my code is so messy that it is scaring people off :)

Start with porting (1)

andrewgilmartin (975221) | about 3 years ago | (#37341120)

I highly recommend working on simply porting an existing tool to a new environment. You will be providing a useful service and learn piecemeal about an implementation style and technique. The more you port the more implementation dos and don't you will learn.

Build Your Own Flight Simulator in C++ (1)

eric31415927 (861917) | about 3 years ago | (#37341146)

I suggest the book: Build Your Own Flight Simulator in C++
I read a version of it over ten years ago, and it helped me keep a perspective on projects.
All the code is spoon fed to you.

Check it out at []

Too bad it's C++ (1)

roman_mir (125474) | about 3 years ago | (#37341158)

Well, if it were C and not C++, I'd suggest this project [] . There are so many concepts involved in database development, that it can give a run for its money to OS kernels, graphics libraries and probably most specialized math/astronomy/healthcare related software.

But it's C.

Re:Too bad it's C++ (0)

Anonymous Coward | about 3 years ago | (#37341404)

Déjà vu.

Re:Too bad it's C++ (1)

greg1104 (461138) | about 3 years ago | (#37341466)

Your message is a confusing. PostgreSQL is written in C, with a few Perl scripts for building the code and some other scripting language bits. Were you trying to say only writing C++ code is worthwhile?

I work on PostgreSQL projects and hacking the source code for a living. The development community has extremely high standards, but there is a pretty formalized process to bring new people up to speed. The recommended way to start is doing patch review [] . Reading a patch that's similar to what you're interested in, and experimenting with it, teaches more of the real-world skills needed to work productively on an open-source project than writing new code does. Testing, code reading, and writing code that's easy to merge are the things new people don't know how to do, things that are critical to working on a real distributed development project. I even went to the trouble recently of writing an entire article on patch cleanup [] due to how often the project was running into issues there from new contributions; that's a very underappreciated skill.

Re:Too bad it's C++ (1)

roman_mir (125474) | about 3 years ago | (#37341560)

Why is my message confusing? The story is about a student who specified he wants to look at C++ projects. PostgreSQL is a good project to look at, but it's not C++. What's confusing here, really?

By the way, when I submit a bug report [] , how do I know if it's ever addressed? Thanks.

Literate Programs (1)

WillAdams (45638) | about 3 years ago | (#37341160)

The program source code type which I've learned the most from has been those which are written in the ``Literate Programming'' style developed by Dr. Donald Knuth to write TeX ( [] ).

The only program I'm aware of written as a Literate Program in C++ and publicly available is the Ynot logic simulator: []


trace startup of mplayer (1)

rzei (622725) | about 3 years ago | (#37341162)

... at least back in the days i was amazed how deep you could bury the int main() {}.

i think that the best one would (regardless of the source code qualities) an open source application that does something you are really interested in, or just find a simple usability problem or a simple bug.

then post your bugreport up on their tracker/mailinglist and offer to help with a patch with a little bit of help.

even if you don't manage to implement it, you might come up with a test case or at least discussion which will help you and the project. during the implementation attempt and/or testcase bulding you will most likely grep through a lot of code, commit logs and comments and might be able to implement your next idea.

if you are not familiar with the project's tools, you will be "wasting" a lot of time learning those while building a testcase/implementation attempt. that time you'll save during your next idea.

remember to start with small ideas. of course selecting a project that is both alive and non-hostile might be a good starting point as well.

What types of projects do you like? (1)

AaronMK (1375465) | about 3 years ago | (#37341254)

I think it would help if you told us what kind of projects you would like to contribute or to learn more about. Are you into OS kernels, IDEs, Ray Tracing, sound editing, etc. Then people might be able to suggest a manageable open source project to your liking (one which you will be more likely to brave through the learning curve), and resources for that specific project.

I suggest NetHack (1)

Ignotus Non Audax (2455806) | about 3 years ago | (#37341268)

After playing the game for some while I began to read the code and found it fun. It's not like the experience when you're reading the Lions' Commentary. Besides it's of moderate size -- a complete game showing how components add up to the whole, but you can also learn from small, fairly self-contained snippets controlling some aspect of the game mechanism or UI.

Getting envolved - its not all about coding (1)

Bork (115412) | about 3 years ago | (#37341282)

There are a lot of little things that have never been cleaned up or standardized. Picking up something could take you a couple of ways; Do you want the understand the of the dynamics of what goes on between people, standardization process ... There is more than just code, there needs to be a direction to what needs to be accomplished.

Take a small thing that might be still being worked on, not to say this is what you should but more as a example,: [] []

There are a lot of little "dangling ends" still out there that needs a bit of help; standards that need to be worked on and other things besides just code work.

Take a Look at CPython (1)

ewsnow (1118665) | about 3 years ago | (#37341292)

CPython's source is easy to find and easy to read. The core dev community has gone to pains to keep it simple. It's also pretty well documented and has a great community in general. You can download the source at or look at it online ( [] ). You make a mercurial clone on your local box for hacking and use bitbucket to host it publicly.

I've found the CPython source to be a fount of knowledge. A great place to start is the devguide [] .

vmime (0)

Anonymous Coward | about 3 years ago | (#37341314)

vmime : very well written open source C++ library

Where to start..? (0)

Anonymous Coward | about 3 years ago | (#37341336)


Start at main (1)

ArtificialPulse (1462259) | about 3 years ago | (#37341350)

I was in the same boat and ended up just looking around on for a project that was interesting. Sort by your language, C++, and pick something in pre-alpha (code is usually smaller). From there, find the "int main" and start following the code, line by line; if you get lost, google it or e-mail the maintainers. Download a copy of the source and start tinkering, break it, and repeat.

one step at a time (2)

MagicM (85041) | about 3 years ago | (#37341354)

1. Find a program that interests you.
2. Find something you want to change about it.
3. Hack away.
4. Find a different program that interests you.
5. Goto 2.

Trying to understand all of the code in a large project may be an impossible task, and it's frequently not necessary if you just want to make a simple change.

how programming works in the real world

There is no such thing. Each project will have its own structure and idiosyncrasies, and even after looking at 10 of them you will only understand those 10, not "the real world" in general.

Experience Is key. (1)

jellomizer (103300) | about 3 years ago | (#37341368)

It is often a bad idea to teach yourself how to program by looking at someone else's code.

1. You are not getting best practices. There are coding guidelines that should be followed but there are always exceptions, and not everyone knows all the rules and will break them needlessly. I am a profession coder with decades of experience... But I am still learning new and better ways to do things and I look back at my old code and I go what the heck was I thinking. And the answer was Oh yea, I needed to get it done and I didn't know about some feature at the time so I had to make this hack to get it to work. Looking at someones code you will get the good stuff mixed with the half drunk, or just a bad day.

2.It is overwhelming. It is more then just being tossed into the deep end, It is being tossed in the deep end with weights attached to your legs. Especially if you new to development and don't know where to start you can see. If you start in the middle you will spend huge amount of time looking at code that does something very minor but with no idea why.

3. You do not have a goal. You can't just look at a program and say I know how it works... You really need a goal to fix something, otherwise you are looking at stuff blindly.

4. Those sneaky 3rd party libraries. Unless you are doing some real low level coding there will probably be references to those 3rd party libraries that will not really let you know how things work.

5. Too much to handle. A computer is a great tool for processing a lot of commands that is often too complex for a human to understand. A programmer rarely ever thinks of how the entire program is programmed only his own little world, or his world at the time. And will often go back to see some code that they written and wonder who written that and when.

If you really want to learn, I would suggest that you start out with giving you a goal project to make.
And search for small examples about the current feature you want to implement. Integrate the examples and alter them see what is happening. Once you get good at making your own stuff, learning the tradeoffs and pitfalls then you can start looking at someone else code to expand off of it. Making new code is easy, modifying others is actually more difficult. That is why I am not a Huge supporter of Open Source Ideals, and more of supporter of Open Specification.

I couldn't recommend this more: (2)

naturaverl (628952) | about 3 years ago | (#37341382) [] (And no, I'm not affiliated - just a fan)

Re:I couldn't recommend this more: (1)

cratermoon (765155) | about 3 years ago | (#37341528)

Also a good choice. I don't own it personally, but I've referred to it at work.

Programming in the Large (1)

Shamanin (561998) | about 3 years ago | (#37341384)

Since the 90s I have been a proponent of reuse, not only internally to an organization, but as interface libraries with a low bar to entry. I found this book to be seminal in identifying issues that show up in large programming efforts and general dependency decoupling for interfacing:

Large Scale C++ Software Design by Lakos

Code Reading (1)

cratermoon (765155) | about 3 years ago | (#37341388)

Take a look at Code Reading: The Open Source Perspective [] by Diomidis Spinellis. I've had a copy on my shelf for years. He covers C++ along with other common languages, and has examples from both very large and small programs.

Small Project, avoid libraries (0)

Anonymous Coward | about 3 years ago | (#37341426)

Look for a small program you use and go check it out. Big projects, like firefox, are going to be hard to get into. And no one is going to hold your hand.

There are thousands of projects with lone developers who would love some outside contributions, even if they have to do a little hand holding.

There are also many projects that were that way but are abandoned (I had one myself) once the developer no longer had time to do it. Picking up one of these can be nice. And you get absurd amounts of appreciation for fixing issues with modern systems.

Avoid libraries. They're hard. The code changes are quite easy, which is why developing new libraries is a blast. Long term maintenance is where the challenge lies. Subtle changes break subtly wrong code and sometimes perfectly correct code: Often, wrong or right, the library user had no way to know because documentation always sucks, no matter how much of it there is (this is one of the arguments for open source libraries). Once you have been programming for a while you might look into helping on library projects.

My advice: don't just look at apps (1)

scorp1us (235526) | about 3 years ago | (#37341428)

Don't go looking for "best programs to learn from." You won't "get" it. Each program has its own focus, and unless you are very interested in the subject matter, you'll just gloss over the important parts. I've worked with tons of other libraries and I always find myself asking "Why the hell can't I just do X" or "Why they hell did they do it this way?" Invariably it was because the library was written with a mindset with a better understanding of the topic and contract than my own. When I say "contract" I mean what the library aims to provide.

If you do want to increase your changes of using C++/OOP right, I highly recommend writing C++ using Qt. That is the best best-of-breed library, with an incredible breadth and depth. It is a well thought out, complete API.

Python also has an art to it which is called "Pythonic". Some things are more or less "pythonic" which means driven by the philosophy of the language that reverberates from the operators and APIs.

So I would say rather than just reading someone else's program, write you own using Qt or Python, and let those shape you.

Also, use Model-View-Controller as much as possible. (It is not possible everywhere though)

The only other thing I can advise on a completely general principal is always separate your data out from implementation. From array dimensions (who dimensions arrays anymore rather than use a STL like class? Static dimensioning makes it easy to exploit your code.) to constants and up to variables, keep that separated, because constants do change. Not often, but they eventually do.

Online Judges are useful up to a point (1)

nroets (1463881) | about 3 years ago | (#37341482)

On sites like there are plenty of easy questions. It's a good way to learn the basics, like sorting, input and output, because the judge will test your program for all the possible newbie mistakes.

Unfortunately, there are very few judges that will force you to use certain libraries (STL, boost, etc) APIs or language features (e.g. inheritance).

Here's my method (1)

whitroth (9367) | about 3 years ago | (#37341486)

Pick any project that's not *too* huge, and preferably not GUI, because that adds many more layers to try to understand. What I do, when I've started new jobs, was to look at the main{}, and see what it does, to try to get an overview. Then I'll look at whatever calls I need to understand for what I've been asked to work on. I'll continue working at the highest level, until I get to what needs fixing or enhancement: that way, I try to avoid breaking something else by seeing where the changes will correctly fit.

If you find spaghetti code - one function hundreds of lines long, if it's not moving 5,543,540 fields, go elsewhere. Or rewrite it modularly. Correct modular code does *one* thing well, not 5 things confusingly. That way lies maintenance hell (as I like to say in interviews, job security is *not* "never let them know what you're doing", it's if I get a phone call at 16:45 on a Friday, or 02:15 some day, I do *not* want to spend hours figuring out how clever I, or someone else, had been a year or two before; I want to solve the problem and get back to leaving or sleeping).


Good luck with that (4, Insightful)

ultranova (717540) | about 3 years ago | (#37341506)

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:Good luck with that (1)

Short Circuit (52384) | about 3 years ago | (#37341588)

That's true, if the program was poorly architected from the outset. In my experience, it's very unusual to encounter someone abusing operator overloading in ways that aren't very localized, or are otherwise counterintuitive.

C++ allows you to do bad things, but if you're playing with anyone but yourself, there are threats of physical harm to consider before you make life difficult for everyone else.

Re:Good luck with that (2)

Rakshasa-sensei (533725) | about 3 years ago | (#37341698)

That's probably the most retarded piece of advice I've seen; congratulations on managing to take a lot of C++ FUD and turning it into 'helpful advice for a newbie'.

Plugins/modules (1)

Chris Hodges (670481) | about 3 years ago | (#37341508)

An AC above suggested ALSA modules, but many other projects accept plugins (my first thought was the GIMP, but that uses python). Pick something that you're interested in and write something that solves a problem with that. If it's a discrete module or a plugin you'll have more chance of deploying it.

Apache Traffic Server (0)

Anonymous Coward | about 3 years ago | (#37341512)

one of the biggest C++ project in the world? former 700K LOC property codes, now opensourced at about 300K LOC, a full functional enterprise cache/proxy production. include all kinds of cool things related to high performance server technical: C++(no STL lib) Continuation StateMachine FileSystem ClusterCommunity ...

If you're looking for a big project... (1)

Short Circuit (52384) | about 3 years ago | (#37341544)

...take a look at the source code for Luminance-HDR. While it's buggy, I've been pleasantly surprised at how well-organized it is, and it should prove to be very hackable.

Minix, OpenBSD (1)

Dr. Smoove (1099425) | about 3 years ago | (#37341552)

I suggest download the Minix source and using the git portal for the OpenBSD source: git:// You can learn a lot from looking at simple tools like ls, and then looking at system libraries as well. And yes, I know it's not C++.

mediawiki (1)

XaXXon (202882) | about 3 years ago | (#37341590)

I'm not a big PHP fan, but I had to dive into mediawiki and found it to be very well organized. It made me realize that PHP didn't have to be bad :)

Two good projects based on C++ (0)

Anonymous Coward | about 3 years ago | (#37341614)

You could try either working with KDE applications/framework, or QT library itself. Both are based on C++ and there is a good amount of samples out there

My Advice: Don't Bother (1)

Anonymous Coward | about 3 years ago | (#37341674)

I seem to be in the minority in this regard, but in my opinion looking at source code to try to become a better programmer is a waste of time. Looking at the source code of a large project is just a bigger waste of time. Writing code is 10% what you're doing and 90% why you're doing it. Looking at code will tell you what it's doing, but it won't tell you why it's done that way. Add on top of that the fact that every developer has his/her own style and conventions and you're just adding more wasted effort trying to get to the "why" of the code. There's simply better ways to learn how to code.

Save yourself the hassle and go here [] instead. This book contains a wealth of information about building and working on large codebases (all open source), written by the developers themselves. This will cut through the boring bookkeeping that is 90% of writing software and get to the heart of why they are written that way.

Start at an Interface (0)

Anonymous Coward | about 3 years ago | (#37341708)

For the most part, It doesn't matter what program you look at. Any large FOSS project is going to represent thousands, tens of thousands of hours of work. You can't expect to pick it up at a glance. The thing to do is to start at an interface, a device interface, a GUI button, something where you can easily understand what the goal of the code is. You might look at the firefox code and go look for the top level code for file->open. It'll take you a while to find, and it will be in at least a couple different places. But from there, you just work down through the call stack to find out how it gets its work done. After you understand that, you'll have your foot in the door. Then rinse and repeat.

PostgreSQL (0)

Anonymous Coward | about 3 years ago | (#37341728)

PostgreSQL is, in my opinion, the best example of a large, open, successful project. It's codebase truly reads like poetry, it's incredibly well-engineered, and its community is smart, welcoming, and open. It's written entirely in C (the core of it, anyway) but it's what I have recommended to friends and colleagues for years as the starting point from which to begin to understand large program architecture. It's been a shining example since 7.3, and it's gotten measurably better since. I'm not involved in the community but have observed it from afar for a long time (shame on me in that regard).

QMail (1)

CynicTheHedgehog (261139) | about 3 years ago | (#37341740)

I suggest QMail. The code isn't that big, it's well written, and it's modular (lots of executables calling other executables). I wrote some authentication plugins for it about 10 years back and as I recall it wasn't too hard to figure out what was going on.

Start with Documentation (1)

codepigeon (1202896) | about 3 years ago | (#37341756)

Something to help you get started could be to try to clean up the code, add comments, and try to create documentation. There is a nice utility for generating developer documents here: []
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?