As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am running a programming club at a high-school, and I have introduced my students to OOP using simplistic classes in C++. I believe at least theoretically they get the idea. I would like to be able to offer them a specific project they can work on together. The question I have is which approach to take. When I took programming classes in college, I saw two different approaches, but in my opinion they both had serious shortcomings. I ended up sleeping through most of them and learning the stuff on my own from books and examples.
Now that I am in the teacher's shoes, I would like to get your opinion on which approach is preferable or if there is a third option.
Approach 1 that was used, was to write a program on the board (or on a computer with a projection screen). The class definitions were always written first. Usually students would look really bewildered at this point, because the purpose of variables and methods would seem entirely obscure to them. The only time that they learned about what each variable and method was for and how they interacted was when the instructor would finally write the implementation (I called this the outside-in method)
Approach 2 was to explain what we are trying to achieve, and creating classes and members as needed. This has the opposite problem. He would be writing a method that would use these imaginary classes that would have to be implemented later. But the students has no idea how these other classes would work.
As it happens, I worked my way through University by working as a teacher. I am now a software engineer.
In my experience, it is paramount that the students be emotionally invested in a programming project. I'll get to your question in a minute, this is a necessary preamble.
To get there, I made the topic of the program something that really interested them, regardless of how silly it seemed, as long as it was something that connected with them in their world.
So, it could be (depending on the age of your students) about ranking singing stars by their talent level, including Justin Bieber. You can imagine the uproar at that one.
Like, Load their lyrics and count the number of times they say the word "baby". Something creative, something fun.
This will make "dry" questions come alive. Like, what should the "singer" class look like. Why it should have properties like "octave range" will be immediately intuitive.
Should the singer class have a method called 'barfOnStage'? (The Biebs barfed on stage a while ago). Sure, why not!? They will easily see the difference between methods and properties.
I mean, I'm just talking off the top of my head, I'm sure you can apply your own inventiveness and creativity to whatever's appropriate for your kids.
I would love to hear what you went with, and how the kids' project turned out.
For the beginner level I would go with a modified number 2 approach where you start with an easy problem and then build on it. Experience is the best teacher....like the time my High School teacher had us 'iterate' through twenty discrete variables as a 'list' and then taught us about arrays....
You need to select the right problem. It needs to be a problem that exercises the 'object oriented muscles' not the 'algorithm muscles'. It needs to be something that you can build requirements on it that exercise object orientation. A simple CRUD program should be adequate. You'll just have to constrain them to using objects and not arrays as I assume they'll be comfortable doing. I'll leave the exact specification up to you.
First, have them write a program that just lets them add records to the 'database'. Just by Creating a 'row' in their 'database' they'll be forced to learn how to create an object and instantiate an object.
Next, have them modify their program to display the contents of their 'database'. When they Read their 'database' they'll exercise the .show function or however you implement that capability.
Third, have them make it so they can change the contents of a 'record'. Updating will reinforce how to tell an object to modify itself.
Finally, they should modify the program to allow for 'record' removal. This will reinforce proper object destruction.
Taking it to the next level (and since this is c++) you could:
require they implement their 'database' as a linked list
write the specification so you can do something that requires objects
being added together
add to the scope of data so the program structure would be better
facilitated by a template or inheritance (vehicle 'database' that has
both cars and motorcycles for example)
From my experience doing is the best teacher. Having someone show me how to do something (or doing it as a group on a board) short circuits the learning. Wrestling with it and having some Socratic guidance teaches a deeper understanding and yields a better programming brain.
If they aren't ready to do the 'create' function then coding it out as a group on the whiteboard will work, but once they have a template of how everything fits together they need to be behind a computer figuring it out.
If it's a beginner programming course I'd say the OOP aspect is of minor issue. Focus on expressions, statements and control flow.
If the focus is on OOP I'd say begin with the history of OOP and what OOP focus is. From that one can look at how one describe these concepts in different languages. (i.e. ADT, Simula etc http://retis.sssup.it/~lipari/courses/oosd2010-1/02.oop.pdf )
...and then experiment.
"If we look at the whole history, we see that the proto-OOP stuff started with ADT, ..."
-- Alan Kay (http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I know good programming practices always help in the "long run" for a project, but sometimes they just seem to cost a lot of time. For instance, its suggested that I maintain a header file and a cpp file for each class that I make, keep only the declarations in the headers while definitions in cpp. Even with 10-12 classes, this process becomes very cumbersome. Updating the makefile each time a new class is added dependecies and evthing .. takes a lot of time...
While I am busy doing all this, others would just write evthing in a single fie, issue a single compile command and run their programs ... why should I also not do the same? Its fast and it works?
Even trying to come up with short, meaningful names for variables and functions takes a lot of time, otherwise you end up typing 30 character long names, completely unmanagable without auto complete
Edit :
Okay let me put it a little differently : Lets say i am working on a small-medium size project, that is never going to require any maintenance by a different developer (or even me). Its basically a one time development. Are programming practices worth following in such a case. I guess my question is, do the good programming practices actually help during the development, or they just pay off during maintenance ?
I haven't been working in the field for long, but not slacking off and documenting as I go, defining variables with useful names, etc...definitely saves time in the long run. It saves time when the other developers/myself go back to the code for maintenance.
Not stuck wondering what this variable means, why did I do that, etc! :)
Laziness may pay off right now, but it will only pay off once. Taking the time to do it right doesn't pay off immediately, but it will do so multiple times and for a longer period of time.
Also, there is nothing wrong with really long variable and method names, unless you subscribe to the naive view that most of the time you spend programming is used on typing and not solving problems.
Addendum: If it is hard to name succinctly, it probably needs to be broken down into more modular units. Method or variables that are hard to name is a definite code smell.
Its all about long term supportability. Clearly you have either not been coding on a team or not had to look at code you have written years ago. I can open code I have written 15 years ago and modify it with very small relearning curves if I have given meaningful variable names, while if I have not it will take some time to figure out what I was doing with that X and that H, and why T should not be more than 4.
Try sharing code with 10 people on a team and have each of them just put code in any place they like... I have worked with people like that. If lynchings still had public support, I would have lead many. Picture this... I know I need to modify the signature on Foo.SetFoos(int FoosInFooVille), but I looked for Foo.h and it was not found, well now I just look for Foo.cpp right? Oops, to save... time?... they jammed Foo.cpp into Chew.cpp... so I look there... its not at the top of the file! Do I find Foo in that file and see if its above that... sure... nope, not found... its in Chew.h. Now I am ready to check the SVN log and target my USB powered missile launcher at that jerk next time he passes by.
The downside of the ad-hoc is in the long-run, when it comes to maintenance (especially when the maintenance coders are people other than yourself). Such techniques might be OK for quickie proof-of-concepts, but will cause more problems in the future if you don't rebuild properly.
Yes, it's worth doing it "right" ie good, because, basically it's pay me now or pay me later, and, you're not the only person who will ever see the code.
If it takes you 15 minutes now to do it "good" - how long does it take you 6 months (or more) from now to figure out what was meant - in your own code!
Now, you could use Martin Fowler's 3 strikes idea for refactoring.
First time in the code to fix some thing , notice it could be refactored, but you're too busy and let it go. Second time back in the same code, same thing. Third time: refactor the code.
The effectiveness of programming practices doesn't seem to be your problem, here. What you should be concerned about are the tools you're using to develop. There are plenty of IDE's and other options for keeping your make files automatically up-to-date, for example.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am developing a project in C++. I realised that my program is not OO.
I have a main.cpp, and several headers for different purposes. Each header is basically a collection of related functions with some global variables to retain data. I also have a windowing.h for managing windows. This contains the winMain() and winProc(). It calls the functions that resides in my main.cpp when events happen (like clicking a button) or when it needs information (like 'how big to make this window?'). These functions are declared in a seperate .h file included into windowing.h.
Is it worth changing this to be OO? Is it worth the work. Is there any better way I can construct the program without too many changes?
All feedback welcome, thankyou for taking the time to read this.
No, I think if it ain't broke, don't fix it.
Any windowing system is inherently OO to a degree. You have a handle to a window managed by the OS, and you can perform certain operations on it. Whether you use window->resize() or resize(window) is immaterial. There is clearly no value in such syntactic rearrangement.
However, as the application grows, you will likely find that many windows are mostly similar and subtly different. The best implementation is boilerplate basic functionality with special functions attached. And the way to do that is with a base class and polymorphism.
So, if you can refactor the program to be more elegant with OO, go for it. If it grows into the OO paradigm with natural evolution, follow best practices and let it be so. But don't just try to be buzzword-compliant.
Two things you need to think about: cost/benefit analysis and opportunity cost.
What is the cost of changing your code to be OO? What is the benefit? If the latter outweighs the former, then I'd tend towards changing it.
Costs include traditional costs such as time spent, money spent and so on. Benefits include a cleaner implementation, leading to easier maintenance in future. Whatever other costs and benefits there are depend really upon your own situation.
But one thing often overlooked is the opportunity cost. This is a cost that should be factored in to your analysis. It's an economic term meaning foregone opportunities.
In other words, if you do convert your code, your cost includes your inability to do something else with that time.
Classic example. If you do the conversion and a customer decides to not buy your software because you're not adding the feature they want, that lost sales opportunity is a cost.
It depends on what you want to accomplish with the project. If not using the OO features of C++ works for you and there are no good reasons to change, then keep going the way you're going. If, on the other hand, you would like to learn more about OOP and you have the time to apply to it, refactoring it to be more OO style will provide you with a great learning opportunity.
I would follow the best practices for working with whatever window manager you are using. Most use an OO style, which you'll automatically inherit (!) as you follow its usage patterns.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know that C++ is a very complex language that takes many years of practice to master.
Taking that into account do you know of a small project (around a 1k of loc) that tests all of C++ major features (inheritance, pointers, memory management, etc).
The thing is I'm a Java/Python programmer and I really want to learn C++ so I've been studying C++ for a while but haven't tested anything of what I've learned beyond small exercises.
I want to take all of that knowledge and put into practice.
Doing this alone you will obtain many harmful habits. It's much better to get an internship with a company that has high competence in C++ development and train under guidance.
C++ is like a grenade without a safety pin – looks cool and you've heard that all "real professionals" use it, but you don't know when it is to explode. A tremendous amount of features that can be used for good or for evil without knowing whether it's really good or evil. That's why guidance is a must here.
A memory manager. That should get you thinking about:
free store management
pointers (of course!)
inheritance (you will want your driver code to use this)
templates (another way to pass the manager around -- driver #2)
designing user defined data structures (a memory block)
efficient use of standard container(s)
algorithms (to move around, figure out empty blocks, defragment)
Effective C++ and More Effective C++
Other than that, pick a (small?) personal project you want to write and do it in C++. You are not going to learn C++ by reading a 1000 line project.
I'm not sure about anything that tests all major features. There are a lot of them, and some are rarely used together (templates and virtual functions come to mind. Both achieve a form of polymorphism, so you often use one or the other depending on your needs.)
A suitable project in that it'd touch on all the important features might be something apparently simple like writing a correct container class, similar to std::vector or std::list. Ensure exception safety, iterator validity, the appropriate time complexity on all operations and every other requirement specified in the standard.
The problem with this, as well as most other projects, is that you won't really know when you're done. Making a resizable array might take 50 lines of code, and 20 minutes of your time. And then a beginner would think he's done. Making it exception-safe requires you to be able to spot all the places where the class might be thrown into an inconsistent state by an exception.
That's a kind of general problem with C++. It's easy enough to think you get it, and the compiler certainly won't notify you of aspects you've forgotten to handle. So you might think your code is perfect, and yet it'll crash for all sorts of odd special cases.
As sharptooth said, for a language as messy as C++, writing code on your own is risky. It is easy to fall into the trap of "I've written some code, it compiles and it seems to run. Therefore it is correct".
Of course you could post your code here or on other sites for review, or maybe just supplement your coding with reading the docs for actual high quality C++ code (most boost libraries tend to have comprehensive documentation, specifying both the rationale for various design decisions, and how it safely handles all the weird special cases that tend to crop up in C++. The C++ standard itself would be another excellent resource, of course. In either case, these might help you determine what problems to look out for)
When I was learning C++, I used it to write my own language for writing Colossal Cave style adventures. Like most computer languages it never saw the light of day, but it did teach me a lot about C++.
Whatever you choose the thing to avoid when learning C++ is GUI programming, which is a trap which will drain all your gumption and probably teach you bad C++ habits in the process.
I'd recommend creating a text based game. That really helped me firm up my C++. Doesn't take too long and you can exercise all the features you want. Come up with the game yourself. It is more fun that way.
Another great idea is to write a simple mathematics library, supporting Vectors Matrices etc.
But with todays libraries, that is only of academic use.
In order to learn C++ it is useful to look at a lot of well written C++ code.
I think the Qt library is quite nice for this so I suggest: Write an Qt application.
Look how they use C++ and create your own graphical components in a similar fashion.
Ideas:
- Stock chart viewer widget that connects to one of the financial websites and scrapes history data.
- Simple Excel like spreadsheet widget.
Depends on what area you want to work in. But nothing worth doing correctly comes in at less than 1000 lines of code.
If you are going to be writing games then try writing a Tetris clone.
If you think you will be using sockets etc then writing a simple chat/irc client would help.
Do you have a specific itch that needs to be scratched? When was the last time you thought "this sucks, I could do better?". Can you do better?
I would recomend writing a Tetris clone.
You can learn a lot of c++ concepts with this and learn a 2d library like SDL or maybe even OpenGL throgh SDL.
It is always good to have a project with visual results and at the end of it you can play it.
There seem to be two themes coming from the answers:
You need to pick a project that might involve more than 1K LOC in order to get the true experience of the project.
You need to also pair up with an experienced C++ developer, who can help you think through problems and avoid pitfalls associated with the language.
You can get around both of these by swing by sourceforge.net and signing up to help with an existing C++ project. As long as you don't mind your code being open source, you should be able to find an existing project to learn from plus experienced developers who can help by reviewing your code and offering guidance.
An interactive world:
A matrix where each position can be a Void or a Being.
A Being is something with a few attributes: age, Time left, gender, neigbor connections, etc. Capable a few interactions: fights, having sex and kids, friendships, etc. Some have special Skills, depending on their fathers (inherited trades)... like ability to kill, ability to make food,, etc...
Possible outcomes of those interactions and skills are changes on the self attributes, or creating offspring (when possible), or change neigbor attributes.
At each iteration, print the matrix as symbols/numbers on the console (depending on the attributes, etc), starting from a Biblical iteration 0 (initial conditions of your choice... you're God here).
Now you got some real-life pattern simulator, and learned something about inheritance, polimorfism, virtual functions, instantiation of classes, etc.
I would suggest a simple text editor would be a reasonable goal.
It's a problem domain that you have a good grasp of.
You have memory management issues, library class reuse issues (stl/curses?), pointer issues, and lots of options where derived classes can be used.
For polymorphism, perhaps, you can have the editor read from a keyboard, or suck commands in from a text file.
There is another good one.... dealing with files.
You don't have to cross platform it. You don't have to open source it. You don't have to show it to anyone. You don't even have to finish it. It can be an exercise just for you.
If you're learning fron a book, it must have plenty of well-thought-out exercises you can implement and learn from. Also check out the university sites and their C++ labs / assignments.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
A few weeks ago, I was assigned to evaluate all our programmers. I'm very uncomfortable with this since I was the one who taught everyone the shop's programming language (they all got out of college not knowing the language and as luck would have it, I'm very proficient with it.). On the evaluation, I was very biased on their performance (perfect scores).
I'm glad that our programming shop doesn't require an average performance level but I heard horror stories of shops which do require an average level.
My question are as follows:
As a programmer, what evaluation questions would you like to see?
As a manager, what evaluation questions would you like to see?
As the evaluator, how can you prevent bias in your evaluation?
I would love to remove the evaluation test. Is there any advantages to having an evaluation test? Any disadvantage?
Gets things done is really all you need to evaluate a developer. After that you look at the quality that the developer generates. Do they write unit tests and believe in testing and being responsible for the code they generate? Do they take initiative to fix bugs without being assigned them? Are they passionate about coding? Are they always constantly learning, trying to find better ways to accomplish a task or make a process better? These questions are pretty much how I judge developers directly under me. If they are not directly under you and you are not a direct report for them, then you really shouldn't be evaluating them. If you are assigned in evaluating those programmers that aren't under you, then you need to be proactive to answer the above questions about them, which can be hard.
You can't remove the evaluation test. I know it can become tedious sometimes, but I actually enjoy doing it and it's invaluable for the developer you are evaluating. You need to be a manager that cares about how your developers do. You are a direct reflection on them and as they are of you. One question I always leave up to the developer is for them to evaluate me. The evaluation needs to be a two lane road.
I have to also evaluate off a cookie cutter list of questions, which I do, but I always add the above and try to make the evaluation fun and a learning exercise during the time I have the developer one on one, it is all about the developer you are reviewing.
I would first consider not necessarily the number of lines of code, but the value of the code that the person adds as reflective of course to what they are assigned to do. Someone told to maintain code verses building a new app is very different. Also consider how the person uses new techniques to make the code relevant and updated? How maintainable is the code the person creates? Do they do things in a manner that is logical and understandable to the rest of the team? Does their coding improve the app or just wreck it? Last and not least does their coding improve over time?
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person. One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding, etc.
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person.
That would work if (1) evaluation is conducted with open doors and (2) you've worked with that person on one project or even on the same module. As the person evaluating them, I couldn't judge the programmers who I didn't directly work with.
One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding
Unfortunately, this is debatable. Someone who looks like a slacker might be in deep thoughts, or maybe not. And is someone who spend a long time planning, necessarily a bad programmer?
I believe a good evaluation question would be able to answer this.