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

The kernel

[Anonymous Coward]

Off you go

Re:The kernel

[Anonymous Coward]

seconded

Re:The kernel

[kthreadd]

Off you go

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

Re:The kernel

[serviscope_minor]

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

[Hazel Bergeron]

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

[Anonymous Coward]

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

Re:The kernel

[interval1066]

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

[BenoitRen]

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.

The special treatment that C++ gives to constructors and destructors makes things harder, though. They don't return any value. If the constructor fails your only option is to throw an exception. But C++ exceptions make code execution slower. Another alternative is to check the object through a method after construction, which a lot of STL objects do, but that's kind of messy.

Don't get me wrong; I program in C++. But this is one of the dilemmas that I've faced and researched, and I still don't know what to do about it.

Re:The kernel

[Anonymous Coward]

The problem is that many of the C++ features you're talking about really are features in the C++ runtime library and that more or less needs an operating system. Building a kernel with it is absolutely possible and there are examples of that but it's a lot of hazels involved.

Re:The kernel

[ShavedOrangutan]

Maybe you're doing too much in a constructor? You could offload anything that can fail into a method that can return a value.

But I do Java/C#, so I'd throw the exception and tell the customer to buy more hardware.

Re:The kernel

[interval1066]

You don't really want a return value in a constructor, do you? I mean, you can do it, but do you really want to? I take issue with your premise that exceptions make the code slower. Well written exceptions don't add that much to the overhead, and they are the Right Thing To Do with regard to OOP. Return codes are NOT OOP, a throwback to procedural programming. If you stick to OOP principals you don't need to have anything to do with them. Use exceptions and state objects.

Re:The kernel

[serviscope_minor]

The special treatment that C++ gives to constructors and destructors makes things harder, though. They don't return any value. If the constructor fails your only option is to throw an exception. But C++ exceptions make code execution slower. Another alternative is to check the object through a method after construction, which a lot of STL objects do, but that's kind of messy.

Well, bear in mind that what was true 5 years ago is not necessarily true now.

The C and C++ non RAII ones are pretty similar in structure:

struct f;
if(!init(f, params))
    return fail;

versus

class f(params);
if(f.fail())
      return fail;

I'm not convinced the C++ one is messier than the C one.

now for the RAII one, there is an interesting thing about speed. The C version has the error logic mixed up in the control logic. Modern C++ compilers put the unwinding logic in other pages. The C++ one can be faster if errors are rare, but slower if errors are common.

Exception enabled code used to be slow, especially in GCC. These days it is much faster.

Re:The kernel

[serviscope_minor]

Maybe you're doing too much in a constructor? You could offload anything that can fail into a method that can return a value.

That's kind of the point of a constructor. If it *has* to be called to make the object valid then putting in the constructor makes it impossible to forget.

But I do Java/C#, so I'd throw the exception and tell the customer to buy more hardware.

Not even that. Whole classes of bugs simlpy won't happen, leaving more time to optimize the rest of the code.

Re:The kernel

[b4dc0d3r]

I finally found you. I hate you. Not personally, but this kind of thinking. A TCP class raises a disconnected exception, the stream class raises an interrupted exception, the object class raises an error exception, and the application says "There was an error." What kind, and how do I fix it?

OOP error handling and code reuse can be done well, but it generally is not. The basic idea of a "return code", giving some sort of information or context about the error, is very important. Even if it's just preserving the exception information to bubble up.

I've collected probably a hundred Microsoft-specific error messages that don't mean what they say they mean. They add helpful text to say what you might fix, but that's a red herring. There is an underlying error which is caught but not bubbled up, and it leaves the user with little or no idea what to do.

You have to have the idea, if not the implementation, of returning something to the user.

And, I take exception to your assertion that exceptions don't make the code slower. Each class wraps its code in try/catch and has to deal with fairly complicated Exception objects in many cases. Did the file open? fopen() returns null, and you can get more information if you want it. OOP says you have to make an exception object and run catch code, and go up the stack and to the exceptions there.

Code that experiences no exceptions will not be noticeably slower, but code that relies on exception processing to try alternate methods or re-try will be a lot slower. This from someone who looks at C++ code at the (dis)-assembler level.

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).

Re:The kernel

[interval1066]

1) Return codes used in a appropriate way, please. Not saying they Are Not useful at all, but should be used sparingly. 2) I don't do Microsoft, so I'm not going to defend what they do. 3) I've found dealing with exceptions to be easier. WHAT classes do in a "complicated" way? That's like saying ALL cars implement the transmission in a "strange and mysterious" way. I've not found that to be the case. If you're stuck in a procedural mindset then you're probably going to find exceptions strange and mysterious. Too bad. 4) So, you've found me. Tag, you're it.

Re:The kernel

[serviscope_minor]

The Linux Kernel is mostly C, with a little ML on critical parts.

Surely you mean assembler, not ML.

I think some modules are written in C++ though,

You sound pretty arrogent to me...

I there are a few C++ modules, but a very few, due to the terrible and bizarre attitude of the kernel developers, who seem to want to insult users of C++, then purposfully make life more difficult, then finally spread the entire issue 3 feet deep in FUD.

Re:The kernel

[interval1066]

Trying to turn a rather reasonable post into some kind of battle? You sound like you need help to me.

Re:The kernel

[BenoitRen]

Those are quite bad and biased reasons. So it's basically C elitism. Let's all ignore that C has problems of its own.

Re:The kernel

[serviscope_minor]

I'm not sure I follow. Would you care to explain?

If you're upset about the comment about arrogance, I was referring to a thread where a seasoned kernel developer concludes (somewhat oddly) that the only possible reason that you could want C++ in the kernel is because of arrogance. The discussend ends with a giant FUD fest from Torvalds.

It's far more enlightening about the attitude of kernel developers than about anything to do with C++.

Re:The kernel

[Pino Grigio]

There's nothing to stop you from throwing an exception and passing a code into it. I do this with exception objects I derive from std::, for things like FAILED(HRESULT) or glGetError() != GL_NO_ERROR.

Re:The kernel

[Pino Grigio]

Absolutely. That post was an eye-opener!

Re:The kernel

[david_thornley]

To quote the C++0x draft I've got, 18.6.1.1/9: "T* p2 = new(nothrow) T; // returns 0 if it fails". In general, I'd rather use the basic form that can throw an exception, but in kernel programming you might well want to use nothrow.

Re:The kernel

[walshy007]

I had assumed you would have read at least a few of the replies etc.

c++ gives enough abstraction and odd feature combinations to allow people to make functional but a complete pain in the ass to maintain code.

While it can be more verbose, c is comparatively very straight forward, how easy code is to understand and maintain matters.

Re:The kernel

[Anonymous Coward]

You're an idiot. Re-read what serviscope_minor said. He was making a joke that clearly went over your head. Again, it has nothing to do with /your/ arrogance or /serviscope_minor's/ arrogance. The point was that kernel developers seemed to think that wanting to code any part of the kernel in C++ was motivated by arrogance.

Re:The kernel

[dkleinsc]

A TCP class raises a disconnected exception, the stream class raises an interrupted exception, the object class raises an error exception, and the application says "There was an error." What kind, and how do I fix it?

That's because the stream class and object class both did the wrong thing with the exception they got.

What you want to do in an exception handler is fix what you can, and throw up the call chain what you can't. For instance, when the stream gets an indication that the TCP connection was disconnected, they could perhaps try to re-establish the connection, but if that doesn't work it should throw the DisconnectedException it got up to their caller until either something either fixes the problem or the application crashes. But what you don't want to do is take the DisconnectedException, replace it with a different sort of exception with less information about what broke, and and throw that.

In other words, if you hit a hammer against your thumb rather than against the nail, don't blame the hammer.

Re:The kernel

[Pino Grigio]

That's also true of course.

Re:The kernel

[serviscope_minor]

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

Those reasons are so terrible. It amount to:

• C++ is bad because I say so.
• C++ is too easy so it allows in bad programmers and this makes it a worse language.
• C++ leads to worse design choices because I say so.
• The STL isn't portable (which is of course wrong).
• You might get the design wrong in C++ and have to rewrite it where as that is not going to happen in C.
• C++ programmers don't understand low level details.

It's all FUD, BS and lies.

Re:The kernel

[Imagix]

And if the code that *has* to be called to make the object valid fails, how do you prevent that object from being used when it fails? Can't use a return code as the programmer may simply ignore the return code and then blithely try to use the object that is now failing it's invariants. With the constructor throwing an exception, at least the code block that the variable was declared in will be exited, causing that variable to no longer be in scope, and thus cannot be accidentally used.

Re:The kernel

[serviscope_minor]

I was actually taking the time to explain the misunderstanding and to tell you that I wasn't accusing you of arrogance, etc, but I see you'd rather ignore that and flame away instead.

Re:The kernel

[serviscope_minor]

I had assumed you would have read at least a few of the replies etc.

I did, and they're full of crap. You don't have to abstract away everything in C++ (what it is with that obsession with poor C++ programmers??), but it allows you to abstract away the irrelevent crap.

c++ gives enough abstraction and odd feature combinations to allow people to make functional but a complete pain in the ass to maintain code.

Bad code can be written in any language. It also gives you enough tools to make really clear, clean, maintainable code.

While it can be more verbose, c is comparatively very straight forward, how easy code is to understand and maintain matters.

No, not really. By that logic, assembler is easier to maintain and understand since each step is absoloutely blindingly obvious. The trouble is that if you only have tiny steps available, then you have to figure out the original programmer's intention.

Re:The kernel

[interval1066]

I love elitist idiots.

Re:The kernel

[serviscope_minor]

You're weird.

Re:The kernel

[AuMatar]

Exceptions actually add a lot of overhead (it used to be 20%+, I haven't benchmarked in a few years). And while they're useful in some circumstances, they can also lead to a lot of spaghetti code. They also require a very specific form of programming- everything needs to be a smart pointer, or you will leak. In addition, they aren't really all that readable- they're a glorified goto where the label can be multiple levels up. In general they should be avoided, and cases where they are used should be evaluated carefully.

Re:The kernel

[Anonymous Coward]

poor C++ programmers

-1, Redundant

Re:The kernel

[PopeRatzo]

Linux, on the other hand, is well worth studying - it's really been written for practical engineers by practical engineers

You say that as if it were a good thing.

Re:The kernel

[Spykk]

Return codes are great until your function needs to return something useful instead. Now you have to allocate a pointer and pass it into your function and everything gets much less intuitive and elegant.

Re:The kernel

[Hazel Bergeron]

You make a fair point. Linux isn't a particularly theoretically interesting or elegant design. But at least studying it gives you a taste of practical, functional engineering. A lot of "why did you do it like that?" comes down to "because it works on all platforms and it's fast".

Studying one of the modern BSDs is a lesson in what happens when you devolve one code base into several competing platforms each of which wishes to maintain an air of exclusivity. Perhaps it's productive for an advanced coder to try to get to grips with one of them to see what happens when social engineering mets software engineering, but it's really not helpful for the beginner to do so.

Re:The kernel

[Spykk]

I've never understood this argument. Poor programmers can write unmaintainable code in any language, including C. If we judged the maintainability of each language on the worst examples we could find they would all be terrible.

Re:The kernel

[Man Eating Duck]

You sound pretty arrogent to me...

I there are a few C++ modules, but a very few, due to the terrible and bizarre attitude of the kernel developers, who seem to want to insult users of C++, then purposfully make life more difficult, then finally spread the entire issue 3 feet deep in FUD.

Woa, that was a fun read :) *scratches zinged eyebrows*

Re:The kernel

[emt377]

Exception enabled code used to be slow, especially in GCC. These days it is much faster.

Yes, exception-enabled code is fast, until you actually have to process an exception. Merely enabling exceptions typically also doubles the footprint of code, without a single actual exception handler or exception thrown, simply because the compiler has to emit cleanups to unwind each and every stack frame, from each and every scope, in case an exception *is* thrown somewhere. Code to actually work with exceptions then add on top of this.

