Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming Open Source

Ask Slashdot: Best Programs To Learn From? 329

Posted by timothy from the besides-aa-of-course dept.
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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Best Programs To Learn From? More

Ask Slashdot: Best Programs To Learn From?

Comments Filter:

  • Pick small libraries/utilities (Score:5, Insightful)

    by Nethemas the Great ( 909900 ) on Thursday September 08, 2011 @11:51AM (#37340890)
    The more lines of code the more difficult to get started as a general rule. Just find a small library that provides support for something you have an interest in. Tinker with it.
    • 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

      • Re: (Score:2)

        by lgarner ( 694957 )

        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 ov

    • Whatever you start off with, give it a run through doxygen [doxygen.org] 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.

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

    • Re: (Score:3)

      by Octorian ( 14086 )

      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.

      • 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

    • 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 [martinfowler.com]. The best thing to do is ask other people why they used it there.

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

  • Really good question. (Score:5, Insightful)

    by Georules ( 655379 ) on Thursday September 08, 2011 @11:53AM (#37340932)
    I have often wondered the same thing. People tell me, "read the code and submit patches!" It may sound like hand-holding to experienced developers, but many new coders could really use an introduction to becoming a part of a community around a project.

    • Re:Really good question. (Score:4, Insightful)

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

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

    • 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. (Score:5, Insightful)

      by LateArthurDent ( 1403947 ) on Thursday September 08, 2011 @12:21PM (#37341290)

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

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

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

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

      • 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 sh

  • Start with slashcode (Score:3, Funny)

    by Anonymous Coward on Thursday September 08, 2011 @11:53AM (#37340934)

    And then do the opposite.

    Works every time.

  • I suggest diving into Node [github.com]. 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 [npmjs.org] 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
  • Wesnoth [wesnoth.org] 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

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

  • Easy! (Score:4, Informative)

    by aglider ( 2435074 ) on Thursday September 08, 2011 @11:55AM (#37340972) Homepage

    For C++ I would suggest Qt [nokia.com].
    For C I would suggest Minix3 [minix3.org].

    • Comment removed based on user account deletion

      • Re: (Score:2)

        by Octorian ( 14086 )

        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.

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

  • From stuff I've seen... (Score:4, Funny)

    by ilsaloving ( 1534307 ) on Thursday September 08, 2011 @11:57AM (#37341004)

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

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

    • 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

      • Re: (Score:2)

        by mikael ( 484 )

        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 con

    • Re: (Score:2)

      by c ( 8461 )

      > ... 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... if you mean businesses (Score:4, Interesting)

      by b4dc0d3r ( 1268512 ) on Thursday September 08, 2011 @02:57PM (#37343560)

      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.

  • 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 w

  • Linky [sourceforge.net]. 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.
  • 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!.

  • The code *you* wrote a year ago ... (Score:5, Insightful)

    by perpenso ( 1613749 ) on Thursday September 08, 2011 @12:02PM (#37341076)
    Besides looking at the code of others be sure to look at the code you wrote a year ago and haven't looked at since. You should learn something about good comments and documentation. You probably will have ideas on how to better implement things. There is some truth to the notion that programmers don't really like the code they wrote for a project until they have thrown it out and rewritten it from scratch for the third time.

    • Re: (Score:2)

      by Hatta ( 162192 )

      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.

  • 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 pr

  • Your Own (Score:4)

    by clinko ( 232501 ) on Thursday September 08, 2011 @12:05PM (#37341108) Journal

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

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

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

  • one step at a time (Score:3)

    by MagicM ( 85041 ) on Thursday September 08, 2011 @12:26PM (#37341354)

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

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

    how programming works in the real world

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

  • 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 ge

    • 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 idi

  • http://www.aosabook.org/en/index.html [aosabook.org] (And no, I'm not affiliated - just a fan)
    • Also a good choice. I don't own it personally, but I've referred to it at work.

    • Re: (Score:2)

      by plover ( 150551 ) *

      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, th

  • 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

  • Take a look at Code Reading: The Open Source Perspective [amazon.com] 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.

  • 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

  • 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

  • Good luck with that (Score:5, Insightful)

    by ultranova ( 717540 ) on Thursday September 08, 2011 @12:38PM (#37341506)

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

    I think you already do.

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

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

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

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

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

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

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

  • Kernel (Score:3)

    by prefec2 ( 875483 ) on Thursday September 08, 2011 @01:08PM (#37341910)

    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.

    • 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.
  • Read the well thought out and put together documentation bwhahaha

  • techniques (Score:5, Funny)

    by lkcl ( 517947 ) <lkcl@lkcl.net> on Thursday September 08, 2011 @01:16PM (#37342034) Homepage

    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.

    • Emacs > Vi (and Vim too).
  • Check out WiBit.net [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

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

  • 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 magnit

  • 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

  • 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 int

  • 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 op

  • 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

  • For C code, I recommend reading the source to Tcl/Tk [www.tcl.tk]. It's beautiful code, well-structured and portable.

    • Re: (Score:2)

      by dskoll ( 99328 )

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

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

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

  • Discussion on Reddit about good code bases (Score:3)

    by ansible ( 9585 ) on Thursday September 08, 2011 @05:48PM (#37345594) Journal

    There was some discussion of this on Reddit [reddit.com] 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.

  • The GNU Standard C Library (Score:3)

    by Greyfox ( 87712 ) on Thursday September 08, 2011 @07:47PM (#37346806) Homepage Journal
    http://www.gnu.org/s/libc/ [gnu.org]

    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.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close