Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I was wondering how valuable open-source projects are to learn from?
I still consider myself "beginner" due moreso to lack of experience than lack of knowledge- I've read many C/C++ tutorials and taken classes and such, but I just really lack experience. Therefore, even though I understand the major data types and coding techniques, I don't have a solid grasp on what approach to take to use them in my own programming. Therefore, while I continue to read/practice/learn, I have been downloading lots of open-source code (random applications, emulators, games). It is worthwhile looking at them to help learn? I find it extremely interesting, but more often than not just get lost.
Second question, where does one usually start when doing this? Do you hunt down a main() function somewhere? Do you look at headers to see what functions will be available throughout the code and get an idea of what is around to work with?
Please let me know!
R
I personally wouldn't recommend the reading of the source code of open-source projects to a beginner, especially if they're mature projects. It may be overwhelming for a beginner since they tend to be rather large projects with thousands of lines of code, most likely of a non-trivial design.
If you lack experience, then the best way to gain experience is by writing your own programs and taking on your own projects that are of interest to you, in my opinion. You can certainly read other people's code to see "how it's done", but actually trying to implement those ideas yourself in practice does more to help you understand how to write code than just passively reading code. In turn, the gained understanding and experience will allow you to make better sense of other people's code.
It's sort of like math; you may know the formulae, and you can see how mathematicians/teachers/professors/etc. use those formulae, but you won't really understand them until you try them out yourself. Once you do understand them, then the kinds of things mathematicians write will make much more sense.
Try to focus on things you want to do, there's not a lot of point in looking at code for an application that you have no reference point for.
The best place to start would probably be to look at a project like Boost
But formulate a series of application tasks that you'd like to investigate, perhaps graphics, text editing or socket programming... and then work from there.
Getting a good IDE or programmers editor that will help you navigate the code is a major plus.
For example, Emacs + ECTAGS/CEDET/Semantic will help you browse all the functions / classes in a C / C++ project.
I'm agree with #In silico. It's very useful to see other's code, but only when it's a little bit over your level, so that you can learn something. I've seen quite a few projects that were too "over-engineered", so that learning from them when you can't really tell the good from the bad will be a bad idea.
Another thing is to learn from another programmer, when you could ask why he did one way and not another. In this case the difference in levels does not matter.
So I'd suggest programming by yourself, and looking on the other people's code for the same thing after you've tried it. In this way you'll be able to compare the choices you've seen and the decision you've made with someone else (when you don't know a problem in depth, any suggested solution would seem right). You know, In theory, theory and practice are the same. In practice, they are not.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Now that I know some of the basics of C++, I must admit that I still find it very hard to deal with code that others have written in C++. This may inherently be so, as C++ allows for complex object hierarchies that are, or at least to me, very hard to grasp if one is just supplied with a C++ Project without any further comments or instructions.
So my question is more a question to the more experienced C++ programmers among you: how can someone understand a large C++ project written by others?
I easily loose my way and can be lost for weeks, if I try to understand how a large project of, for example, 10,000 lines of code is written. Functions of classes are pointers to functions of different classes that may or may not be overloaded and may or may not be inherited by other classes, etcetera, without ending.
Are there any practical tips that may speed up my ability to read and understand large C++ projects? Is there perhaps a tutorial with such tips? Please, elaborate! :)
I've been programming professionally for some time now, and as such I have repeatedly been handed down codebases written by others before me. Understanding is never easy, especially when the code is inconsistent.
The first thing to realize, though, is that learning your ways in a new codebase is not so different than re-discovering a codebase you had not touched for a while. Thus, whether written by your old-self of others does not matter much; and since you probably manage to cope with re-discovering codebases you had worked on before, you should be able to discover new codebases as well. Don't lose hope.
The second thing to realize is that understanding is a vague term, and there are certainly different degrees. Often times, nobody asks you to understand the ins and outs completely; more likely you will be asked to understand a portion of the codebase in which either there is a bug or some new functionality should be developed. Therefore, as time passes, you will gradually gain an understanding of various portions, and you will inevitably have a deeper knowledge of the portions you worked the most whilst others can be relatively abstract or even completely obscure. It's okay, it's been a long time since human beings stopped trying to learn everything there was to learn.
With that said, there are several axis of understanding you can try:
you should look for architecture: a good thing is to trace the library dependencies (the Makefile/Project should help here) this will give you the coarse technical blocks out of which the application is built. Executables are normally leaves of the dependency trees.
you should look for data-flow: what's the trigger of the application (called directly or as a callback) ? what are the steps followed by this data (roughly, just a sketch). Do not hesitate to focus on a specific narrow usecase and use the debugger to trace things, and do not try to dig too deep at first; just get a feel of things.
There are also other axis that may help gaining some understanding of the domain the application has been written for. An understanding of the domain is useful because it provides you with a key insight on what should happen and it also helps you decipher the comments/function names.
user documentation: what is this used for ? if you can arrange for a demo it is generally very helpful, otherwise maybe you can try playing with it yourself (in a test environment)
tests: what is tested ? what is exposed to the user ?
persistent data: what is serialized ? what is saved in a database ? Persistent data is accessed at some point, so it helps if you understand when it is read/written.
If it is a working product (that runs) and you can "debug" it, start by looking at just one particular feature.
Learn how it is working from the user's point of view (UI, behaviour, inputs, outputs, ...).
Once you know the feature from the outside, just look for the code for that feature (only that feature); the starting point might be a handler for a menu, or from a dialog or a mouse/pointer event.
From there; manually trace the code for one action or sub-feature; skip deep internal libraries (treat them as black box for now) and learn how it works.
Once you know that section of code, dig deeper in libraries API that was called from the upper level code.
Take your time.
Do not try to understand everything at once.
Draw up schematic (pen and paper) of the dependencies (stay high level, no class dependencies at the beginning).
Good luck.
The problem that you are mentioning does not have clear and simple answer. Nevertheless here are some tips:
At the beginning try to randomly remember everything. Names of directories, classes, params of templates, etc. As much as you can. This sounds pointless but still makes sense.
While working with the code always think "Have I looked at this function/param/etc before?" If the answer is yes, spend with this piece of code more. If not, just make basic grasp and go on.
As the time will go on, you will find out that more and more sounds clear and easier to grasp.
It is impossible to give any exact values because size and complexity of projects vary greatly. Do not expect simple and immediate results.
Other points:
You definitely need a source code browser. Spend time in learning how to use it. Good example is http://sourceinsight.com/. This is not my site!!! I do have my own site. I will not mention it here.
If you see a function that is called 500 times, it is 500 times more likely that knowledge about this function will be useful comparing with a function, that is called only once.
The best is to grasp the architecture of the project. Trying to do this it is necessary to remember that project may have no architecture at all.
Studying the code you should remember your task. Typical situation - you need to modify something or fix a bug. If this is so look for the right part of the code and focus your effort on it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've been working for years on my personal project, an operating system made from scratch. As you may imagine it's quite complicated stuff. The problem is that I've been working this from scratch many times. Meaning that at some point (quite advanced too, I had hard disk read/write and some basic networking), things were too confused and I decided to throw it all by the window and try again.
In the years I've learnt how to make the code look nicer, I read "Clean Code - A Handbook of Agile Software Craftsmanship" by Robert Martin and it helped a lot. I learnt to make functions smaller, organize things in classes (I used C, now C++) and namespaces, appropriate error handling with exceptions and testing.
This new approach however got me stuck at the point that I spend most of the time to check that everything is going well, that the code reads well, that is easy, well commented and tested. Basically I'm not making any relevant step from months. When I see my well-written code, it's difficult to add a new functionality and think "where should I put this? Have I already used this piece of code? What would be the best way to do this?" and too often I postpone the work.
So, here's the problem. Do you know any code writing strategy that makes you write working, tested, nice code without spending 90% of time at thinking how to make it working, tested and nice?
Thanks in advance.
Do you know any code writing strategy that makes you write working, tested, nice code without spending 90% of time at thinking how to make it working, tested and nice?
Yes, here.
Seriously, no. It is not possible to write good code without thinking.
When I see my well-written code, it's difficult to add a new functionality and think "where should I put this? Have I already used this piece of code? What would be the best way to do this?" and too often I postpone the work.
This is called "analysis paralysis". You might be interested in reading the "Good Enough Software" section of The Pragmatic Programmer. Your code doesn't have to be perfect.
Those things are widely discussed. To me this legendary blog entry be Joel Spolsky and the follow up discussion (Robert Martin answered this) everywhere an the web contains all the pro and cons and is still fun to read.
To get an idea here's a quote by Jamie Zawinski which appears in the post linked to above:
“At the end of the day, ship the fu****g thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”
I suggest you give TDD (test driven development) a run.
In this context, you will write automated tests for each piece of functionality before implementing it, then you run the tests after completing the feature.
If the tests pass, then you are done, and can start another feature. As a bonus, the tests will collect over time, and you will soon have a test suite you can use for regression testing (to make sure you haven't broke anything while new coding); this addresses your fear of breaking things in the "nice code".
Also, TDD will let you focus on developing exactly what you need, not more, so it tends to lead to nicer and simpler design (especially in interfaces, since you have to think about interfaces before you start coding, so "thought" drives the interfaces, rather than "whatever happens to be handier when I'm coding it".)
However, be aware that applying automated tests to an OS may provide some amount of technical challenge!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm a high school student, and I have a decent amount of programming experience (HTML, Javascript, PHP, Actionscript 3.0). I know C++, but unlike the other languages I know, I have never actually made any decent sized projects with it. I am puzzled at what kind of project I should start, as there are so many things you can do with C++.
I just want some experience making something - but right now I don't know what I want to do!
HELP ME!
Find some open source projects and offer your help. You get to see other's code and have a goal on what to develop.
Find something that interests you. That will keep your attention the longest.
Pick something you're either passionate in, or something that might help you at home.
If you do that, then you have a vested interest in it rather than it being just another application.
For me, I wrote a small system to keep track of my customers. Now I know there are any number of applications that do that but I just wanted something small and custom so it really worked for me.
After that, when it was working, I then went back and refactored etc.
I see this question quite often. My reply is always the same. Programming is about scratching an itch. First find something that interests you and doesn't have a solution (or at least a good one). That's the itch.
Next sort out the best solution. It may be C++, .Net, Java or any one of a hundred other languages. The key is to pick the right tool for the job. If you try and push the square language in the round problem you will fail.
Programming is not about any one language. It's about finding the best solution to a problem and implementing it well using the right tools. This is what makes the difference between someone who knows a programming language, and someone who solve problems. The first are a dime a dozen, the second and worth their weight in gold.
Write a bitmap parser and viewer entirely from scratch, don't use any existing libraries. If you want an even bigger challenge, write a jpeg parser, that will require writing a huffman decompression algorithm and all sorts of other goodies.
I did this in java recently for a challenge, the program was rubbish but the amount of things I learnt made it worth while.
You could geek it up and create a complicated RPG (Maybe start with a simple form or console based game to get logic than maybe move on to directx or something).
I made an RPG myself but really never got to directx... yet. It can be fun because the game can be about whatever you want, your imagination is the only limitation. Figuring out the logic is a great way to stimulate your brain and learn new techniques in the process.
Try and find a copy of The OpenGL Programming Guide and have fun with some graphics programming. Old editions can usually be had cheaply.
The examples are all in C, not C++, but its good to get some experience in C too.
Also, see if your school or community hosts programming contests. One of my first large programs was a game for a junior-high level contest (though that was a long, long time ago).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I need to interview a candidate with over 8 years of experience in Linux using C/C++.
What would be the best way to judge such a candidate?
Do I need to test his understanding of algorithms?
Do I need to test his programming skills by asking to write a program?
How should I test his understanding of Linux?
It depends entirely on what you want him to do. You haven't said anything about the position that you are hiring for but if, say, you want him to write C# then you need him to prove his adaptibility.
Do you need him to write (or modify or bugfix) algorithms? If not, then it is pointless determining how good at them he is.
On the other hand, in order to understand his abilities, you may be better off talking to him about a domain that he is familiar with. You should certainly get him to describe a recent project that he has been involved in, what his contribution was, what the challenges were, what went well, what lessons he learnt.
"Over 8 years of experience in Linux using C/C++" is a fairly vague requirement without reasons for the time length. What are the specific reasons for that time length? Would you prefer more C/C++ experience if some of it were BSD or Solaris or other Unix? Would you prefer less time or a wider experience with different distributions; would you prefer 5 years experience with Red Hat or 7 years experience spanning Red Hat, Debian, SUSE, Gentoo, and others. What are you trying to get from the person you hire, that relates to the amount of time?
The best way to judge a candidate, any candidate, is on how well he can do the job, not how good the qualifications are. You mentioned Lead Developer, owning a product feature and eventually new features. What sort of feature? A highly responsive and adaptive UI? A UI-free recursive data mining calculation? Offline document scanning/indexing code? Custom device drivers?
Basic understanding of algorithms is important, but that can be tested easily in a phone interview. The ability to map out an algorithm for problem solving, and clearly state the reasons for preferring one over another is much more useful, and harder to test.
Test his programming skills by asking to write a program is a fairly useful BS indicator test; there are quite a few people who are adept at slinging manure who can't actually write a line of code. Another useful test is to give him some code with a defect and ask him what's wrong with it, and how he would fix it.
To test his understanding of Linux, I would look at a basic BS test; fire up a Linux box and ask him to perform some basic tasks, including maybe write and compile "Hello world". This will identify the BS artists. Then I would just go with some stock test, showing that he understands the basics of the Linux design; some file system knowledge, some knowledge of tools, ask about how he would add removable device permissions for a user using SE Linux, how he'd configure access to an application that needs elevated privileges so users without those privileges can use the application.
But ultimately, these are all pretty generic ideas; IMHO, it's much more useful to think in terms of "what do we want the candidate to accomplish", than "how do we test basic skills".
Maybe you should focus on what you need. Can he help you? Has he solved problems similar to yours? What are his expectations, what are yours?
I interview people like this all the time. The answer is that no matter how much experience he has, you must prove to yourself that he is capable of the job.
Joel Spolsky is right, hiring badly is destructive to a team and organization. It should be avoided at all costs.
The more I think about it, the more I begin to think good professional developers must be good communicators - in their code and with people. Think of the old saying - the more you know, the more you realise you don't know.
That's not to say you want somebody who isn't confident: but neither do you want someone that is cocky and unwilling to interact with others.
Recently someone asked about whether they should become a programmer in this posting. No matter how a programmer starts out they will likely learn from many mistakes they've made and as a result have an element of humility about themselves and development in general.
A good programmer continues to learn and keeps a relatively open mind.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am learning C++ as a first language. I feel like I am about to hit a ceiling on my learning (I am not learning through a class) if I don't start looking at actual code soon. Here are my two main questions:
Where can I find source code
What is a good litmus test on code's quality (I've obviously never developed in a work environment)
I hope this is relevant to SO, but I can see the need to close this. Thanks for the help.
Related:
Examples of "modern C++" in action?
I would recommend Boost. Using Boost will simplify your program design. Reading Boost source code can show you how to use C++ to solve some challenging problems in a concise way.
This add on library is itself written in C++, in a peer-reviewed fashion, and has a high standard of quality.
I think your two best bets for finding C++ code are to go to the popuplar open source repositories.
CodePlex: http://codeplex.com
Google Code: http://code.google.com
SourceForge: http://sourceforge.net/
These all have high quality C++ projects you can take a look at. I don't think there's a great metric for judging quality on a large scale. I would start with the more popular projects which may be more likely to have quality code.
The List:
SourceForge: http://sourceforge.net/
Boost: http://www.boost.org/
CodePlex: http://www.codeplex.com/
Google Code: http://code.google.com/
Google Code University: http://code.google.com/edu/
koders.com: http://www.koders.com/
The net is chock-full of open-source C++ code. Why not pick a few such projects, and, even better, start helping out of them? No better way of learning than by doing!
I would recommend getting a good book, which will be packed full of source code examples!
C++ in a Nutshell
You can also search open source code at www.koders.com
I think you got some good answers already, I would like to add this suggestions for picking a project from one of the open source project repositories: Pick a widely used but preferably smaller project that has been around for a while and targets a domain that you are specifically interested in. That way you will be able to get a better idea of production ready code and be able to learn something about that domain.
I found the source code and documentation of POCO are quite readable, and
unlike some other open source projects that focus on handling one specific problem, say GUI or Logging, this library focuses on developing a complete application, thus covering a quite broad area(file system, text processing, networking, logging etc ).
it uses modern C++ idioms. So by reading the implementation you can learn modern C++ skills as well.
I would recommend OpenSG
It is an interesting topic, it uses concurrency modeling, networking, includes links to scientific papers, is well documented, uses real c++ not c with objects stuff and almost all subparadigms and doesn't overuse them, is easily accessible AND who would have guessed... I am a fan of it ;)
OpenSG - Home
C++ is a great language, but kind of heavy as a first language. Try python.
1) Where can I find source code
Reading code is harder than writing it. This is especially true of large, complex languages like C++. Without already knowing the intricacies of the language, you don't stand much chance of getting knowledge from the complex code others write in production. You're going to have to learn the very smallest parts first, on your own by writing it. As you learn c++, you will also learn programming.
2) What is a good litmus test on code's quality
There isn't one. That's not going to be an easy thing to learn, either. It comes from experience. But really, the way you know the good code from the bad, is that after you've had some time to familiarize yourself with the layout of a project, you can understand what any given piece does, after you look at it. Readable code has quality, whereas confusing code falls short.
Looking at other peoples code is a hard way to learn the basics. Find a tutorial on the net and get your feet wet that way. I'm sure there are many, fine printed books on the subject as well.
As you go, and get stuck or confused or lost, post questions here.
Code Project is the best place for source code.