Given the outrageous expense of processing exceptions, anything that resembles normal or non-exceptional should never be handled as an exception. This includes things like TCP FIN (*all* connections end with it), EOF, poll timeouts, event processing (yes, I've seen it done!), not to mention regular C library and syscall error returns. I've seen people wrap things like mkdir() with an error check that throws an exception if it returns -1. Well, the program that used the wrapper of course used mkdir() all over the place just to make sure a directory existed (and to create it if didn't). So it got an exception in the TYPICAL case. Every call point was then wrapped in an exception handler that, well, did nothing! I consider that borderline incompetent. But I digress. On the other hand, the things that really ARE exceptional - heap corruption, out of memory, deadlock detection, out of file descriptors, thread creation failure, unmounted root fs, kernel resource errors, etc, etc - there's nothing to be done about. And any attempt to do anything at all will likely aggravate the problem. In the case of say a heap corruption, or stack overflow, it's unlikely that attempting to process an exception is going to do anything more than crash. And serve only to make it harder to debug because it crashed somewhere in a runtime routine that walks a table with links to procedures to unwind the stack, not the place where it was actually first discovered. You're IMO better off simply calling a panic routine that stops then and there rather than attempt to do anything else that would only aggravate the problem further (possibly leading to real data loss - "oh, a corrupt heap... lets try to save the document before bailing" or similar brilliance). Between the two, and given the footprint overhead and the inevitable abuse in the absence of adult supervision, it's best not to use them at all. The sliver of cases between the two where exceptions are useful is so narrow that it's no longer meaningful formalism.

Note that you typically don't get away from the error check of a return value. Instead you move it further down the tree, to the position where you conditionally throw the exception, instead of at the return of the function. The difference is there, but trivial.

Re:The kernel

[emt377]

By the way, I prefer your latter version for C++. Constructors really shouldn't do anything that can fail gracefully. A separate init() method encourages reuse of objects, making it easier to make them members by reference or value.

Re:The kernel

[emt377]

Oops, meant former, the f.init() version.

Re:The kernel

[pclminion]

But C++ exceptions make code execution slower.

They do not. Exceptions improve performance by moving error handling code out of the main path of execution, increasing instruction cache effectiveness. They also eliminate all the instructions necessary to check function return codes, and defer error handling to the moment an error actually happens. Given a good implementation of the exception mechanism, they are nothing but win.

You can get into trouble when you start using try{}/catch{} blocks in complicated ways, particularly, nesting them inside each other. This is always a sign that you've designed your code wrong. try{}/catch{} should be used only to make decisions about what to do when an exception happens. All other sorts of stuff that needs to happens when an exception is thrown, such as deallocating containers and releasing resources and so on, should have been handled using proper RAII techniques without any try{}/catch{} at all. A well-designed program that uses exceptions may have literally hundreds of throw statements per try{}/catch{} construct, perhaps more. If you are writing try{}/catch{} all over the place, you don't know how to use C++ effectively.

The real downside to using exceptions, particularly in embedded environments, is code bloat. Most implementations use (rather large) object lifetime range tables to figure out which objects must be destructed, and in what order, when an exception is thrown.

Re:The kernel

[Archwyrm]

Here's some more FUD, BS and lies from other people who, like Linus Torvalds, don't know what they are talking about and have zero credibility.

Re:The kernel

[sapgau]

+1 Please mod up.

This is showing two very different ways to look at the problem. I agree with delegating to another component to handle a system wide error and raise the exception already!
Stop "optimizing", you've got bigger fish to fry.

.

Re:The kernel

[Anonymous Coward]

Who did you buy that account from, whippersnapper?
You have a lower ID than the person you are replying to and yet you don't know that we used call "assembler" machine language.
By the way, assembler is the program you use for assembly. Try assembly language next time.
Oh, and your spelling of arrogant reminds me of rogue-likes for some reason.
No wonder you think C++ is something to develop Operating Systems in.

Re:The kernel

[bzipitidoo]

Spaghetti code is pretty much gone because, except for rare grumbles about things like "multiple entry points" and that an assembler expert can still write more efficient code than a compiler, Structured Programming is clearly superior.

OOP, the next generation paradigm, has not displaced Structured Programming in any way close to the same extent. Why? Because it's not unequivocally better. Doesn't help that C++ is an especially poor realization of OOP. Name mangling? Templates? No automatic garbage collection? iostream? But those are only details. The major problem is with OOP, not C++. Class hierarchies can impose structure that is both unnecessary and detrimental. To avoid that, one doesn't use it. But then you have to ask yourself, why even use an OOP language? Polymorphism is cute, but it sure looks lame next to what Functional Programming can do.

Re:The kernel

[Anonymous Coward]

Functional programming is new (relatively, at least with regard to OOP), functional is superior in some regards, not knocking it, and fp is a superset of oop anyway. There your not comparing apples to oranges, but apples to granny smiths.

Re:The kernel

[Anonymous Coward]

You're the fucking idiot who doesn't understand that nobody was calling you arrogant.

If you'd like to be insulted, I'm happy to tell you how much of an idiot you are for getting ML confused with assembly.

Re:The kernel

[jjohnson]

code that relies on exception processing to try alternate methods or re-try will be a lot slower

If you're doing it this way, you're doing it wrong.

By definition, an Exception is something you don't expect to happen, even sometimes. You guard against it for the same reason that you check your return code in C even if you're certain the call will succeed: Because sometimes shit happens, and robust code demands that you fail gracefully when shit happens. Your catch code isn't for "oh, that didn't didn't work, let's try this", it's for "something happened, that, if I don't deal with it somehow, will crash my program." It's for "I'm bailing out because there's no reasonable way for me to continue." That programmers misuse Exceptions is an observation about programmers, not an indictment of the architectural reasons to use them.

Re:The kernel

[jjohnson]

Yes, because argument by soundbite works so well to establish policy. Just look at Washington!

Re:The kernel

[walshy007]

Because context-free grammar is a bad thing and having undecidable grammar is such a lovely feature where you can have no idea what a specific piece of code does (sarcasm).

Re:The kernel

[walshy007]

Well, undecidable grammar (example)r is certainly a lovely feature c++ has that c does not (sarcasm)

Even horrible c code can be understood if you just sit there looking at it for a bit. That in c++ it is possible for that to not be the case is a horrible failing.

Re:The kernel

[smellotron]

For instance, when the stream gets an indication that the TCP connection was disconnected, they could perhaps try to re-establish the connection, but if that doesn't work it should throw the DisconnectedException it got up to their caller until either something either fixes the problem or the application crashes.

Please humor my pedantry, but perhaps this is a bad example. A TCP connection is a stream, so any other stream based on a TCP connection is not at the appropriate abstraction level to catch anything. If it's an HTTP connection (with an in-flight GET request that may have been lost), let that layer handle restarting the stream and re-issuing the request. If it's a lossey stream of video data, let that layer restart the stream, wait for the next keyframe to show up in the input, and resume sending new data. I regularly see people writing "adapter" layers such as a TCP iostream wrapper and trying to handle exceptions when it is wholly inappropriate to do so—they should simply guarantee some level of exception safety and then get out.

What you want to do in an exception handler is fix what you can, and throw up the call chain what you can't.

IMHO, what you really want to do is replace the exception handler with a RAII "guard" object that will perform cleanup in its destructor if .commit() has not been called. This gives you all of the benefits of a try/catch block without forcing the try/catch on your parents. Keep in mind that if an exception is thrown with no outer try block, the program may omit stack unwinding and abort with a nice healthy core dump. If a single "middleware" layer inserted a try/catch block with a re-throw, then your stack trace shows up in the middleware's (usually useless) function and the source of the std::out_of_range remains a mystery. (note: this is probably undefined behavior, but it is damn nice and worth leveraging.)

Re:The kernel

[smellotron]

Modern C++ compilers put the unwinding logic in other pages. The C++ one can be faster if errors are rare, but slower if errors are common.

I've looked at this myself. It is very nice that in C++ the "default" way of approaching error handling with RAII plays nicely with the compiler's static branch prediction logic. However, it's not a sufficient argument for truly high-performance code. Either your compiler provides conventions on static branch prediction or it provides intrinsics such as __builtin_expect that give you control. Both of these will give you the same benefits as the C++ RAII style, and (in my experience) neither approach gums up the logic enough to hurt readability.

Re:The kernel

[Gorobei]

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.

Grasshopper, a good language is not defined by its features, it's defined by how well its features hang together.

C++ is a nuclear power plant driven swiss army knife. Perhaps worthy of a Sunday comic strip, but little else.

Re:The kernel

[smellotron]

A separate init() method encourages reuse of objects, making it easier to make them members by reference or value.

If "being uninitialized" is a well-defined state for the object, then I agree. For example, you can have an empty container, an empty string, or a disconnected TCP "connection" (fd==-1 is a natural state, and instead of init() you have connect() or bind()). OTOH, I frequently discourage my co-workers from reusing value-objects. It's just as easy to say homeAddress=StreetAddress(street,unit,city,state,zip) as it is to say homeAddress.init(street,unit,city,state,zip). I have seen the latter pattern contribute to bugs when somebody added a member variable and didn't think to add it to the init() method, whereas nobody seems to accidentally omit it from the constructor.

Re:The kernel

[thePuck77]

I think b4dc0d3r was using someone else's program or working on an OSS project, not writing his own (obviously he doesn't like how these exceptions worked, so I don't think he wrote them to do that). If he's speaking as a user, I can understand the thinking of the original programmer; an end-user isn't going to know what to do with a detailed error message, and I have often written exceptions to be both logged and then passed up to another, different error message for the user to see that has:

This application has encountered an error!
Error #
Detailed information on this error has been logged at /path/to/log

This is so the user can tell support what error they got, or the user can be asked to copy/paste or send it in an email, etc.

Not saying you're wrong, I'm saying that thinking about the UX for errors can be a good idea.

Re:The kernel

[justforgetme]

orthogonality.

oh, man! I can hear the apple lawsuit coming....

Re:The kernel

[walshy007]

The trouble is that if you only have tiny steps available, then you have to figure out the original programmer's intention.

And figuring out programmers intention is easier when the languages grammar is more ambiguous... not.

Context-free understanding of what code does is _useful_ something that c++ completely blows out of the water once you start abusing its more advanced features.

Can c be coded badly? of course, can you sit down and figure out what a code snipped is doing? yes. Can you do the same of ill coded c++, quite possibly no, this is a serious flaw.

Re:The kernel

[alexandre_ganso]

I think he said about c++, not c.

Re:The kernel

[acooks]

Stop "optimizing", you've got bigger fish to fry.

I thought we were talking about a mature project (the kernel), where performance is critical, not a commercial product that started life six months behind schedule and twice over budget which has to play catch-up.

Ok, that sounded more negative than I intended, but if you're arguing that the current kernel development style needs radical change, then I disagree with you and urge you to study it in more detail. My argument is that the efficiency gained from embracing a well-understood (though perhaps flawed) pattern is greater and more predictable than the efficiency gained by radically changing pattern and upsetting the habits of so many highly skilled developers.

When the next generation microkernel is developed by a next generation of people using next generation tools and patterns and it manages push Linux aside you can shout "I told you so!".

Re:The kernel

[xouumalperxe]

Functional is new relative to OOP? The 1950s called, they said to rub Lisp in your face. Functional is also in no way, shape or form a superset of OOP. You can emulate OOP with functional code alone, but that's about how close the two are.

Re:The kernel

[petermgreen]

Classes, inheritance, templates, virtual functions etc are all language features not runtime library features.

Re:The kernel

[petermgreen]

Another alternative is to check the object through a method after construction, which a lot of STL objects do, but that's kind of messy.

Kind of messy but given that the whole point of constructors is that they are called automatically so the object is never in an undefined state you are going to have this fundamental problem.

a third alternative is to have the constructor create the object in an empty form (which can generally be done without memory allocation) and then fill it with data through regular functions.

Re:The kernel

[EdgeCreeper]

Even if it's just preserving the exception information to bubble up.

I do that. It preserves all exception/error information and can be used easily as long as the original source code is accessible. Although that is Java and not C++, this method has worked for me. As a mediocre programmer it is one of the areas of my code which I don't actually dislike.

Re:The kernel

[Jorl17]

Polymorphism is cute, but it sure looks lame next to what Functional Programming can do.

Mind of opinion. It just pisses me off that people keep saying these things as facts. Go back to your Functional Programming if that's what's good for you. Leave those who like OOP (even if done in plain C) to themselves. And the same goes for those OOP-bastards that pick on Functional programming "dudes".

Re:The kernel

[pugugly]

Feh - I've not been around forever, but I've been around long enough to know none of the programmers I've ever met called assembler machine language.

Assembler is, at it's basis, homomorphic to machine language (although even that's not true any more), but unless you're actually twiddling 1's and 0's it's not machine code and that's a distinction every programmer I've ever met is thoroughly aware of - and indeed will hit you with a cluex4 for forgetting.

Pug

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

[Garridan]

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

[Anonymous Coward]

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.

Re:Pick small libraries/utilities

[lgarner]

I think the first desire is to "try and figure out how their code works" and find some nice open source projects to look at to get an idea for how programming works in the real world." I'm not sure that a large, buggy project would be the best option for this.

Once these are satisfied, though, such a project would be a good place to address the overall objective: "start giving back to the FOSS community."

I generally start with small programs to learn how do something so that looking at a larger one isn't overwhelming.

Re:Pick small libraries/utilities

[Garridan]

Just sharing my personal experience. I tried to dive into a few small projects, and failed. I met William Stein, he helped me get started on Sage, (arguably a much smaller project back in '06... but still) and I've since watched lots of newbies get nurtured into productive developers.

Re:Pick small libraries/utilities

[Nethemas the Great]

I am not certain what your experience level was when you first started your "dive" but the author appears to be more or less a complete and total newb. He's taken a few classes, probably has a reasonable albeit basic grasp on C++, data structures, etc. but no practical experience with anything, just coursework. You also had someone that apparently mentored you to a certain extent. This suggestion was for "learning" while gratifying oneself with playing with actual code. A few posts down I discuss how to break into a larger project and be a meaningful contributor.

Re:Pick small libraries/utilities

[Anonymous Coward]

Rather than small libraries, I think it's important to choose a product that has a consistant design and sticks to it. In the C++ world, the best one I know of is LLVM. From my somewhat limited look into the code, it's very cleanly implemented and very well documented. And, as a bonus, the submitter is familiar with C++, so he/she will also already be familiar with the domain they deal with and further exploration will only further his/her understanding of C++.

Re:Pick small libraries/utilities

[Anonymous Coward]

No, the least lines of documentation the more difficult it is to get started. Find something that is documented very well, good luck.

Re:Pick small libraries/utilities

[tqk]

I'm not sure that a large, buggy project would be the best option for this.

Really? It could be the perfect environment, depending on the existing support for their efforts. Bugs galore? Where to start? Anywhere! Hell, it's like getting free rein in your new job at $BIGCORP. See something that's broken, take a whack at it. It's not like you'll make anything worse by trying.

I'm also a strong believer in learning from other's mistakes, not your own.

Re:Pick small libraries/utilities

[Anonymous Coward]

sourceforge.org

Write a large project yourself

[Rakshasa-sensei]

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

[Octorian]

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

[Anonymous Coward]

...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

[elsurexiste]

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

[denshao2]

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.

Re:Write a large project yourself

[Anonymous Coward]

-- Ethanol-fueled

... Is a gay faggot.

Re:Write a large project yourself

[Anonymous Coward]

I know you were looking for application examples, but - before you drown - it's well worth reading Lakos' "Large-Scale C++ Software Design". It goes into structuring of your project at the file and component levels for better maintainability, development, and builds. Great read.

Re:Write a large project yourself

[HarryatRock]

Oh no please no. This is exactly why so much code is so bad, and why computer systems are expected (by the muggles) to fail.
Please learn structured design methods first. Then don't submit code, submit documentation. I promise you if it is any good at all you will be welcomed as the prodigal son. Next step is to suggest changes to the design, and if you are confident suggest a code implementation . Please note the suggest; and be prepared to accept "peer" evaluation.
As to which project, pick something you know how to use, preferably with a simple interface and an active community. And do take part in any beta test release and user forums you can.

Re:Write a large project yourself

[BenoitRen]

I followed that road and now I'm stuck because game developers refuse to share any knowledge on intermediate difficulty topics. The only 'help' I get is to sling shit at the wall until something sticks.

I refuse to reinvent the wheel.

Re:Write a large project yourself

[Hognoxious]

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 a long time after your project reaches that point.

FTFY

Re:Write a large project yourself

[bigbird]

Been a while since I read this in my C++ days but highly recommended.

Re:Write a large project yourself

[tqk]

-- Ethanol-fueled

Your .sig says a lot about you, AC.

It doesn't really matter what the poster chooses to play with. If he's sufficiently determined to learn, anything he looks at will teach him something. I looked at/played with lots of stuff, some destined to fail no matter what I did. Still educational.

Ignore zealots of all stripes. Make your own way. Have fun!

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.

[Nethemas the Great]

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.

[swan5566]

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.

[Garridan]

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.

[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.

Re:Really good question.

[Anonymous Coward]

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.

[dkleinsc]

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.

[LateArthurDent]

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.

Re:Really good question.

[Whalou]

Some where small typo type bugs

Indeed... :-)

Re:Really good question.

[jank1887]

I heard something very similar about going in for a job interview.

If you say, "I'm willing to do anything, and learn what I don't know!" you've just created more work for everyone else (very likely the person interviewing you) as they will need to spend time figuring out what to have you work on.

If you say, "I have an interest/experience in X, and based on what your group does, I'd be interested in starting to try something with Y, unless you have something else pressing for me to start with" you've just showed that you have the ability to find things to do independently, saved them time and effort in getting you started up in something, and showed flexibility and a desire to help them out.

Similar to contacting a developer. A pointed question, or specific request will get them help with less effort required on their part. A general, "hey, I'm here" means they need to spend time getting you set up. they'll brush you off until you come back with the pointed question.

I find we have the same issues with summer interns. We always bring some in, or are told to bring some in. When we have a couple specific projects, its great. when we don't, someone has to waste half of their summer managing/handholding the interns. fun fun.

Re:Really good question.

[LateArthurDent]

I find we have the same issues with summer interns. We always bring some in, or are told to bring some in. When we have a couple specific projects, its great. when we don't, someone has to waste half of their summer managing/handholding the interns. fun fun.

Man, I know that feeling. Lack of planning on our side means that we constantly need to stop what we're doing as the poor intern shows up and asks, "do you have something for me to do?" At that point you usually come up with some busywork that bores the crap out of them. Not what they signed up for.

There's also a related problem on the part of the interns. Some of them expect far too much hand-holding. I had this one guy assigned to my team once and he literally called me to ask a question every single time his code didn't compile. He would ask, "this doesn't work, what should I do?" Well, try reading the compiler error and at least typing it up on google, for god's sake. I don't want people to be stuck on a problem for a week when I could help them in five seconds, but you've got to at least wrestle with the problem for 20 minutes, or you don't learn anything.

This is what showing that you've tried something before talking to a developer accomplishes. You're letting him know that if he sends you in the right direction, you can be counted upon to go off and get something done, you're not just going to make him do the work himself in a less efficient manner through you.

Re:Really good question.

[Anonymous Coward]

As a self taught grey haired script "kiddie" I found this really great starting point.

https://github.com/tylerhall/simple-php-framework/

Just complex enough to cover most bases.

Re:Really good question.

[AlexiaDeath]

If you already can program then you can skip the QA and dive straight into debugging. Just one thing to remember tho, if the bug that's bugging you is present on the stable version that you are most likely to have, go get the development code first and check its still there. Then go join some developer haven where you can ask for pointers and then just dive into code. Developers are usually very very happy to see intelligent people capable of telling them where the bug is. don't rush to code a fix tho, without talking to developers first. There are many ways to fix an issue and most of them are wrong way of going about it.

Start with slashcode

[Anonymous Coward]

And then do the opposite.

Works every time.

Re:Start with slashcode

[Anonymous Coward]

Corollary:

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

Re:Start with slashcode

[cforciea]

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

[2names]

...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....

[Anonymous Coward]

Linux

Node

[Mensa Babe]

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!

Re:Node

[dargaud]

Out of curiosity I looked at your link to Node. Then at the explanation about what the project is. It fits in half a line: "evented I/O for v8 javascript" and I have no idea what that means, even after 25 years of pro programming. Fairly typical of undocumented open-source projects, unfortunately.

Re:Node

[spud603]

main page

Re:Node

[emt377]

Out of curiosity I looked at your link to Node. Then at the explanation about what the project is. It fits in half a line: "evented I/O for v8 javascript" and I have no idea what that means, even after 25 years of pro programming. Fairly typical of undocumented open-source projects, unfortunately.

The link is to the source, not the project per se. It's pretty well documented (I hadn't heard of it before, either) at http://nodejs.org/. In brief, it's a reactor pattern for JS. In fact, I see it's even mentioned on the Wiki page: http://en.wikipedia.org/wiki/Reactor_pattern.

The code looks good to me. Pretty much stock, professional, quality, C++ system software. Some of the algorithms/heuristics (e.g. idle detection for GC) are perhaps debatable (in a good way), but the code itself looks good. If a job candidate told me they wrote this and showed it as an example of past work I'd consider their ability to produce quality code fully proven, and switch to their other abilities as an engineer.

Wesnoth

[Digana]

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

[pak9rabid]

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

[Anonymous Coward]

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.

Re:Wesnoth

[Anonymous Coward]

I know I'm asking for a flame war here but I just want some ideas.

What (if any) IDE do you guys use? I've dabbled a bit here and there on some projects but never used a Linux IDE to do it. Usually just using Nano and do the recompile, test if it worked, rinse and repeat as needed.

Thanks.

Re:Wesnoth

[pak9rabid]

I prefer Eclipse. It's free and platform-agnostic (it's written in Java). It supports a lot of languages once you get the correct plugins installed. I've personally used it for Java and PHP (it's great for both...you can even do server-side PHP debugging if you install Xdebug on your apache web server and configure it properly. There's plugins for C/C++ development as well.

