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 10 years ago.
Has using an acknowledged anti-pattern ever been proven to actually work in a certain specific case? Did you ever solve a problem or gain any kind of benefit in one of your projects by using an anti-pattern?
My understanding of the "anti-pattern" concept is that it encompasses solutions that have drawbacks that only reveal themselves over the long term. Indeed, the primary danger associated with a lot of them---like writing spaghetti code with loads of global variables and gotos every which way, or tossing exceptions into the black hole of an empty catch block---is that they're seductive because they provide an expedient solution to an immediate problem.
EDIT to add: Because of that, sometimes you do derive benefit from these anti-patterns. Sometimes your calculation that you're writing throwaway code that no one will touch again is dead wrong and you wind up with maintenance programmers slandering your heritage and sexual hygiene, but other times you're right and that crummy shell script that's held together with baling wire and spit does the job you intended it to do and is then blessedly forgotten, saving you the considerable time and effort of putting together something decent.
Anti-Patterns are still so widely around just because they solve a particular problem (while creating 10 new ones). Also known as workaround. But how do they say? Nothing lasts longer than a makeshift.
In fact I believe we'd all be jobless if things had been done right from the beginning.
The biggest problem that it has solved in my experience is launching a new application.
When the dev team has scoped the new application thouroughly, the timeline to implement the correct solution is usually too much for management to bear. Therefore, oftentimes, you code to meet the timeline, rather than "correctness" of the solution to get to the launch date, (but have others coding the "correct" solution for the next rev), making it essentially "throw-away" code.
One software anti-pattern is Softcoding, also defined at the daily WTF. Softcoding happens when programmers put material that "should be" inside code into external resources.
I'm working with software that some might say is suffering from softcoding. External files drive the software. Those external files are a micro-language: they must be compiled to XML before the software can use them. This micro-language has its own tools.
But softcoding is always in the mind of the beholder.
Having the material in a micro-language with its own parser has made my life easier. One data source can generate many different outputs: In addition to the version that the main program uses, I am able to extract information into HTML, .csv, and other formats that our customers want. Other programs can generate code in the micro-language, making automation easier.
In our case, softcoding has been a useful pattern, not an anti-pattern.
There is a reason for calling it a pattern rather than a law.
I would surmise that almost everyone has at least one example of a place in code where exactly the wrong thing was done, and it turned out better in the long term than the "right" thing would have.
And a far longer list of examples of anti-patterns causing trouble.
I have used magic pushbuttons a number of times, out of ignorance or laziness, and sometimes it actually worked out just fine, and it turned out that I did not need the extra abstraction of proper MVC.
Duff's Device utilizes the Loop-Switch Sequence (AKA For-Case Paradigm) anti-pattern.
Related
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.
Before you condemn this as subjective, consider that there are differences between different frameworks. Writing something with PHP, I assume, is probably a lot less verbose and thus time consuming and expensive than writing it in binary. While the differences may not be as pronounced between the title options, I think there probably are significant differences which can result in, for example, a DoodleJump-type app taking more or less time to code in each.
Although there are other factors involved in choosing a framework, I'm just asking which one requires the least amount of coding and thus time and expense for equally skilled developers to accomplish the same thing (conjuring DoodleJump physics, a basic TicTacToe game, creating a UI, whatever). I'd appreciate links to sources if you have them, as well as direct experience comparing the verbosity of one or more in accomplishing the same task.
I'd most like to get an idea of how Flash and HTML5 compare to Corona (in terms of development time), but I'm also curious about the others.
Well you should seriously rephrase the question. It looks like subjective.
I'll just give my experience with all these tools.
Disclaimer:- The following review is my own personal opinion and involves my personal experience. You might have different opinion.
Marmalade
While I've used marmalade for most of my deployed projects, I've never used their RAD tool quick for any serious development. I was asked to try it out by remaking one of our deployed game. I was really impressed with it's quickness and less-verbosity. Although it was only for 2D and I recommended it's use over normal marmalade for all our 2D games. Unfortunately, we never made any 2D games after that. The benefit was that it comes preloaded with box2D and Cocos-2Dx and still supports C++ libraries. Didn't try EDK with it yet, but it should support that too. The con (for me) was I had to learn luascript for that.
Flash
Well I am not a flash expert here, but I tried it on two of our deployed game and it was a good one. Although it was too limited in what it seemed to have. We had to Re-code one of these games in marmlade, just to support some 3D elements, which were not possible to do in flash(at least for me). Flash was too verbose and too confusing for me, since we don't know where the actual script is attached. I guess it must have happened with all programmers who tried flash after trying any other tool, like marmalade. It just confuse you.
Unity
Well it was much much better than Flash, and is actually a well written game engine. Although it might cost a fortune for Indie developers, but still it's worth it. I've been using it for almost 4-5 months and I already started liking it over any other engine. It's easy to learn and too less verbose. You just need to drag and drop and attach the script to the gameobjects.(Not really that simple actually). No need to worry about Physics engine, no worries about plugins(since most of the plugins are already avaialable). And you can do 3D in that too.
Never tried Corona and HTML5 for any development project, so can't have a say in that.
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.
Currently I have started on very large Legacy Project and am in a situation which I always feared Reading and Understanding Other People's code, I have known that this is an essential skill which is required but haven't developed it as till date it was not required and now its like necessity to develop this skill rather than hobby and so I would like to know from SO Readers about:
How you have overcome the hurdle of reading other people's code ?
What techniques or skill have you developed to polish your art of reading and understanding other people code ?
Are there any books or articles which you have referred to or in general how did you developed the skill of reading and understanding other people's code ?
I would highly appreciate useful answers to this questions as now I can understand how one would feel while trying to understand my code.
Practice. Practice. Practice.
I overcame the hurdle by interacting with people on open-source projects. Discussing my contributions with others, and seeing their suggestions and ways of looking at things really opened my eyes.
I suggest you find a project that fits you, check out the source and contribute what you can (no matter how small to begin with). Over time the skill of reading code should just come naturally. Some projects even offer mentors specifically for helping out new contributors.
Michael Feathers' Working Effectively with Legacy Code is a great resource that contains a large number of techniques for working with older code.
Practice, Practice, Practice.
If you can, talk to whoever wrote the code or has an idea about it. Draw lots of pictures and have them explain big things to you while YOU write comments.
The quickest way to find your way around is to get lost. Dive into the code and break stuff. See if you can change an int into to a string or something.
Patience: Understand that reading code is more difficult than writing new code. Then you need to respect the code, even if it is not very readable, for it does its job and in many cases pretty efficiently. You need to give the code time and effort to understand it.
Understand the Architecture: It is best if there is any documentation on this. Try talking to people who know more about it if they are available.
Test it: You need to spend some time testing and debugging the code so you know what it does.
For those parts you understand, write some unit tests if possible so you can use them later.
Be Unassuming: Many times the names of the patterns are misused. The classes have names which do not indicate their purpose. So don't assume anything about them.
Learn Refactoring: The best book I found on this topic is Refactoring: Improving the Design of Existing Code - By Martin Fowler. Working Effectively with Legacy Code is another awesome one.
I don't know of any way to do it, i have participated in several proyects, where i have to undertand by my own, how do they think in and achieve that solution, so i can undertand it too.
That's why every time i can, i recommend, if you are a developer, try comment the code, all you can, because, you don't know if someone will find it useful (i think i make my point)
If you're not a developer, you should find someone to support you.
How do you learn to read what other people have written? You get really good at writing yourself and try to make sure the person is as good a writer as possible (suggest things they could do better, like adding some darn comments) Sadly, code is almost always read by someone else other than the author. Practice, and familiarity with some of the person's other code can help. But whenever you spend over 5 minutes figuring out what a particular line means, note how they could have done it better, and make sure you never make the same mistake.
good luck. :D
When I'm approaching an unfamiliar code base, I like to start at the beginning. Find main(), and write out a summary of what main() does. Create a list of the functions/methods called in main(). If you're visual, create a flowchart of main().
Once you have a list of the methods called directly from main(), look up those methods and repeat the process. As you figure out what each of those methods is doing, write it up in JavaDoc format and paste it into its corresponding box in the flowchart. If it's an API call, document which API it is using and put a link to the relevant API documentation.
Working recursively, you will create a map of the application and figure out what the program actually does. Once you know what it actually does, you will be able to find inconsistencies between what it does and what it's supposed to do.
The answer varies depending on the tools and documentation available.
If any documentation is available, I try to understand the high level overview of the system - the different modules, interfaces and subsystem interaction. This helps to divide and conquer the code into sizable pieces as you go along reading the code. If any design patterns are commonly used across the code try to build up your knowledge on that.
Also depending on the tools available I may use any of the popular source code browsers (Source Navigator/Source Insight) to quickly view the dependencies (class hierarchy etc). This speeds up code understanding. Also if I have some handy unit testing framework try playing with the code- different inputs and expected output. I also recommend using debugger to step through selected complex functions to get a hang of the code flow.
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.
Possible Duplicate:
What is your longest-held programming assumption that turned out to be incorrect?
What do you consider to be the most harmful misconception about programming from people who are new to programming that you have seen?
Re-inventing standard library functions/classes.
After going through a language book/tutorial, most beginners - knowing how to handle strings and numbers - will invent their own date functions, their own 'compression algorithms', their own SORT implementations.
Oh, and they always spend their first day searching for clrscr();.
That because their program compiles and runs it does what they expect it to do.
That if their code doesn't compile or work, it is because of a bug in the compiler.
Maybe not the most harmful, but they usually can't estimate how long stuff will take to be done, they think it can be done much faster than it really must(including me).
As for harmful stuff, good companies usually keep beginners away from where they can do much harm. They are usually encouraged to work by someone more experienced, so they can learn better.
That if their program works on their own computer, then it will work on everybody else's computer too.
"But it works on my machine!"
That programming is all about the syntax. Turns out it is all about problem solving.
That the user is a programmer.
Thinking if it doesn't look horribly complicated it must be wrong or "bad" code.
I must admit years ago in school I was guilty of thinking my programs didn't look complicated enough! These days I want to cry if something doesn't turn out as simple as:
//start
if(something)
{
do_stuff();
}
//go home
:P
Programming is easy: Programming is a lot of fun but don't ever think of it as being easy. It takes a lot of experience, learning, and failure to get better at it and be humble about it.
Tools do it for me so I don't need to learn what happens underneath the covers: Tools make things a lot easier and allow you to get things done quicker. However, you still need to know and get familiar with what's happening underneath the covers because sooner or later you will need to pop open the hood.
Lack of curiosity
It's all about the newest and the coolest technologies: Not necessarily. It is about what's right for the customer and the problem you're trying to solve.
"The problem is not in my program, it's a bug in the library / OS / language."
"It worked on my machine! What is wrong with yours?"
"Everything is a pattern, you just have to find them."
"I don't need to test because I only made a one line change."
"Source control is a waste of time for this project."
The real problem I've seen with programming tyros is "programming is magic", meaning not truly groking that the computer will operate exactly logically, and will do exactly the same thing every time given the exact same input.
They write something that they think should sort of does what they want, and then when it doesn't work, rather than try to approach the problem logically, they start changing things semi-randomly, hoping, apparently to appease the gods of computer magic by their sheer tenacity or willingness to abase themselves upon the altar of whimsy. They feel that the computer is capricious, and changes things randomly, and the best they can hope for is to get things to a vague approximation of working, and hope the stars stay aligned for long periods.
Of course, even to experienced programmers, it can feel that way sometimes, but there is an inherent knowledge that what is happening is happening for a specific reason, and you just have to dig down to get to that reason.
That their program will work.
If the previous hurdle is overcome miraculously, that their program will work as expected by the end user
If the previous hurdle is again overcome miraculously, that their program will stand the test of time, i.e that it will be maintainable
If all of the previous hurdles are again overcome miraculously, that their second system will be as good or better
That you have to have design patterns in your code.
That their solution is the One and Only True Way To Solve The Problem, and everyone else is just dumb and wrong.
most harmful misconception (financial version):
"That a college education is required to know or have understanding about how to write software."
"I am going to make a ton of money by playing with computers!"
Edit: Another one that drives me nuts:
"The other guy's code isn't calling mine correctly, so it's not my fault the system doesn't work." -- with no proactive investigation, diagnosis, suggested patch, nothing. As a manager or a team leader, this really gets under my skin.
The worse misconception I've encountered, and the hardest to be rid of, is that programming is writing code, and not reading it.
The most harmful misconception is: You are done when you get the code to work.
That you have to use every feature of the language you are learning, inheritance above all.
Updated: be obsessive about assembly inline code in C
That cool == usable.
Disabusing them of the notion that "perfect but very late" is better than "acceptable and on time".
No one is going to care if some weekly report runs in 5 seconds rather than 8 if it is two months late.
It has something to do with computers.
That their code doesn't need to be documented. They're the only ones who will ever look at it, right?
The most common misconception is that you can write an application by starting your favorite IDE/editor and then write code immediately.
Yes, it will create an application. Yes, it's probably cr#p too when you're finished...
You start developing software by first creating a design. Preferably with pen and paper or with some useful tools on your computer. Writing the actual code just happens to be a small part of the whole process. (If not, you're doing something wrong!)
The most harmful misconception is to assume that people in software industry know what they're doing. Beginners tend to trust everything written in product's documentation, they trust error messages and exception descriptions. They even trust stuff posted on blogs.
That all there is to it is building cool new stuff everyday. Maintenance IS a part of programming!
That the hard part is typing in the code. The farther up you go, the more that comes to be the easy part.
Early on:
But isn't all the world an x86?
I have to pass a size with that buffer?
Error checking? Why?
The STL is too complicated. I'd rather implement everything myself.
(Use std::swap()! std::swap()! Start there, then branch out to more...)
Not knowing that you cannot treat binary buffers as strings without first null terminating them. (Think: read(), recv(), etc.)
Later on:
Wrongly thinking that...
That there are 8 bits in a byte.
That garbage collection will save you from resource management.
Endianness? Padding? I can't just write(), send(), etc. the whole struct?
Threads and deadlocks and race conditions oh my.
i18n? (2009, and we're still learning that the earth is round!)
I could have written this better. Time to rewrite. (Hint: refactor.)
Time related, wrongly thinking that:
That within a calendar year, DST starts before it ends.
That all time timeszones are + or - whole hours.
That the max UTC offset is + or - 12 hours.
That there are 60 seconds in a minute.
That 1900 is a leap year.
Wrongly thinking that:
16-bit is enough to hold a Unicode code point.
I can ignore FOSS libraries that will do 90% of the work for me.
That C, C++, Python, Lisp, C#, .NET, Java, VB6, Ruby, PHP, Bash, assembler is the perfect language for every task!
That the program has to be correct the first time.
Fail fast, early, and often. It's the only way to get better.
That they will "break" something!
Or, to define "newcomers" as those that don't do it, "It'll be easy to change! It's software!"
cheers,
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 13 years ago.
Duplicate:
Learning implementing design patterns for newbies
I have been a developer for years and have my way of developing and have always kept up with the latest techologies. I want to start using a design pattern in the hope it will improve my development speed but I need to find one to apply and I need to find a full open source sample that demonstrates it.
I use and have an application that uses LINQ to SQL and .net 3.5 I tried to apply the repository pattern but found the structure complex and having to hack my way through it.
Any advice for someone who wants to better their programming style?
Read blogs (RSS Feeds are prime). Read magazines. Read random MSDN entries. Write little trial applications. The only way to keep up is to discover it and practice it.
Patterns aren't really "tech" in the traditional sense. Using patterns means applying your specific knowledge of a domain to a problem keeping in mind the patterns which apply to that domain. They are useful to exactly the extent that you have a base of experience to put them in context.
The repository pattern, for example, is maybe not the best starting place for constructing a database architecture based on a pattern. Have you got a simpler pattern implemented such as Table Module or (in the specific case of data access) Active Record? If not then perhaps you should start there. These patterns focus on a fairly limited, basic way of organizing data and operations. Repository is more like a meta-pattern that then builds on top of these patterns, organizing a complex domain-data boundary into a simpler collection-like interface.
Two books that I would suggest reading are:
Refactoring: Improving the Design of Existing Code (ISBN: 0-201-48567-2)
and
Refactoring To Patterns (ISBN: 0-321-21335-1)
Both are great books that will help you, at a high level, understand the when's and why's to applying patterns to your code. In addition, they are great reference material for some of the most commonly used patterns out there.
To be clear, these books are by no means the "complete library" of design patterns.
My simple advice for bettering your programming style:
Pick a technology that you find productive and "fun" and keep with it to learn how to fully explore it's potential.
Don't try to learn all the new technologies all the time - just keep yourself oriented.
Seek advice and solutions where and when you actually need them - don't waste time learning solutions to problems you don't (yet) have.
Regarding design patterns... Well... I'll probably get shot for this, but I don't really like the idea of cramming them all into my head "just in case". They are really a cooking book of "good solutions" for common problems. My advice here is: Whenever you run into problems that you can't come up with an obvious/immediate solution for - use them as reference.
Learn from your mistakes (you'll make them).
Don't marry your code. Throw away and rewrite is an excellent way of bettering the style.
I would sincerely recommend dofactory.com
which also offers code examples in vb.net + c# for all the design 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 10 years ago.
When deciding whether you are getting involved in a fairly big open source project in order to contribute to its code base, how significant are the project's issue tracking facilities (i.e. tracking of bugs & feature requests) for your decision to contribute or not?
There are still many non-trivial (huge code base) open source projects out there, that don't formally do issue tracking - and while some contributors may indeed still do this privately in the form of miscellaneous "ToDo" lists, I have personally found the lack of availability and established use of issue tracking to be a fairly reliable indicator for a lack of organization, structure and overall project coordination.
What are other people thinking?
I would say it would be a fairly significant factor.
An open issue tracking system is one component of what I would call having an 'open development process' - where anybody who is so interested can see the developers' decisions as they are being made, and contribute to the discussion.
Some projects don't really have an open issue tracking system (or a good one) but still have publicly visible discussion lists, maybe an IRC channel where there are always people on, maybe a forum/bulletin board, etc. In my opinion such projects are still fairly attractive in terms of contributing to them.
What I have personally found is that while I work with very many different open source projects out there, I don't ever really become part of a larger group. However I do find bugs and would like to report them and would like to find out if the issue was found before, and when and if it is going to be fixed.
For myself personally, an open bug tracker or mailing list where I can shoot a one-off email to notify people of the bug is better than having to signup for the mailing list or register for the bug tracker. I already have enough accounts all over the place, I don't need yet another one for the piece of software.
So the friction involved in reporting a bug is definitely an issue, also being able to view the status of bugs and having them be searchable is a big help in determining on whether or not I will report my issues to the project or not.
So yes, open issue tracking, easy to use, easily visible (digging through a page for 20 minutes is not my idea of fun) and best of all with as little friction to get a report of a feature wanted/bug in.
A number of projects that I'm involved with still do everything on the mailing lists. If a bug comes in (and gets confirmed, and can be fixed) its put in some kind of BUGS file within the repository. As things get fixed, the entry in the file is noted.
Not my preference, but its what other contributors are accustomed to and like. It could be that someone doesn't want the hassles of hosting the bug system, dealing with the SPAM it might attract, etc. Could it be that the project doesn't get very many bug or feature requests?
The real question of 'should you' really revolves around the code, no? Or how much you could learn / teach by working with any particular group? If you begin contributing and show yourself to be friendly and useful, you might meet no resistance when suggesting something like trac or bugzilla.
The only thing that would make me consider steering clear of any given project would be a total lack of any kind of version control. But, even then, I'd have to weigh what I'd be given up against the hassle of managing patches with racy merges.