I am teaching software engineering to undergraduates and I would like a blob of object oriented code that demonstrates tight coupling, bad abstraction, low encapsulation, poor maintainability, the works. Anyone have a good example? Something that is digestible (as in, able to skim in an hour or less) would be great. Thanks in advance.
closed as not constructive by user8 Jan 11 '12 at 3:36
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. If this question can be reworded to fit the rules in the help center, please edit the question.
You might Google for "refactoring". Often there's a before-and-after picture or even a step-by-step process that can supply you with a "bad code" starting point.
If that doesn't work, why not teach them how to write bad code? It might be an interesting exercise in contrarian thinking. Post the "rules of bad code" on the blackboard/whiteboard:
1) Try to bury misspellings in method names
2) Use extremely short, long, or meaningless variable names
3) Try to reuse variable names or similar variable names in different scopes
4) Write lengthy comments that either don't match the code or are meaningless (getSalesTax - a method which gets the sales tax)
5) Put as much functionality into a single line as possible
Others are welcome to add the missing 95 rules to this answer.
While still a student project, I shamefully submit part of my capstone project. It is open source software written in Java.
It is large enough that you probably wouldn't want to scrap it and start again.
It features some absolutely horrible constructs, but should have enough structure to make some key sections palatable.
Disclaimer: We only had 3 out of 5 team members and were self-teaching ourselves Java as part of the project to make it more of a challenge.
I will be available for questions/answers or anything else if you end up looking at it.
Also, Clean Code by Robert Martin has a lot of before and after examples taking those sorts of concepts one at a time. Not exactly one canonical example, but that's one book I wish every new hire had read in college.
You might want to specify the language you're searching for a project in. About a year ago I wrote a client and server for four-dimensional go in C++ with Qt. It is about 4,000 lines of code if I remember correctly, and should work on both Windows and Linux.
The code abuses exceptions, tight coupling (I think there's even bad friendship somewhere in there), RTTI, uses a ridiculously bad network protocol (which is entirely undocumented), and has at least two classes that do way too much (
Client). Oh, and it lacks any kind of unit tests. It took me about three weeks to write if I remember correctly, so it may be too small.
Feel free to contact me with questions/complaints if you choose to use it.
I think an interesting way of generating such projects would be to take existing student projects and then demand that students add features to them in a timespan that is not quite long enough. After a few of those, which probably get tacked on quickly, you could teach them to refactor and then request another feature at the end (in a similar time slot) to further demonstrate the benefits of what they've learnt/done.
Pretty easy, think of a project, have the person/group code it up in a day or two and then walk them through why it is bad design. People learn a lot better than it is relevant to what they know (in this case, their own code).