Re:Wesnoth

[tuxrulz]

I know I'm asking for a flame war here but I just want some ideas.

What (if any) IDE do you guys use? I've dabbled a bit here and there on some projects but never used a Linux IDE to do it. Usually just using Nano and do the recompile, test if it worked, rinse and repeat as needed.

Thanks.

You could try Code::Blocks http://www.codeblocks.org/

Re:Wesnoth

[Archwyrm]

I'm asking for a flame war here

Next offensive: All IDEs are horrible. Just use vim.

Your move.

Re:Wesnoth

[smellotron]

All IDEs are horrible. Just use vim.

Vim is an IDE, ergo vim is horrible.

Easy!

[aglider]

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

Re:Easy!

[Octorian]

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!

[dreemernj]

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.

Re:Easy!

[Anonymous Coward]

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

Qt is probably one of the WORST choices for C++ you can possibly suggest because it has NON-STANDARD "moc" (Qt ONLY) phase to it which is NOT C++ ! Neither are Qt "signals" and "slots" which rely on Qt "moc"! Boy oh boy talk about "bad advice"!

Re:Easy!

[gknoy]

It might not teach you specifically about C++, but it could likely teach most people (including me) a good deal about developing something large scale, and with comments that explain things in a way which help other developers understand what should (and what DOES) happen.

Re:Easy!

[Anonymous Coward]

Qt has few huge problems. First it's not really even C++. It's Qt-code that's compiled to C++ (the moc-stuff etc). Secondly, it's has very peculiar style, which partly comes from it's attempt to be compatible with everything. So it doesn't really utilize C++ very well, and it reimplements a lot of stuff that is in the standard (like containers). And from that comes also the fact that it is full of ugly macros.

Re:Easy!

[Anonymous Coward]

+1. Too bad the qt enthusiasts are so intent that everyone use their library so exclusively rather than encourage qt to conform to the C++ Ansi standards.

ALSA

[Anonymous Coward]

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.

Re:ALSA

[NikeHerc]

... some of the LADSPA filters are a little out of date ...

I started using Audacity under Fedora 14 recently; it's a nice piece of work. However, when I tried using the 60 Hz filter on some digitized LPs, I was pretty disappointed in the result. Don't know if it was user error (e.g., me) or lack of documentation.

Where the heck do I start to create a better 60 Hz filter???

Re:ALSA

[emt377]

Where the heck do I start to create a better 60 Hz filter???

Digital Signal Processing: A Practical Guide for Engineers and Scientists would be a good place to start.

From stuff I've seen...

[ilsaloving]

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...

[Anonymous Coward]

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...

[Anonymous Coward]

Brilliant

Re:From stuff I've seen...

[Cro Magnon]

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...

[Anonymous Coward]

Or just download the gcc source tree.

Re:From stuff I've seen...

[c]

> ... and then fling the whole thing against a wall.

Don't forget to pick everything up, dump it into a paper bag, light the bag on fire, and leave it at the entrance to the Marketing department. They sold the client a "candle light dinner"... let them deliver it.

Re:From stuff I've seen...

[Anonymous Coward]

I have a wall of quotes and congrats your quote just made the wall! :)

Re:From stuff I've seen...

[Rizimar]

Parent is modded "Funny", but it's true. I was hired to finish up a software project for a startup after they outsourced their web development to some students in India. The code I had to work with was a total mess. PHP code would jump in and out of HTML without warning, nothing was commented, and the spacing was completely random. On top of that, filenames weren't very descriptive, separate files were made for very basic functions, and there were tons of versions of the same files left over in the same directories as the functioning code with little to no indication on whether or not it was still used somewhere.

I find it so hard to believe that someone will take on a serious coding project and just disregard any sense of structure or organization at all.

Re:From stuff I've seen...

[royallthefourth]

Parent is modded "Funny", but it's true. I was hired to finish up a software project for a startup after they outsourced their web development to some students in India. The code I had to work with was a total mess. PHP code would jump in and out of HTML without warning, nothing was commented, and the spacing was completely random. On top of that, filenames weren't very descriptive, separate files were made for very basic functions, and there were tons of versions of the same files left over in the same directories as the functioning code with little to no indication on whether or not it was still used somewhere.

I find it so hard to believe that someone will take on a serious coding project and just disregard any sense of structure or organization at all.

Yeah, I've had to work with Wordpress before too.

Re:From stuff I've seen...

[theArtificial]

Thanks for the laugh!

Re:From stuff I've seen...

[RandomMonkey]

Hehe, that is my real world experience as well. This highlights one of my favorite parts of open source. Because each line of code is "reviewed" by potentially thousands of people who are actually interested in the code for themselves as much as for the community (instead of one or a few coders that really don't want to give the man their full brilliance and really just want to go home and watch TV :-D), open source tends to create cathedrals of brilliant code. Sourceforge (particularly large known projects, small ones can be very sketchy) is a great source for good code.

Of course I am a curmudgeonly old open source advocate, so I may be a bit biased. ;-p

assemble the first GNU/Hurd distro

[Anonymous Coward]

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

Re:assemble the first GNU/Hurd distro

[Anonymous Coward]

The Debian project already have a testing/experimental distro: http://www.debian.org/ports/hurd/

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

Re:assemble the first GNU/Hurd distro

[Pricetx]

what about Debian and Arch? http://www.debian.org/ports/hurd/ http://www.archhurd.org/

Goals?

[immakiku]

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?

[Anonymous Coward]

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!).

Re:Goals?

[immakiku]

I think your analogy fails. I said a product he knows extensively, not a skill he is interested in. The assumption is he already has the skills required but not the domain knowledge.

DONKEY.PAS

[Anonymous Coward]

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

More info here:
http://en.wikipedia.org/wiki/DONKEY.BAS

Best Programs To Learn From?

[Anonymous Coward]

>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

[Rogerborg]

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

[bigredradio]

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++

[Anonymous Coward]

http://libcxx.llvm.org The coding style is very straightforward and the code is small

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.

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

[Hatta]

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.

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

[Anonymous Coward]

No, when I look at last years code I find all sorts of flaws in it. I've often looked back and went "yeah, that seemed like such a good idea at the time". Or simply "why did I ever do THAT?". Whenever I ask a developer about certain design decisions, sometimes there's an excuse like "well yeah it was written in $yyyy, but it works" which is completely understandable and valid.

How Programming Works in the Real World

[Anonymous Coward]

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

Scratch your own itch...

[jafo]

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. :-)

Your Own

[clinko]

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

[dkleinsc]

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

[ifreebudget]

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 :)

Re:I am looking

[gblues]

JavaDoc comments in your code would be a good start.

Re:I am looking

[ifreebudget]

Agreed. I was not disciplined when the project began. Going back and javadoc'ing the whole code base is non easy now. Anyway almost half is gui layout code, no use adding javadocs for that. I wish I was more careful from the beginning.

Re:I am looking

[Jmc23]

Whymake every potential helper search for your project when you could have just posted a link? By doing that you would have certainly saved a lot of people their time and increased the amount of people checking out your project. I know I'm certainly not going to checkout your project if you can't even think that through properly.

Re:I am looking

[sourcerror]

I guess it's time for shameless plug:
http://sourceforge.net/projects/infinite-wisdom/

Re:I am looking

[ifreebudget]

And my own shameless plug: http://code.google.com/p/ifreebudget-android/ http://sourceforge.net/projects/ifreebudget/

Re:I am looking

[gknoy]

That brings up an interesting point. You can learn a lot by asking an experienced developer not just what they did, but what they wish they had NOT done, or wished they had done differently.

Start with porting

[andrewgilmartin]

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++

[eric31415927]

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
http://www.amazon.com/Build-Your-Own-Flight-Sim/dp/1571690220

Too bad it's C++

[roman_mir]

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++

[Anonymous Coward]

Déjà vu.

Re:Too bad it's C++

[greg1104]

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++

[roman_mir]

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.

Re:Too bad it's C++

[greg1104]

Your use of "it", such as "if it were C", reads like you're talking about PostgreSQL--when apparently the "it" you actually mean is the person's experience.

There's no formal bug tracker for PostgreSQL. Following the mailing list traffic about it on pgsql-bugs is the only way to know what happened right now. It's hard to justify the overhead of a better bug tracking system when the project has a zero tolerance policy for bugs, meaning there's very few of them open at any time. It has been looked at and that investigation isn't closed; just waiting for resources.

Re:Too bad it's C++

[Anonymous Coward]

He's saying PostgreSQL is a good codebase to look at, but the OP was talking about C++ and PostgreSQL is C.

Literate Programs

[WillAdams]

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 ( http://www.literateprogramming.com/ ).

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

http://www.brpreiss.com/books/opus3/

William

Re:Literate Programs

[N3Roaster]

I wouldn't hold it up as any kind of example of great code (so there are certainly opportunities to improve it and it is still under active development), but another open source (MIT licensed) literate C++ program you can add to the list is some software I've written for data logging/record keeping in commercial coffee roasting facilities. I've tried to keep the generated source documentation reasonably easy to read and understand and the program is used daily at several coffee firms throughout the world.

http://www.randomfield.com/programs/typica/index.html

trace startup of mplayer

[rzei]

... 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.

More

[Mensa Babe]

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!

What types of projects do you like?

[AaronMK]

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.

Re:What types of projects do you like?

[Creepy]

That and with Class Diagrams for C++ are incredibly useful for getting a hierarchy view of the code. XCode comes with a tool as do at least some versions of Visual Studio (I have Ultimate at work, so I'm a bit spoiled) and there are at least standalone versions that are FOSS (some may integrate, but I'm a bit out of touch with FOSS IDEs). The diagrams take a while to generate, but simplify the code down and put it in a dependency drawing so you can see the dependency chain. You also can open any files from the diagram.

There are free tools for Open Source that create these diagrams and they may or may not integrate with certain IDEs (I haven't looked into it). I know CodeBlocks can generate Nassi-Shneiderman charts with a plug-in, but those are more for checking logic in a functional program (so not much use on Libraries).

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

[Anonymous Coward]

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...

I suggest NetHack

[Ignotus Non Audax]

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

[Bork]

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,:
http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt
http://pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf

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

[ewsnow]

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 python.org or look at it online (http://hg.python.org/cpython/). 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

[Anonymous Coward]

vmime : very well written open source C++ library

Where to start..?

[Anonymous Coward]

main()

Start at main

[ArtificialPulse]

I was in the same boat and ended up just looking around on sourceforge.net 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

[MagicM]

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.

Re:one step at a time

[Anonymous Coward]

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

Sorry, your code was inefficient. I had to fix it for you.

Re:one step at a time

[FrootLoops]

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

Sorry, your code was inefficient. I had to fix it for you.

The compiler would have optimized it anyway.

Re:one step at a time

[Anonymous Coward]

0. Avoid Goto loops - use GOSUB instead
0 and a bit. Avoid coding in BASIC - the line numbers are a real pain

Re:one step at a time

[Anonymous Coward]

Am I the only one that saw the irony in giving programming advice using a "goto" statement?

Experience Is key.

[jellomizer]

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

Why?
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.

Re:Experience Is key.

[firewrought]

You are not getting best practices....Looking at someones code you will get the good stuff mixed with the half drunk, or just a bad day.

Best practices are good, but reading code is its own education. Reading forces you to think and care about how the code communicates its own organization and intent. In turn, this spurs you to really think about what your own code means instead of just what it does. While books and articles on best practices can teach you a lot about code formatting, language-specific idioms, platform-specific techniques, design patterns, packaging/delivery, etc, they usually do so separately: you have to look at actual working code to see how all of these techniques work at once.

In my opinion, struggling to understand real code (with plenty of successes and failures--the failures are important too) steps you closer to learning the gestalt of style... you gain skills that help you critically evaluated someone's "best practice" and determine where it is and is not efficacious to use it.

Re:Experience Is key.

[CortoMaltese]

You are not getting best practices....Looking at someones code you will get the good stuff mixed with the half drunk, or just a bad day.

Best practices are good, but reading code is its own education. Reading forces you to think and care about how the code communicates its own organization and intent. In turn, this spurs you to really think about what your own code means instead of just what it does. While books and articles on best practices can teach you a lot about code formatting, language-specific idioms, platform-specific techniques, design patterns, packaging/delivery, etc, they usually do so separately: you have to look at actual working code to see how all of these techniques work at once.

In my opinion, struggling to understand real code (with plenty of successes and failures--the failures are important too) steps you closer to learning the gestalt of style... you gain skills that help you critically evaluated someone's "best practice" and determine where it is and is not efficacious to use it.

But then you'll face grandparent's point:

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.

It just doesn't make sense to just look and try to understand some code unless you have an angle to it. How do I add feature X? How do I fix bug Y? How do I refactor this to fewer lines of code? Etc. Scratching your own itches is possibly the best way to go. It gives you motivation, goals, and satisfaction.

Re:Experience Is key.

[Chninkel]

If the question you want an answer to is "How does it work ?", it does make sense to "just look and try to understand some code". Some (many) people are much more interested by that than by adding new features, I am.
(just sayin')

I couldn't recommend this more:

[naturaverl]

http://www.aosabook.org/en/index.html (And no, I'm not affiliated - just a fan)

Re:I couldn't recommend this more:

[cratermoon]

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

Re:I couldn't recommend this more:

[plover]

I came here to post this exact link. It's a great book, and a great way to learn how 25 different popular applications are architected, how they work, how they grew to be what they are today, and they show you the value of having planned your apps for the future. (or at least how they were forced to confront the future at least once in their histories. )

For someone just starting out, any of these giant apps would seem daunting to start reading the source at main(). I'd recommend reading the book first, then pick one of the featured apps that is of personal interest to you, such as Eclipse or Audacity, then try reading the source to one of the plug-in modules. Much smaller, and you'll get a better feel for the code itself.

Programming in the Large

[Shamanin]

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

Re:Programming in the Large

[smellotron]

Large Scale C++ Software Design by Lakos

I really like this book because Lakos breaks down intermodule relationships very well, something that doesn't get enough (or any) discussion from other popular references. However, it's very clear that he grew up in an age with shitty C++ compilers. IIRC he had some weird recommendations like avoiding namespaces and duplicating header guards outside of #include directives.

Code Reading

[cratermoon]

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

[Anonymous Coward]

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

[scorp1us]

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

[nroets]

On sites like spoj.pl 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

[whitroth]

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).

                        mark

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

[Short Circuit]

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

[Rakshasa-sensei]

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'.

Re:Good luck with that

[Anonymous Coward]

This is the difference between C and C++: in C, whatever the code of a function says it does, depends on all defines hidden in the included headers ; in C++, whatever the code of a function says it does is subject to be changed by templates, operator redefinitions, etc.

#define if while

I do hope that omitting the problems of the good old c preprocessor in your list of c++ flaws was just an oversight.

Re:Good luck with that

[Anonymous Coward]

This is bogus. In C you might call a function Foo(). In C++ that function may be called using syntactic sugar, but it's a 1st-order problem to determine which types are involved, and hence which overload/operator is called. In either language, what foo actually does changes the meaning of the whole program; so the dependencies are exactly the same in each language. In C++ you can name many functions the same so it's less trivial to determine which is called, but still 1st-order.

Then you have virtual functions, which emulate a certain use for C function pointers, and the dependencies between different parts is worse in C. Now you have to grep - either for the virtual function name (and hope it's not been overloaded too much) or for the C function pointer variable name. C is worse because you can't guarantee that a sensible idiom is used - the program may set the function pointer to a different value somewhere, in an if statement. C++ can't do that with virtual functions so it's easier to prove that you've got the right end of the stick if virtuals are used. C with function pointers is a nightmare (so is C++ with function pointers, but they're rare in C++, because people realize that non-idiomatic use is bad; they don't tend to realize that when they're writing in C).

The point is, C++ features do what people already did in C, except in restricted idiomatic ways, which help you sort through the mess. When people do the same things in C the situation is worse because you can't prove as much about the program's behaviour. This is why C++ was invented, and it's why high-level languages are a good idea.

It is easy to make small changes in a C++ program using a debugger and grep. The same process needs using in most non-trivial C programs too, owing to their design. In fact, I have someone else's 1MLOC C++ game engine here, and it's easy to work with - the design is relatively clean, and there isn't an explosion of subclasses. It was far more painful last year when I was working on Asterisk, where there are 100s of subclasses off a small number of base classes. Asterisk is written in C, and abuses function pointers.

I'll grant you, C++ with template policies wrapped inside macros is as bad as it gets in terms of not knowing what the fuck is going on, though. Unreal Engine III, I'm looking at you. Alexandrescau has a lot to answer for.

Re:Good luck with that

[RogerWilco]

I've seen C++ projects that exactly fit the description ultranova is making. I don't think it's unique to C++, but C++ does tend to encourage it more. Sometimes it has taken me more than a day to understand a single like of code. Not a method or a class, but just one line. This was that line: outptr[0]=0.0;
This was one of my first encounters with this 2M+ lines library, where before I had only worked on projects of a few 100k lines. This project has given me both a feeling of awe at the beauty of some of the code, and at the same time a fear of ever changing it. It's like Lady Galadriel, beautiful and menacing at the same time.

It often goes hand in hand with a core of brilliant programmers who are responsible for most of the code, but who are so ingrained into the software that they either don't see why it's not easy to understand for the newbie, or have taken a defensive posture, afraid that the meddling newbie will foul their masterpiece and oblivious to it's flaws.

By the way: I consider the above line a bug, but according to those who maintain the library it's a Feature, because it's been in there for nearly 20 years. (The project is almost as old as C++ itself).

Re:Good luck with that

[Anonymous Coward]

"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."

This is hogwash. C++ code presents APIs, just like any other code. Don't alter the exported APIs that other things depend on, and you'll be fine. If you WANT to do that, then OF COURSE you have to read what uses that API, but there are refactoring / cross-referencing tools for that; you don't have to digest the entire project just to see how a method is used.

Re:Good luck with that

[Anonymous Coward]

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.

Looking at a class definition and seeing if it uses operator overloading now considered hard. C can be just as bad when people use macros everywhere.

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.

The word you are looking for is coupling. In general as a professional C++ developer I don't find this to be true, maybe I'm lucky. C++ can eliminate a lot of the boiler plate you end up with in C without resorting to void *.

I agree C++ is considerably more challenging than C to understand all of its parts, however it does come with benefits for an experienced development team.

Re:Good luck with that

[toddestan]

Yeah, you can play tricks like that with C, but generally speaking you're not going to find that kind of thing unless someone is trying to make intentionally obfuscated code.

Re:Good luck with that

[Anonymous Coward]

What a load of crap.

The quality and modularity of a program is determined far more by the intelligence of the developers than the choice of language. Your comments about what a function does being changed by templates clearly shows you know fuck all about C++ programming. There is a difference in the way problems are usually broken down between C and C++ (function versus class based), but its not at all true to think that C programs are typically more modular than C++ .. there's loads of crap and loads of gems in both languages.

Plugins/modules

[Chris Hodges]

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

[Anonymous Coward]

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...

[Short Circuit]

...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

[Dr. Smoove]

I suggest download the Minix source and using the git portal for the OpenBSD source: git://git.freebsd.your.org/openbsd 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

[XaXXon]

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++

[Anonymous Coward]

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

[Anonymous Coward]

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.

Bad answer

[Anonymous Coward]

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.

Start at an Interface

[Anonymous Coward]

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

[Anonymous Coward]

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

[CynicTheHedgehog]

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

[codepigeon]

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: http://shfb.codeplex.com/

Code Browsing Tool

[Anonymous Coward]

Whatever you choose, a good code-browsing tool is essential for effective spelunking. cscope is the runs-anywhere standard, but I've recently become a fan of Opengrok.

Spaghetti sells .....

[King_TJ]

I'm going to get a little bit snarky here, but there's a point to it.

Why go to all this effort to learn a language like C++ these days, if you're not already employed someplace where you're clearly able to earn more income fixing/building something specific for your employer that requires that skill-set?

As one of my good friends just realized, he's been struggling to master Objective-C so he could learn to code a few apps for the iPhone and iPad -- but he's "going about it all wrong", ultimately. After all, his reason for wanting to create those apps is a financial one, so he's far ahead to simply outsource the coding to another country where labor is relatively cheap, and simply "project manage" its progress as it's developed for him.

"Why tend the farm when you can own the plantation?" was his wording, I believe.... In a way, it's a shame our country has come to this (United States in our case), but it's a reality of the global economy. As long as someone can create a user account on a website like odesk.com and place want-ads for iOS developers, graphic artists, etc. and actually FIND people willing to do this work for as little as $7-9/hr. -- it's not remotely cost-effective to try to code an app yourself instead. Will the resulting code be a bunch of "spaghetti" that's difficult to maintain or decipher? Oh, quite likely! But the end-user won't CARE as long as he/she can download the thing for as little as 99 cents a copy and it basically does what it says.

It's VERY possible to spend as little as $800 or so and receive a complete, working game or other iOS app in return. Then, it's equally possible to turn around and earn at least $100-300 per month, month after month, for NO additional work beyond doing a little promotion of the app's existence and answering emails about it. More importantly, if one rolls the profits back into paying for development of the next app, the process can be done in a "wash, rinse repeat" process, ensuring a multiplication of monthly income. Don't forget, with tools like push notifications, one can announce the new apps to owners of the existing, previously sold apps, which helps drive more sales....

Obviously, the original poster wasn't referring to developing for smartphones .... but rather, using a long-standing, popular language for writing apps or even operating systems themselves. But my point remains.... We're reaching a stage where it's just not financially smart to hire developers at the kind of salaries or hourly wages they'd expect to receive for the type of work they're doing (and amount of learning required to be ABLE to do it). Outsourcing is becoming the new norm, even if it results in poorer quality code (and I think it often does).

The document management software we purchased, where I work, for many thousands of dollars back around 2004-05 used to be developed in-house, here in the U.S. Guess what? The entire last major revision was coded as outsourced labor in India. They retain a "help desk" in the U.S. to answer their phones and give the appearance you're still dealing with a U.S. based company -- but all the trouble tickets eventually get turned into work orders for Indian developers to do either as a "hotfix" or more often, as a required change for the next service pack or version of the software they have scheduled to release.

Re:Spaghetti sells .....

[mikael]

I've seen that on those outsourcing/freelancer project websites. These days, one contractor at a client site will just subcontract all the other tasks onto one of those websites. You can never tell who actually did the work.

There used to be a trade term for startup companies bidding to for a contract only to subcontract the work out - "dutch windmills". Each company would take enough work to keep a group of engineers going at full speed and then pass the work downstream for someone to complete. It would continue all the way down the line. Eventually they realize it is better to keep everyone inhouse and they just have one big company.

Re:Spaghetti sells .....

[robotandrew]

Your ideas intrigue me and I would like to subscribe to your newsletter

Re:Spaghetti sells .....

[rgviza]

the only problem with the outsourcing approach is they'll simply steal your idea, present it as their own after they code it and screw you over. Go ahead and try to enforce an NDA signed with a foreign company.

After all who is going to believe that it was your idea after they've coded it and added it to the app store as their own?

You can't outsource boxed software coding unless you are already established and have a product for sale. Outsource V2, but V1 needs to come from  your own blood sweat and tears.

Start something new

[Spunkee]

I wouldn't bang my head on the desk looking at someone else's code and trying to learn from it. So many people write the most obfuscated shit -- spaghetti code and using extreme levels of shorthand when it doesn't actually improve any performance and makes the code hard to read. Don't cuddle your braces. /ducks.

Get your self a real IDE. Visual Studio 2010 Ultimate is available as a free download from Microsoft. You can get a free key for it with a Google search. I got mine from a Youtube video. You're free to install updates for life, and there is no DRM in it. Microsoft does this because they take fucking care of their developers (even us hobbyists that can't live without the features of VS Ultimate).

If you like games, then get the XNA Game Studio and use C#/.NET. The performance is great, and using unmanaged C or C++ for a game (with XNA available) is premature optimization in my opinion. You can call C code from your C# code and use unmanaged code whenever you want AFTER it's warranted by benchmarking and profiling. There are plenty of performance tracking classes in .NET and the profiler in VSS 2010 Ultimate is amazing. No cross-platforminess, though. I guess if you want to develop for Linux, then you'll have to settle for slightly inferior tools and APIs.

Have fun.

Kernel

[prefec2]

The Linux kernel is a piece of good crafted code in comparison with most desktop projects. This is mainly due to working community processes which Gnome or Freedesktop.org lack. Before someone marks this as flamebait. There is and was a lot of bad communication between parts of the Gnome community e.g. between Ubuntu and Gnome, between users of Gnome and the GnomeShell team etc. And arguments like: "It is open source take it or leave it" where send out, which is nonsense as software is not only designed by the programmers and designers, but also shaped by user needs. So the feedback of users is important. That's why Ubuntu became so popular in the beginning. Lately that changed a bit and therefore their loosing user base.

However, there are projects with a good community model such as the Linux kernel (even if Linus is sometimes a little harsh). The Apache projects seems to have a good process too and Apache HTTP is a smaller project so it might be a good starting point.

The best thing right not to help the desktop FOSS community would be real community building. There are some efforts with common conferences from Gnome and KDE, but there are still big issues for users to be heard by the developers. So help building community processes is even more important than coding.

Re:Kernel

[netskink]

I also like the linux kernel. Its not c++ but its well written. I also like the android api. Its well documented and its the hot topic now.

Re:Kernel

[prefec2]

I agree. The Android platform is also interesting and a possible starting place.

Anything + Doxygen

[rwa2]

Whatever you start off with, give it a run through doxygen first. Esp. with C++, this will save you a lot of time looking up definitions of objects and other stuff buried in various (and overridden) header files.

Duh, FOSS makes it easy

[sunking2]

Read the well thought out and put together documentation bwhahaha

techniques

[lkcl]

the most important thing is to have techniques that allow you to find your way. the language doesn't actually matter, but it does definitely definitely help if the code is documented in some fashion. i tried, for example, to work on fontforge with my usual techniques, and the code was so incredibly dense and uncommented that it was absolutely impossible to understand. but, exceptions aside, here's a starting point for getting into large projects:

* use vi. do not use graphical editors. do not use emacs
* get a damn big monitor (or 2 monitors). open xterms at 80x60, as many wide as you can get.
* use a multi-window desktop manager (i use fvwm2 and i run a 6x4 grid: that's 24 desktops.
* be prepared to open (and background) up to 200 simultaneous files, across multiple windows.
* make sure that you open the files from the *root* of the project.
* open the files "by name", explicitly, so that you can do "jobs | grep {filename}"
* run "ctags -R" - it is your friend. then use ctrl-] on a function you don't know, and read about it.
* remember to use :e # to go _back_ to the file you were originally editing (after using ctrl-])
* be prepared to print out the ENTIRE codebase, and flip through it, off-line, very very quickly.
* be prepared to do page-down, page-down, very very quickly, through as many files as you can stand

the main thing to do is to get a vague map of the code into your subconscious, as quickly as possible. then you will go "i've seen that before..." and you stand a chance of being able to hunt for it and find it.

you *don't* have to memorise the entire codebase - you *don't* have to even understand all of it. but you *do* need to at least have the techniques which will allow you to jump to wherever it is that you want to go.

ultimately, though, you need a goal. what, exactly, is it that you want to achieve? if you have no goal, you are pissing in the wind.

i added NT Domains Security to freedce - that's a good, simple goal. FreeDCE is 250,000 lines of code, and very well laid-out. it was therefore quite straightforward to add 6,000 lines of code to do NTLMSSP. took a couple of weeks.

i added python bindings to webkit - that's a good simple goal (ok, it was horrendous, requiring over 12 different skillsets, including c, c++, python, perl, autoconf, gtk, python c modules, IDL files parsing - the list just went on and on). webkit is a massive project, and also very well laid-out and structured. the first version of the python bindings took about 8 weeks, and the 2nd (faster, better) version took only 2. the reason why the 2nd version took only 2 weeks is because i hunted down the mozilla xulrunner IDL file parser, hunted down python-gobject's code generator, adapted the xulrunner IDL file parser to understand the webkit IDL file-format (2 days), then spent the rest of the time hacking codegen.py to spew out the data types from webkit, and to create a standard python c module.

so you say "you don't know how to get familiar with a free software project", well, i am not - i wasn't familiar with webkit, but that didn't stop me. i wasn't familiar with xulrunner, but that didn't stop me. i wasn't familiar with python-gobject's codegen, but that didn't stop me. i just got on with it, and just trusted that the surrounding code would do its job, and trusted that the bit of code that i picked up could be adapted.

so in many ways, tackling a large codebase is more about overcoming your own fear and feelings of inadequacy. sometimes not even i can do that, and sometimes i can.

Re:techniques

[plover]

And why would you be opposed to using graphical tools, such as an IDE? Being able to click on a label and having it take you to the declaration or definition is great while you're walking through a module. Being able to find all references to it is invaluable when you want to see who called it and how. But to insist they can only learn if they run ctags and type ctrl-] in vi instead of some heretical right clicking in an IDE is ludicrous.

I don't understand people who argue against IDEs. To use a car analogy, it's like telling someone "don't ever use a map. You should just drive on every street around town and learn that you're supposed to stop at the intersection of 4th and Maple, and learn to look left when you approach the train tracks that cross Elm street." It artificially limits them from a lot of valuable tools that could help them learn. I think people should use every tool at their disposal if it aids them in their understanding.

Re:techniques

[scubamage]

Emacs > Vi (and Vim too).

Re:techniques

[RogerWilco]

I agree. I have seen the coding style that lkcl touts the virtues of, but it only works for a few people. It requires a certain kind of person. These can then often produce great code. But I can't work like that and I don't know many who can.

Re:techniques

[Archwyrm]

I don't understand people who argue against IDEs.

Maybe because you have never tried working without an IDE?

Fact: The shell is infinitely more powerful than anything anyone could cram into a right click accessible context menu.

It artificially limits them from a lot of valuable tools that could help them learn. I think people should use every tool at their disposal if it aids them in their understanding.

You could say the same thing about artificial limitations when only using an IDE. And hey, you could even use a shell and an IDE. Nothing wrong with that. Though I think most people who end up using the shell a lot soon realize that they don't need everything else that comes along with an IDE when they are only using it to edit text.

Re:techniques

[plover]

Maybe because you have never tried working without an IDE?

Sorry, I've been coding for 40 years. I've done everything from punching paper tape, and keying punch cards, to filling out optical scanning documents, edlin, ed, vi (but never emacs), Turbo $(LANGUAGE), Visual Basic from 3+, Eclipse, and so on all the way up through the latest editions of Visual Studio. I'm intimately familiar with many various ways to write programs. And I have to say the IDEs absolutely rock in terms of productivity. Autocomplete, the ability to have every manual at your fingertips in context, visual brace matching, code generating tools, syntax highlighting, trouble tracking, refactoring tools, unit test tools, all these things are knowledge amplifying tools. They employ the power of the computer under my fingertips to make me more effective. My time should absolutely not be wasted on looking up things manually, or trying to recognize I misspelled a word, or spent in various yank and paste operations in vi. The IDE is a performance enhancer.

I've found that the "I'm so macho I write all my code using cat and echo because vi is for wimps" attitude is one primarily of ignorance. These people see these tools and think "they're designed to make it easy for kids to enter the field." They couldn't be more wrong. These tools are written by awesome hackers trying to eke the most performance out of their own time.

I still code manually, of course, on occasion for small test programs. It's just too easy to open a text editor and scratch out a dozen lines of code, rather than loading up the three ring circus of the IDE. And I agree that it bothers me when some kid says "wow, you can actually write code like that?" But the day job isn't about scratching up dozen line test programs. It's about working together with lots of people on modules that are parts of large projects, that have to be submitted through a build machine to reach the testing team. Integrated source code management is yet another pain that an IDE helps take away.

Fact: The shell is infinitely more powerful than anything anyone could cram into a right click accessible context menu.

Y'know, I was going to write something snarky about this, but I trust I've said enough for you to understand why I don't agree that this is actually a "fact".

Re:techniques

[Anonymous Coward]

Looking at the advice from Ikcl, and I think he's probably an elite, experienced programmer. I think for a beginner trying to have 200 files open in vi, and scanning them is just going to cause a headache and zero uptake. Taking this advice is like an average person trying to use the training routine of a Kenyan marathoner. I've met elite programmers. I can't do what they do, not enough RAM in the right places. My thoughts, as an average programmer with a few years of experience:

1) Use notepad++ - one of the most overlooked, underutilized tools for programming out there. It'll format your C++ files neatly. As well as a host of other files types. You can open lots of files in notepad++. And it's free. If there's an IDE used with the project, use that IDE. Eclipse for example. Concert pianists can open complex music and just start playing it. Not so much the rest of us.
2) Get documentation. You've gotta be experienced and very good, IMHO, to just open code and read and understand it.

You can do programming. General rule - decompose larger problems into smaller problems. Try to use an IDE (Integrated development environment). I feel like the less energy you spend fighting with your tools, the more thought you can put into the code. Any non-trivial project, for an average programmer, will require some semi-graphical tools. I've used both vi plus gcc, and graphical IDE's and there's just no contest.

Re:techniques

[Anonymous Coward]

Why not to use emacs?

Re:techniques

[akanouras]

* make sure that you open the files from the *root* of the project.
* remember to use :e # to go _back_ to the file you were originally editing (after using ctrl-])

Thank you so much!

I've been assembling the "use Vim as an IDE" puzzle for the past few days and these were the remaining pieces...

Re:techniques

[Anonymous Coward]

>> 6,000 lines of code to do NTLMSSP. took a couple of weeks.

Horseshit. 6KLOCs is about a month of effort for a very good coder modifying something non-trivial. More like 1.5 months.

Re:techniques

[Archwyrm]

Autocomplete, the ability to have every manual at your fingertips in context, visual brace matching, code generating tools, syntax highlighting, trouble tracking, refactoring tools, unit test tools, all these things are knowledge amplifying tools.

You are assuming that these things do not exist for terminal based editors. They do. It is all about customizing your environment. No, I wouldn't want to use plain old vi for anything other than a quick job, but I get all those things you listed with vim (for example) and I get what vi offers and I don't have to wait for any three rings circuses whatsoever. ;)

In the end each programmer will use the tools to which he is most accustomed and maybe you actually like using a mouse, but perhaps now you at least understand those who do not prefer IDEs at least a little bit. It has nothing to do with calling anyone else a "wimp". That doesn't help you meet deadlines.

Fact: The shell is infinitely more powerful than anything anyone could cram into a right click accessible context menu.

Y'know, I was going to write something snarky about this, but I trust I've said enough for you to understand why I don't agree that this is actually a "fact".

Show me an IDE with a Turing complete context menu and I'll readily concede that point. :)

Re:techniques

[Anonymous Coward]

I agree. Emacs is a great operating system.
If only it had a good text editor... that would be quite something! :D

Re:techniques

[Anonymous Coward]

so in many ways, tackling a large codebase is more about overcoming your own fear and feelings of inadequacy. sometimes not even i can do that, and sometimes i can.

You need at least 28 desktops to consistently overcome fear and inadequacy.

Re:techniques

[Anonymous Coward]

Wrong.
Use ctrl-T to go back to where you were before ctrl-].
ctrl-# takes you back to the file you were previously editing.
ctrl-T can take you back several levels if you used ctrl-] more then once.

Re:techniques

[plover]

You are assuming that these things do not exist for terminal based editors. They do. It is all about customizing your environment. No, I wouldn't want to use plain old vi for anything other than a quick job, but I get all those things you listed with vim (for example) and I get what vi offers and I don't have to wait for any three rings circuses whatsoever. ;)

You front loaded part of my three-ring-circus-waiting-time with your customization efforts. I may have to wait 30 seconds for the splash screen and the IDE to load up the project, but you just acknowledged that you also spend some amount of time every time you begin developing in a new environment. (And I'd maintain that the graphical presentation of source or program architecture is also valuable, but again not everyone needs or wants it.)

Show me an IDE with a Turing complete context menu and I'll readily concede that point. :)

Here's one way to do it in Eclipse and here's one way in Visual Studio 2005. I've used it to create a plugin that automates the generation of CppUnit unit test skeletons. I've also created a plugin for VS6 (a very long time ago) that automated the maintenance of a project by watching a folder for new source code modules, automatically adding them into the project, and then building with them. I suppose if someone cared hard enough, they could implement ed in a context menu accessible dialog box, using ! as the menu accelerator key. That actually sounds kind of cool...hmm... anyway, it sounds better than Clippy for vi. :-) Anyway, the point is that both text and IDE environments are endlessly customizable.

And I totally get your point that some people prefer IDEs. The problem I have is the attitude those people often display is that IDEs are only for beginners or bad coders, which simply is not true. And many of them do it very arrogantly, which is quite off-putting.

I think the bad rep that IDEs get is that people don't see it as the difference between a performance enhancing tool and training wheels. Look at it with different users, though, and it becomes obvious why there can be differences of opinion.

• Do the productivity gains given by an IDE enable a bad coder to write more bad code? Yes, and I think that is heavily related to the biases against IDEs. It enables stupid people to make more mistakes per hour. But that's no different than a stupid person buying a fast car. It doesn't make fast cars bad, it just means stupid people can go faster.
• Will an IDE make a bad coder better? No, although that's a mistaken impression a lot of managers have because the bad coders are more productive. Productive != better.
• Will an IDE help a bad coder become better? (Note the distinction between the previous question.) I believe the complexity of the tools may often hinder learning by hiding important foundational knowledge inside "wizards" or "code generators." But because those tools make a good programmer more productive, they shouldn't be eliminated. Someone will become better only if they're personally interested in improving their skills, but that has nothing to do with their choice of tools.
• Will an IDE make a good coder worse? Absolutely not. There's a learning curve, of course, but anyone able to master programming will have no problem picking up such a tool.
• Will an IDE make a good coder better? I have seen that it can, especially when you're dealing with more than one programmer on a project. Plug in a real-time static code analyzer, and they find mistakes fast. Plug in an architecture visualizer, and they can instantly see if someone is violating layer encapsulation. Plug in a code generator and you el

Re:techniques

[optymizer]

what's wrong with ":tabe /path/to/file" then pressing "gt" or "gT" to go forward/backward between tabs?

Re:techniques

[Anonymous Coward]

I am not a programmer, but I did learn MASM decades ago to help me learn how MS-DOS really got things done. It was wonderful and led to a career as an IT desktop and server hardware support technician. Reading your long and helpful response was delightful, especially your final statement of absolute fact.

So I just want to thank you for sharing your insights. Outstanding!

Learn from the best

[FoleyvanDam]

This was the path I followed to enlightenment after I took my undergrad software engineering course in C in the early 90s. I set out with a similar goal to find what real world systems looked like with proper decomposition, class structure, commenting, etc. At the time FreeBSD was getting a lot of interest, so I decided to dive into that code base a look. That made my head spin and seemed to violate all sorts of tenants we were being taught. Shortly thereafter, I accepted an internship at Microsoft and thought "Aha! Now these guys are doing great and must have a truly excellent software engineering culture. I can really see some good code now." I cracked open the code base for Excel and PowerPoint and got lost in that for a while. A lot of the Excel code was still based around Simonyi's design in C, and actually had a reasonable core structure given the limitations of C. But it was also a real world system and had an amazing amount of cruft built up around it that was difficult, at best, to understand. Mac PowerPoint at the time was a hodge podge of Pascal, 68000 assembly, C++. Some of the code was clearly written with some serious thought and design, but a large chunk of it wasn't. My favorite code review during the internship was a bit of assembly that processed a code resource loaded on the Mac to patch in a fix to the OS routines for FileDialogs in order to prevent a crash in our application.

Start with a basic library

[Anonymous Coward]

You need to start with relatively straightforward problems, and I think the best way to do that is to start with a generally-adopted library that offers simple incremental improvements on the standard libraries of the language you are working with. If it is widely adopted it is likely to have been improved by a whole lot of eyes, and if it is basic you are likely to understand what the code is doing.

For example, I've recommended many people read the Apache APR code to get started coding C. Not only is it elegantly written in a way that is understandable and teaches good programming practices, but it is accessible because the problems it is trying to solve are relatively well understood by most programmers.

Which library you choose will depend on which language you want to work in.

You can help others learn on WiBit.net

[revjtanton]

Check out WiBit.net. It's not really an open source project; but it is a site that, for free, teaches programming including C++ (also C, Objective-C, soon Java and C#). We have a forum where users can help each other learn. It's not a big thing, but that's one way to give back to the community. Not just on WiBit, but helping others learn what you have learned is a great way to give back overall :-) Also by getting into a learning site you can meet others who are like you: they know a bit, but want to be involved with something bigger. You can get your own effort moving and maybe create your own open source project. We have a guy in our forums working on an open source game with other users of the site. Check that out here.

linux kernel

[Anonymous Coward]

I've always thought they had the best model for everything.

Xorg, not the kernel

[buchner.johannes]

• Xorg needs plenty of help that could be influencial. I heard it's more difficult than Kernel development ;-)
• You can pick a project from https://www.fsf.org/campaigns/priority-projects/
• You can also look at the projects of other well-known organisations (smaller projects by Mozilla, VLC, GNU, Wine), but it's best to work on a software you use and like. For instance, I tried to extend evince with a dual-screen presentation capability.
• I can also put forth my project, JakeApp that needs developing of a GUI (Java or Python or Ruby, whichever you like), and testing. It's about distributed P2P folder synchronization and hopefully soon also P2P TCP tunnelling, for small workgroups or companies.

Re:Xorg, not the kernel

[buchner.johannes]

Here are some more links:

• Sourceforge help wanted page
• A similar Slashdot story from before
• Some similar Stackoverflow questions: 1 2 3 (C related)
• One comment from above I especially agree with -- Look at GNOME Love -- Large enough projects have bugs marked as "easy to fix for newbies" -- This is for you!

use geant4

[Anonymous Coward]

Download geant4 (it's a c++ open source simulation libraries developed by the high energy physics community) from http://geant4.cern.ch/, install it, and try and go through their novice examples. These are short and sweet, and you don't need to be a high energy physicist to understand them.

Don't overlook related subject matters

[Anonymous Coward]

Becoming proficient in a programming language is an important skill, but it's not the only one that has to be picked up to get the job done. Keep in mind that code is a solution to a problem, often written to leverage a generic framework that is suitable for the task. It's just as important to understand the nature of the problem and the framework.

To keep this concrete, I'm learning Python (yeah, which stone have I been hiding under) after years of C/C++ programming. Lately I've applied myself to Unicode issues, solving bugs in Ubuntu stemming from multi-byte character processing. Apart from honing my Python skills, this task has exposed me to related technologies: internationalisation/localization; gettext; and Unicode. As the code I'm working with in applies Python's multi-language support, I've also had to dwell on this part of the Python library. Learning and grasping all of these -- not just Python per se -- helps me be effective in contributing to Ubuntu and making it successful in, say Asia, where multi-byte language is the norm (i.e. CJK).

The fact that you have the mindset to continually learn is heartening. Keep it up!

write a compiler

[Anonymous Coward]

At my university to complete a degree in CS you had to take a class called compilers which was a big project. This will teach you how to organize your code:

I could post the link, but I don't think the prof would like that -- let's just say it's a big 10 school, and they use Appel's book

Just start

[drolli]

There is no way to learn without failing. Start something small and let it grow as needed while trying to maintain quality.

Doxygen is your friend

[Bram Stolk]

Understanding a code base that is large and new to you is a challenge.
Especially if it is crappy architecture.

What I do is use Doxygen to map out the code base.
Once mapped, you can use your browser to get the basic layout and workings of the project in matter of minutes.

Google Doxygen, and install it (install graphviz/dot first).
Then play with it.
You will be glad you did.

Especially the dependency graphs are a life saver:
use them to identify and weed out header file dependencies, and you can orders of magnitude faster build times as well.

    Bram

Read This Book (online or in print)!!!

[Anonymous Coward]

http://www.aosabook.org/en/index.html

INKSCAPE INKSCAPE INKSCAPE

[Anonymous Coward]

Inkscape is a very interesting C++ project. You can hack on UI bits which are easier to get a handle of than the SVG rendering internals.

There's something for everyone to work on in Inkscape, and the project needs contributors to improve its quality!

You have much to learn grasshopper!

[Fallen Andy]

I'm sorry to say this, but for sure my personal experience taught me that there is no such thing thing as a program that will walk you to enlightenment. Here's a hint: you *should* feel like an idiot looking at any reasonable size codebase for *ALL* projects - even if they are in your domain of expertise. Anything past 4-5 contributors can easily look like the FSM descended to Earth - especially if it is a project that has run for years (original devs have long departed to other lands....)

Most of the more elderly progs/dev here will tell you if you prod them hard enough that "being dumb" is the road to enlightenment - if you think you know everything already, then you're not learning!

Big codebases, many hands = you need to learn human psychology just as much as coding, and the "art of diplomacy" (also knowledge of when to get out and say - "die in a fire losers" - just in your head). Ego's and little Hitler's who think they are code gods can burn many a decent project.

Andy

Develop a personal Framework

[JTW]

Aspirations of tackling a large coding project are usually less than imagined. Most successful projects start as the kernel of one programmer who strikes the landscape and envisions how things will work. Then they flesh it out to a degree and move on or otherwise becomes involved in managing the code base. At some point they leave or move on. So the majority of new or junior programmers end up interpreting that code base, usually with little or no documentation. In the best of all worlds they attempt to internalize or get inside the mind of the missing programmer.. and "figure things out" for themselves and extend it.. often making assumptions and mistakes the original programmer might laugh at or never intended.. but that is how the code lives on. Programming Libraries, APIs and application sdk's are all formalized examples of this.. sometimes with better documentation, or supplemental documentation and work even better as learning tools. In the distant past Language standards served the same purpose before formal libraries were common, and to a degree still do until new libraries for new languages are built up.

There are two fundamental reasons for wanting to work on "big" coding projects anyway, one is that your curious or have the need to extend or work with an existing product, application or code base.. that probably isn't well documented, or doesn't have "learners notes" or "examples" of how to get things done.

The other is the perception that it is career enhancing or will give one an edge over less experienced programmers.

For the first, the best way is to tackle intimidation with small projects and just going for it.. experience good or bad breeds confidence and eventually success.

For the second, a whole lot has to do with personality and experience and confidence, part of which can come from working with big projects and code.. but the personality is better worked on in a coffee shop and basically communicating with people in a sociable way.. even on the internet through email.

Open source projects are a great way to collaborate and work on all of the above in a safe non-litigious environment, and its high profile.. and you can find people willing to help.

Schools and colleges are a more traditional way, but cost a lot and there are some barriers to entry put in place by convention and societal expectations.

The interface between the real world and the digital hasn't changed since Woz and Steve Jobs invented the Apple computer or Bill Gates commercialized the free software disk in the back of a book. How can this tool, software, help me do things that I couldn't do before?

In the early days it was a lack of hardware that forced us to reach with our minds and know the capacity of the code better than the designers of the language.. more with less. That world is gone.

Today another economic, the embarrassment of hardware riches, tons of ram and lots of hard disk space.. but a limited human lifespan.. causes us to re-evaluate the old rule of "re-invent it yourself -- you'll learn something".. we just have the perception that to make something worthwhile.. it has to be totally and completely unique. Rather I think we should "get over it" and use Libraries or examples as if they were hardware building blocks and move on.. if you need a smaller code base then "that is the project" build from something that's already working.. and don't try to place magic crystal bricks in perfect celestial harmony.. before you get started.

There is an example of this happening before.. when we used to pontificate over RTL versus TTL which circuits should I use to build a Flip-Flop to build my microcomputer.. now we're moving into the age of when the Mobile computer replaces the Microcomputer and the Data cloud replaces the Database. What is a Mobile computer? It's not a PET Commodore anymore.. I don't even think I know.. its still being made.. but the effect on Apple and Microsoft are being felt.. safety seems to be in the cloud.. but maybe not.. what about distributed emergent data stores? Like bittorrent, dropbox, and programs that aren't programs but organize our lives like calendars? eh..

Whatever you're interested in, and step through

[b4dc0d3r]

Take something you like and/or use. Or something like what you do if possible. Load it in a debugger, trace in to main or the language equivalent, and see where the calls go. You'll see quickly how the files are organized (if they are organized).

The more familiar you are with the app, the more sense the code will make.

Choose several - I've found every project has its own style, organization, or other peculiarities.

As someone said above, the real world is not all open source. Most of what I've seen in open source has nothing to do with what is done at large companies. The closest you might come is Red Hat, their distro-specific additions to Linux. But that's still open-source style.

When you feel comfortable, go to something that will blow your mind. The creative use of the preprocessor in MAME/MESS, and the ploymorphic implementation in C, makes this a wonder to behold. And not a great example unless your intent is to make an emulator.

http://mamedev.org/

The point is to learn more than one way of doing things, and find what you are comfortable with. Not how other people do it. Because there is no one way. If you want the one way, read a book instead.

Get the book ?

[Lennie]

There is a book on that subject called:

Code Reading: The Open Source Perspective: Open Source Perspective by Diomidis Spinellis

ISBN-10: 0201799405 | ISBN-13: 978-0201799408 | Publication Date: June 6, 2003

Tcl/Tk source

[dskoll]

For C code, I recommend reading the source to Tcl/Tk. It's beautiful code, well-structured and portable.

Re:Tcl/Tk source

[dskoll]

Following up on myself... as a bonus, most of the important C functions and data structures have man pages.

DOOM

[x mani x]

For C, learn from the best, and that would be John Carmack. :)

http://doom.wikia.com/wiki/Doom_source_code_files

In my experience

[bytesex]

The best formatted (C)API that I ever encountered was the X11 client-library. Yeah - so sue me. No really - one function per file,same name for the file as the function, clear indentation scheme, always a comment (on top), well documented structures, etc.

Re:Pick well-used libraries/utilities

[b4dc0d3r]

I'd say take things that are popular, well-used. libpng or zlib for example, or any other library that is most likely in something you use. Even if real-world code doesn't work that way, it's something that a lot of people are exposed to, if only via the API.

Usually there is sample code which shows how to use the library. Many eyeballs on that sample, and you have a good shared consciousness. It's not always how things work as I said, but it is what's being used.

3D Graphics.

[Anonymous Coward]

You can try go to the world of 3D developing for Blender or FreeCAD. Blender 3D (www.blender.org) is a full featured suite for 3D artists, cross platform and with a huge and well stablished codebase. This is good since you can learn a lot from them and also you can start with something easy (like python scripts or C or C++ functions for it) or go for some challenging topics (they are redesigning their modeling core, or help with the new renderer they're coding). FreeCAD (http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Main_Page) is a 3D CAD tool being developed by 3 people for enginners out there. This is C++ and python skills involved, cross platform and these guys really need help badly.

Whatever you're passionate about...

[Anonymous Coward]

I was passionate about communication and chatting so I helped out the Anope project (IRC services), UnrealIRCd and Inspircd by contributing modules, some bug fixes, and some time testing. I think if you're going to get involved in something make sure it's something you're passionate about first and foremost. The other parts will come later.

Don't use any specific codebase ...

[golodh]

learn to use tools (like Doxygen) to gain an overview first.

If your codebase does stuff like modifying operators you'll find out that way. If, on the other hand, it's is heavily template-based, my best advice is to either learn a lot about those particular templates (e.g. the Qt library) or stay away for now.

Code monkeys try to read their way straight through the codebase. In order to succeed that way takes a lot of time and raw talent (among other things superb concentration, a memory like a bear trap, and a good feeling for C++ syntax). You can waste a lot of time before discovering you don't really have the talent to do things the hard way.

Software engineers on the other hand use tools like Doxygen and first try to understand the overall structure of the code and then selectively zoom in on something they want to change or improve.

My suggestion is to train yourself first to use tools (perhaps on a codebase you already know) and then find yourself a smallish but new project you can apply those tools to.

Re:From stuff I've seen... if you mean businesses

[b4dc0d3r]

If "the real world" means the corporate world, do this. Take an application you don't care about and don't know how to use, and assign yourself a bug to fix, and give yourself a deadline pulled from a RNG.

Code is developed this way:

Start developement
Shrink the team
Fire all but 1 guy who does all the maintenance
Bring in contractors
Add a few people
Shrink the team
Fire the 1 guy who knows everything
Scramble to find someone who knows the application
Bring in contractors
Select any step above at random

I'm not trying to be funny. End result is quirks, inconsistencies, inexplicable code blocks, bugs, performance issues, and all kinds of other bad things.

Assembler

[Lodragandraoidh]

It depends on what your true goal is. Do you want to become wizardly, or merely competent?

Study the libraries used to implement the code in question to become competent in that application. Most of the confusion of thought regarding code has to do with specific libraries used. By encapsulating complexity in libraries, it streamlines the main code - but then requires you to dig into the libraries to understand what's going on. This 'state' is difficult to maintain in their head for most people.

If you want to become generally 'wizardly' at all code you come accross - start off learning Assembly code for the gear you're most likely to encounter (probably INTEL processors). After that, everything else is easy. Following craw-walk-run - move on to learning about compilers and interpreters that you use (C/C++ and CPython or bash are good choices to look at). Finally, after you get a good understanding of the lower level hoops that your programs make the CPU jump through, then start looking at the higher level code you're interested in.

I like to conceptualise the different meta levels of the program stack -- from the microcode that defines the CPU functionality -- all the way up to the high level languages as boxes within boxes -- each level standing on the shoulders of, and building on the strengths of the simpler lower level constructs. Another visualisation you could use are those russian nested dolls -- one within another and so on.... If you can understand what is going on at the different levels when any one high level command is executed, you can have a better handle on what your code -- or any code for that matter, is doing. Computers are actually very simple when you get down close to the hardware --- it's all the cruft we've layered on top that leads to complexity - much of which is really unnecessary, and the result of people trying to code fast, rather than efficiently. I'm not suggesting everyone code in Assembler -- but there has to be a balance, a 'middle way' that avoids layers of high level garbage that you have to sift through because someone decided they wanted to use their favorite (big/ugly) library/framework, rather than implementing it in a more streamlined fashion. This state is largely the result of people seeing every problem as a nail, and every tool as a (their favourite) hammer - without any deeper understanding.

I think 'computer science' courses today give short shrift to that key understanding. This, as you may be able to tell, is a pet peeve of mine.

Hello world

[gnasby]

Hello world.

'nuff said.

code examples.

[Anonymous Coward]

I found starting with older BSD systems, in particular 4.4 BSD and FreeBSD 4.x was a great way to understand systems code. For a simple example of understanding how a kernel starts to manage memory, look at zalloc() and friends (vm_zone.c) in FreeBSD 4.x. [http://fxr.watson.org/fxr/source/vm/vm_zone.c?v=FREEBSD4].

For string parsing, the strbuf code in git and some of the code the jansson JSON parsing libraries are excellent. Jansson in particular is clear easy-to-understand state-machine parser too.

Debugger

[anonymousNR]

If you can start a project in a decent debugger, and once you start tracing the flow of the program, you would find a part of the code where you can begin your contribution, because thats where you will begin to see the turning wheels inside.

Oh ma(i)n

[gabereiser]

start with main(int argc, const char* argv[]) and work your way backwards.... look at what is called and dive in deeper...

gnuplot

[ThorGod]

Warning: I'm taking a wild stab in the dark.

It's written in C... But, it seems relatively small and does one job very well. It's also scientific and I think it's got a good sized userbase.

Anyway, you could always port it to C++. (i.e. basically write from scratch an object-orientated version of gnuplot, perhaps using some of the libraries gnuplot has for the real gritty stuff.)

Or, you could program some kind of C++ based GUI for gnuplot. Think like matlab or excel, only kept simple, stupid.

Play! :)

[Anonymous Coward]

I think you should have fun and play! Write tiny little programs to understand specific C++ features in isolation, focus on learning why they are there,
why they work the way they do, and what they're for. Read all the high-quality texts you can-- Stroustrup's books, anything in the Addison-Wesley
C++ series; follow C++ blogs like C++Next; read the Boost and comp.lang.c++.moderated groups; use lots of libraries, then find out how they work.
Then, look at progressively larger projects. Read the C++FAQ Lite. Read D&E. Get a copy of the standard.

I think you would enjoy Stroustrup's new book, "Programming: Principles and Practice in C++". It is pretty challenging, written with tremendous honesty, and
you will learn a lot about building software by reading it. I have been programming for over 25 years and I was very impressed with it.

Postgresql and libmagic

[Anonymous Coward]

The former for a good example, the latter for bad.

torvalds/diveclog

[Anonymous Coward]

Linus' new divelog program is a good small project to read through. It does something useful in a concise way with C and has good coding standards that make it very readable.

Learn JAVA

[na1led]

Forget C++, it's becoming outdated and too complicated. More platforms are using Java and HTML5 now, it's the future of apps for PC's and Tablets.

Re:Learn JAVA

[Anonymous Coward]

Forget Java, it's becoming outdated and too complicated.

Fixed that for you.

libstdc++ and the boost project

[SLOGEN]

Look at the libstdc++ for GCC and some of the boost project code.

That code has production quality, is written in a style that actually utilizes c++. Beware that c++ recently got quite a few new features that have not gotten too much usage in libstdc++ and boot you may want to read up on that separately.

There is an *excellent* FAQ on most of the fine-grained aspects of c++ at http://www.parashift.com/c++-faq-lite/

In general, stay away from tutorials on the web, they are mostly written by people who have little or no experience and thinks they should teach the world about for loops or whatever because they just made one that doesn't crash themselves.

As a side note: that goes doubly for javascript, a much better search term to find quality code is ecmascript, unfortunatly there is no such good discriminating search-word for c++.

try KDE/QT

[tuxrulz]

KDE is a big project, and has lots of apps where you can learn from. You can find small apps, big apps, libraries, WM, nearly everything in that project. It's well documented, easy to code thanks to Qt. You can start from the bottom with small tutorials, and move up in the chain when your experience improves.

A book that's done the same thing

[globallyunique]

http://www.aosabook.org/en/index.html

Plan9 cmds

[mevets]

It won't help you much with c++, other than in its commonality with C; but they are great programs to study. The code is clean; there is a minimum of comments, and there are lots of programs ranging from the trivial, like echo, cat; through interesting like ed, awk, to more ambitious bits like compilers, cpu emulators, debuggers, etc...

Gnu code is often very difficult to understand - huge variable names, #ifdef insanity, strange control flows. over-blown.
Spend a little time with clean C, and you'll want to forget all about the foggy, incoherent monster C++ has become.

Re:Plan9 cmds

[Archwyrm]

Seconded. You don't even need to be actually running Plan 9 either: http://swtch.com/plan9port/

Click

[Mensa Babe]

Out of curiosity I looked at your link to Node. Then at the explanation about what the project is. It fits in half a line: "evented I/O for v8 javascript" and I have no idea what that means, even after 25 years of pro programming.

Actually it says:

evented I/O for v8 javascript - Read more
http://nodejs.org/

Surely clicking one of those links would be faster than asking for it on Slashdot and waiting for an answer? When you click the "Read more" link that is not even half an inch from what you've quoted you can find a big "Resources for Newcomers" section with links to the wiki and the home page.

JavaScript is of course the programming language. V8 is its high-performance implementation developed by Google for Chrome. I/O means input/output and evented means that it is asynchronous I/O based on event loops. I think that after 25 years of pro programming you should know that, and if you don't then you should at least know how to follow the hyperlinks to find it out.

Fairly typical of undocumented open-source projects, unfortunately.

Well if the only place where you look for documentation is the title of the project on GitHub then yes, it is fairly typical.

Re:Click

[dargaud]

I did look at the link and it was to the source code and how to make the project. Now that I've read more, I still have difficulty wrapping my head around what is the point of running a webserver in javascript... I imagine it's not supposed to run in a client browser, otherwise it would be an open door to all kind of abuse.

Depends on your definition of real world

[Anonymous Coward]

Just like in hobby code, in the "real world" there is a lot of variation. You'll find some well architected programs, and some spaghetti as mentioned before.
If you want to be good at understanding any code, well, there is no one formula.
Have you worked on any medium to large sized programs? You'll find you had good intentions with designing something, but as your understanding of the problem grew, it had an inverse effect on the readability of your code. Add a function here, make a new class over there, whoops, forgot that class needed some other funcionality too. Why did I implement a copy constructor on that class, its *never* copied...I thought completeness was a good thing! Dang, I made that private, but my derived class needs access to that value, should I make it protected, or add a getter/setter?
Unfortunately, you may think in the real world this doesn't happen, but it does. If all the programmers on the team have a *complete* understanding of the problem from the beginning, they can write code that is easily followed, has a low defect rate, and is easily optimized. Sounds like utopia, right, thats because it is. The real world leads to the aforementioned thoughts which lead to the aforementioned spaghetti, defects, and difficult optimization.
No matter how good you are, spaghetti is spaghetti. You can become good at following the design thoughts that lead to the spaghetti, just as you can become use to the seemingly random road layouts in the northeast and thus still be able to find some path to where you want to go without GPS, but its still sub-optimal.

My reccomendation for any new programmer is to try to think like an architect. Study design patterns, break what you know of the problem down into pieces that fit a design pattern and implement it this way. This will at least help the future newbie programmer who also studies design patterns. It also makes it incredibly easy to refactor when necessary. If greater understanding of the problem leads you to realize either it needs to be broken up into 2 seperate design patterns, or just a totally different one, the refactoring is simple. Never be afraid to refactor! Don't hack code to fit. If it needs to be moved to a different pattern do it early, as I'll do it later becomes there isn't funding to do it ever. It may seem like you are slowing yourself down in the short term, but the benefits will be seen by your own productivity rate later in the development cycle when everyone else is still bogged down with following their own spaghetti from 3 monts ago, and you are implementing 6 months of their productivity in the next 3 months. Trust me, it works, and its easy.

To summarize, to be better with spaghetti, you need to study spaghetti, lots and lots of it until you notice it is becoming easier....writing spaghetti and studying your own is a great way to learn.
Second, follow design patterns and refactor as necessary to avoid creating spaghetti in the first place or fix it as necessary.
Lastly, be aware of OO slowdowns, study optimization techniques so that following good OO principals doesn't create slow code.

Discussion on Reddit about good code bases

[ansible]

There was some discussion of this on Reddit a while back.

I second Mike Pall's comments. The Lua codebase is relatively small, and your puny brain can probably understand all of it from top to bottom. Other systems, like GCC and GHC, would be much more challenging to understand completely.

Try something with plug-ins

[Anonymous Coward]

Try looking at different filter code and or writing your own filter for something like the GIMP.
You will be able to produce something pretty quick and graphics are a fun place to start.
After you get proficient with the plug-ins start looking at the main part of the application.

Best "Ask Slashdot" evar...?

[bwcbwc]

I'll second the recommendation to start small with a library or utility. Preferably a utility so it's easier to see how the pieces are supposed to fit together. With a library you frequently just get a group of classes without a good way to understand the underlying design.

I have to say that I think this is probably one of the best "Ask Slashdot" questions I've ever seen in my years here. It's directed to the right audience (the answers will actually be useful, as opposed to say, answers to a question about copyright law), it will have interest for a lot of of others who also want to learn and contribute, and it isn't a simple question that has only one good answer, so it will generate some useful discussion in addition to the usual /, noise.

The GNU Standard C Library

[Greyfox]

http://www.gnu.org/s/libc/

It is extremely well documented what every function in there is supposed to do, and most of the functions are actually written in C. Though I suggest you avoid printf. You'll learn things about C that you really can't learn any other way.

Some of the other standard unix utilities are also pretty good. I seem to recall that reading the source to awk and vi were very enlightening.

Re:The GNU Standard C Library

[Anonymous Coward]

This is a good suggestion, and since you studied C++, you might also try some STL functions which you likely implemented as homework assignments. For example, look at the "stack" or "vector" header files to see all the cryptic things you never thought were needed.

Like Aged Wine

[thed8]

I learned on Fortran in the early 70's so that must be the right way considering how great I am now..............

Parent makes joke

[Anonymous Coward]

Qt is a finely-honed, nth generation, complex, state-of-the-art library; the OP is unlikely to be anything but a nuisance to that project. Minix is where Linus started, ultimately spawning Linux. Actually the Minix suggestion may be in earnest; maybe it's a good place to learn about OSes. I doubt it's too susceptible to patches though.

Any unix source tree

[Anonymous Coward]

Eg. FreeBSD / NetBSD / OpenBSD, solaris , etc -

One where there is a single source tree, that is built at once, and serves as a basis for the system

(*not* e.g. a 'source based linux distro' where the build is a script that runs somewhere and there isn't something like /usr/src/usr.bin, etc lying around)

you have all the base utilities - which includes networking servers, utilities, network stack, kernel stuff, userland stuff, databases (ala DBM), etc -
all right there, easily buildable, and actually runnable vis-a-vis your own system

need a new tar flag? just add it .. want to see how something works - just tweak it

it's all very unified. this is something that does not translate to the linux world, nothing against linux here - it just doesn't

Be that as it may...

[Anonymous Coward]

I could suggest a few good English programs from which to learn.

Learning from open source projects

[lsatenstein]

There are many projects from which to learn. The way I would do the learning is to start with a small to medium sized project by a) get the user documentation
b) study the documentation and c) experiment/use the software.
After you understand the functional aspects of the product, your project should be to download the source, including makefile or build information. Then as a second stop, I would look in the source to find the explanation in the user manual, or vice-versa.

  Looking at a source library collection without knowing the user functionality will be a most difficult learning process. I would say that this latter approach will lead to frustration and abandonment of your learning wishes.

Re:From stuff I've seen... if you mean businesses

[Anonymous Coward]

Oh, you forgot that repurpose the project at least annually to do something completely different, and change specs monthly.

Minix 3

[unixisc]

Go w/ Minix 3 - you'll learn what a microkernel is, learn to write device drivers for it, and at the end, could end up writing them for a whole bunch of h/w-s/w combinations. Just the mere #combinations should keep you busy for a while, not to mention giving you a company that could sell/license its drivers either to Linux/BSD/Hurd companies, or to the h/w manufacturers.

I read the questioner as asking which programming languages should he learn, in addition to C++. Did I misread him?

A Debian package just for you!

[ignavus]

I'd find the source code to this Debian package and start by reading it:

http://ftp.us.debian.org/debian/pool/main/h/hello/hello_2.6-1_i386.deb

Must admit, I don't know how they got it all the way up version 2.6 ... what features did they add? And WHAT bugs did they fix?????

It's not the project. It's what you like

[naniid]

You can't learn from any project if you are not excited by it, no matter how small. Purely for learning this should be the approach:
1. Understand what you like. Look for similar project which is successful.
2. Download the oldest public version of the project and understand that.
3. Follow the subsequent versions and understand what changes were incorporated into them.
4. Join the newsgroup/irc relevant where this project's developers hangout and follow their posts.

There are two things you need to learn. One is syntax and approach to problem solving. This looks tough but will be easy once you get into it. Second is the group's dynamics and culture. Which might look easy from the outset but might prove to be tough once you get into it.

Start Small

[cnxsoft]

First look a small C++ library, e.g. google "lightweight c++ library". e.g. http://vipbase.net/xmlparser/ Then compile it and run the sample. Enable debug messages or/and some debug messages. Play around and modify a few things.

The Architecture of Open Source Applications

[Anonymous Coward]

It might be hard to navigate new code without knowing the design or at least having a reverse-engineered
view of how things are supposed to be organized. This recent (e-)book might be a good companion to dipping into actual code.

http://developers.slashdot.org/story/11/05/23/2227232/The-Architecture-of-Open-Source-Applications

Another advice is to start with something you can easily build and add prints to,
without changing something and seeing the results it can be hard to get hold of existing code.

take a VCS history walk

[godztempus]

Find a project that has its main history all the way back to the beginning. Use a git or mercurial repo as then you will have the complete history on your computer. The check out the first commit and work your way through the history and watch how it gets built up.

As you move through the history pay attention to the commit messages and the changes that were made. You begin to really understand what the developer is doing. Eventually the project will get to be so big that you won't be able to keep track of everything.

I did this with the git source itself. It was pretty neat to see it come together. Then when I found a bug it was easy to find the part in the code where the bug actually was found.

Performance

[Mensa Babe]

The main point is performance. Ryan Dahl wanted to write fast, scalable servers easily. We all know for years that threads don't scale but event loops do (see the second chart of memory consumption of apache vs nginx). Of course in order to have a highly concurrent evented server you can't use blocking system calls (which were a big mistake in my opinion to begin with - they are the only reason why you needed threads exposed at the application level for concurrency in the past). OK, so we want a portable, high performance, event-based, async-I/O, scalable, highly concurrent server. The obvious way to write such servers in a portable, OS-independent way was to write them in C using libraries like libev or libevent for event loops and libeio for non-blocking I/O. The result is great. But the problem is that it is not easy. C doesn't have lambdas, anonymous functions, closures or higher-order functions in a real sense, which all would make writing event handlers much easier. So Ryan was looking for a higher level language and found V8, the JavaScript virtual machine written by Google for Chrome. JavaScript has anonymous functions and closures. And V8 is fast. And also when you write JavaScript in the browser then you never use blocking function calls anyway, so people are already familiar with asynchronous I/O, events, callbacks, closures, futures and promises. Hell, you can even use Y combinators in JavaScript if you know your craft. Now, if only JavaScript had lazy evaluation and proper tail call optimization - maybe some day. Watch some talks by Ryan Dahl if you're interested and after 25 years in the field you should be. Oh, and Node doesn't have anything to do with the browser besides the V8 origins. It's all server-side. See the Wikipedia article on Node for more info and code examples. I'm glad that people who have been professionally programing for so many years are still willing to broaden their horizons. As I have written in the past it is not a universal property of programmers unfortunately. Have fun with new tools.

Re:Performance

[dargaud]

I'm more into embedded programming still using primitive C, so all that is a mouthfull, but thanks for the details. I have some colleagues who'll get a hardon with that stuff !

Just dive right in

[MrMickS]

Do what all enthusiastic new comers to FOSS do:

1. Find a project that interests you.
2. Gain an incomplete idea of how it works.
3. Re-write it from scratch and say how much better your solution will be when it is finished.
4. Profit

whats your aptitude?

[Faisal Rehman]

For os kernel: linux and join Linux kernel mailing list. For distro development: debian and its mailing list. For social network: diaspora.

Cppcheck

[dvice_null]

I suggest Cppcheck: http://cppcheck.sourceforge.net/
- It is quite small
- It is a command line application (there is a small GUI also in case you would prefer working with that, but I would recommend the CLI first)
- It has very good unit test coverage (about 90% line coverage), so if you break something with your modifications, you will most likely notice it.
- The general idea is rather simple, source code is input, then it is preprocessed, then simplified, then passed to a number of different classes that try to find errors from the source. So following the execution path should not be very difficult.
- As it is a tool for static C and C++ code analysis, you will learn a lot about C and C++ language while working with it
- It is a tool, which you as a C++ developer most likely want to use yourself, so helping it improve will give help also you.

re: reselling your idea

[King_TJ]

Your point would be valid, except I think the tactic is generally not to CARE about trying to enforce an NDA or copyright or anything else. You simply want the really cheap labor to code the thing for you. What they do with it after that is rather irrelevant. For starters, assuming your project requires graphics, you probably have 2 different people outsourced to work on it for one. One guy is designing the GUI screens or the game characters and look of the backgrounds for the game levels, or what-not, while the other guy is coding the core of it. Since only YOU have the whole "ball of wax", neither one of them is able to completely steal the app.

If they go off and redesign your idea into something similar but a little bit different, and start trying to sell it? That's ok. You've probably got your app out there first, which has inherent value. But additionally, you can add value if you keep up good communications skills with your customers and occasionally offer product updates (which you could again outsource to yet another new developer, ensuring the first guy trying to screw you by submitting your original app idea as his doesn't have access to the revised one).

Re:From stuff I've seen... if you mean businesses

[Anonymous Coward]

I know you are not trying to be funny, but that shit is sooo funny cause it is true. Sorry, I have not coded "professionally" for a while. I am still on meds and shock therapy to get over that experience.

You forgot to add the part about taking on some language / framework that you have no experience with at all and no time to even read a book about it.