|
Pablo Aliskevicius wrote: This one avoids the = against == pit.
LOL, that one kills me, because I'm constantly switching back and forth between C# and VB 
|
|
|
|
|
gervacleto wrote: if(Something)
One();
two();
...
This can also happen in C#, but auto indent of Visual Studio makes you less likely to fall in this trap.
gervacleto wrote: if(MyBoolValue = false){
This happened to me several times and the warning saved. I always pay attention to warnings.
gervacleto wrote: if(MyBoolValue)
I do not consider this a bug, it is actualy a coding style. I do it myself.
gervacleto wrote: for(int i = 0; i <= MyArray.GetUpperBound(0); i++)
Never used this construct, so I wouldn't know. But will keep my mind to it in case I run into this. Thanks!
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
the semi-colon on the end of the conditional, the block will always execute.
DoSomething is in its own little world and will always execute.
C# will just raise a warning on the conditional but will not compile with the DoSomeThing becuse it is not a method or an assignment.
But, what if it is not C# compiler, then there could be compilers that would allow this and it would be worthless code, i still use Crimson, NotePad, etc to write code. Either to many semi colons or not enough !!
|
|
|
|
|
I bet that in DoSomeThing there is logic to handle the strange case when the if condition is not firing properly. 
|
|
|
|
|
Ooh, nasty! Couldn't see it at first.
Check out my latest article: Celerity: How it was all done.
A complete how-to on our sensor-driven head-tracking virtual reality tunnel game in C#.
|
|
|
|
|
Delphi4ever wrote: if(SomeThing == SomeOtherThing);
I remember years ago spending a few hours debugging why (in C++):
for (int i=0; i<10; i++);
DoSomething();
where DoSomething executed only once.
I only had to learn that lesson once!
Marc
|
|
|
|
|
There may be trouble ahead!
There's a constant debate at our place about the use of third party libraries. Half our lot refuse to use them, preferring to write absolutely everything themselves.
It's no coincidence that the developers who use third party stuff get their tasks done quicker and with less bugs opened from said tasks. I'd call this good productivity.
The current Not Invented Here debate is based around expression parsing. We want to be able to interpret expressions defined in Xml files in place of static attribute values, DateTime.Now.ToString("format of some sort") is a great example of what we need to be able to do.
Earlier in the week I introduced Flee - Fast Lightweight Expression Evaluator[^] to members of the team, upon which reasons were being invented not to use it.
Autonomously I've knocked up a working example that covers all the requirements we've specified in about an hour using Flee. Our planning indicates that we've put aside 5 days for writing an expression engine from scratch. Now I can guarantee that in 5 days I'd be able to write something that can evaluate simple static property and method calls, but very little else. In 1/40th of the time using a third party library I've done the job as far as I'm concerned and we've got a component that can do a hell of a lot more to boot. Not only that, but it's been peer reviewed on CodePlex and on here with almost entirely 5 star ratings and nearly 15,000 downloads on CodePlex. It's LGPL licensed and as we're not modifying it and it's already freely available, we won't have a problem redistributing it.
If they're not watertight reasons for using a third party component instead of rolling your own then I don't know what are.
Now I'm totally biased when it comes to how I develop. I 'll use any third party library that I feel can help me get my job done quicker so I can concentrate on quality and I absolutely detest reinventing the wheel, which makes it very difficult for me to see peoples' points of view when they object and claim writing everything from scratch is somehow better.
What objections do you have to using third party stuff?
|
|
|
|
|
My issue with libraries is that they often do something that's nearly but not quite what you want, and you end up changing what you want to fit the library, which is backwards. This is particularly true with more complex frameworks like Hibernate, Spring etc. A good example from my personal experience is lambdaj[^], a fluent query library in Java. It looks great, until you realise that it uses dynamic proxies so you can't use it on a list of strings, it loads everything into memory so you can't use it on external data sets, and to work around those two things is more effort than writing the subset of query functionality that you need.
On a project level, it also means that anyone new to the team has to learn a new library, whereas presumably they are familiar with the standard library (java.*, System.* etc) which a home-rolled version will use.
If it really, actually, does do the thing that you want, then fair enough. But it's surprising how often you find that a little way down the road you have nasty wrinkles in your code where it butts up against the library, because that third party tool doesn't actually do things the way you want to do them.
|
|
|
|
|
I understand what you're getting at. I've also come across libraries that haven't quite done what I was after. In that case you're completely correct.
Obviously I'll evaluate a library first. It's not as if I download the first thing I find and plump for that like it's cool. It also has to have good documentation and positive peer reviews because without them you're on your own, with someone else's code.
You can't guarantee that it will be any easier picking up someone's homebrewed alternative. You'd still have to learn that and it might not have the same documentation or review coverage as the third party component. This is where I find independent peer reviews are worth their weight in gold.
At any rate, I've still got 39 of the 40 estimated hours left for ironing out my wrinkles.
|
|
|
|
|
totally agree.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
The make-it-from-scratch vs. use-third-party-solution debate will never end.
Each choice has different, uncomparable costs and benefits, so it's fundamentally an apples vs. oranges debate. It's perfectly normal for the final decision to be made due to irrational or irrelevant reasons.
Most people err too much on the side of make-it-from-scratch, though, as they don't want to go through the effort of figuring out what third party components exists and are good enough for the task. However, I've seen people who dislike coding (but have to do it as part of their job) err on the side of trying to get third party stuff do everything for them.
Anyway, the main reasons to not go for a third party solution are:
1. It costs too much / license is not flexible enough.
2. The problem it solves is too simple; making your own solution takes less effort than figuring out theirs.
3. Whether or not it will be maintained in the future is questionable; maybe you'll have to write your own solution, anyway.
4. It's too buggy or poorly implemented.
5. Your problems are slightly different from the problems it solves.
|
|
|
|
|
The biggest challenge is legal. Do the libraries explicitly grant you an IP license, do they specifically state they are free of encumbrances of any sort, do they clearly give you the right to sell and/or distribute the code?
I have seen deals go bad over licensing third party code - both from the point of buying a component to the issue in buying an entire product or company. Be careful.
But don't reinvent the wheel. There are tons of third party libraries with excellent licenses that save a TON.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
I pretty much won't consider third party stuff if it requires another dev to do some non-obvious step to get it running on their computer. If they just have to get latest from TFS and it will work, that's great. If they have to run some license installer on their machine before it will work, that's a no go.
|
|
|
|
|
I agree with Bobjanova. I'm not against using libraries, but you have to think it through thoroughly and if possible accept it's limitations, something not always easily explained to managers.
Another option is to create your own reusable framework (for very specific stuff).
|
|
|
|
|
I'm not against third party stuff in general, but..
jim lahey wrote: as we're not modifying it and it's already freely available, we won't have a problem redistributing it.
You don't have to modify it .. yet. Someday there will be a problem where you have to choose between modifying the library or some worse option. That's not uncommon (what library really does exactly what you wanted, rather than exactly what someone else wanted? often the problem is hard to work around, too), and it's often bad news for the license.
Some other reasons I frequently have are
- Is crap. No contest there, I think. No one likes a library that's crap.
- Impossible to use. Applies to 80% of all open source libraries pretending to be "portable". What they really mean is "works on one's-complement processors and platforms where ints are 27.5 bits" - it won't compile with MSVC.
- Not as good as I could make it. Sure it'd save me time, but I don't like using bad solutions just because they're easy. Probably doesn't apply to a widely used 5-rated library though.
- Integrates in an invasive or crappy way. Especially happens with libraries that are too framework-like.
- Is a moving target. Not so bad if you can ignore new versions, but sometimes the new version has a feature that would save you a lot of time .. and also has breaking changes. Being forced to make a choice like that pisses me off. Bonus points if that happens at least twice a year. Sometimes old versions even have an expiration date (anyone who does this can go die in a fire), or it auto-updates itself (again, go die in a fire. no one pulls this off without ever introducing a problem - that I will get blamed for of course).
- Is dead. Dead projects don't inspire much confidence in me, even if good things are claimed about them. Bonus point for pretending to be alive when they're not.
|
|
|
|
|
When you are developing a long lasting product, using third party components has several risks:
- you can face a bug all of a sudden and get in deep trouble - usually at the worst moment - because there is no maintainer available (the company went out of business, the freeware project died or you can't afford the cost);
- trying to fix a bug yourself from open sources can be a nightmarish endeavour; libraries can be huge and written by gurus in the least readable way; architecture documents are often unavailable; all you can do looks like quick and dirty hacks;
- adding a feature of your own when required is an assault course as well;
- packages are often overfeatured for your needs; you'll have to carry a monster (redistribute it and complexify your installers) for the rest of your life;
- big packages are sometimes so complex that the effort it takes to master the API and comply with it may not be worth;
- last but not least, portability is the main thing; my code needs to be compatible with all MS compilers from VC6 to VC2012, as well as gcc, and future compilers; if a third party library fails to support one of these - which is quite likely to arise -, I can get in big trouble; and this is unpredictable and out of my control.
When dealing with your core business, integrating black boxes is not so reasonable. In the long run, you need full mastership of your source code.
|
|
|
|
|
Third-party technology is just great...when it's right at all.
Let's leave aside considerations such as bugs in the package. IBM's old mantra that "you never get the last thousand bugs out" will be true until the Sun goes nova, and we all know it. But the probability of such bugs in a third-party package is much less than that of bugs in one's own, newly designed solutions, so it's a false trail in discussions like this one.
The ugly secret about third-party tech is that packaged solutions are never free of constraints. To use a third-party library, you have to be reasonably certain that the constraints it will impose on your application are bearable. Sometimes, you have to err on the side of caution and decline to take the risk.
My business is hard-real-time, so I'm very sensitive to that. If a third-party package can't guarantee me performance within my time constraints, then I can't use it. Not "won't." Can't.
Other sorts of development have other needs. I recently turned away from a popular XML parser because it imposed a callback requirement on a legacy application whose architecture was inimical to that approach. In another recent case, I spurned a set of .NET facilities because they'd clash with my need to keep the addresses of certain dynamic memory constructs stable. No doubt there are other cases of this sort that I just can't recall this morning.
The application is the ultimate determinant. Does the third-party library you're considering fit within the application's constraint envelope? Does it make "philosophical" demands on the application's architecture? Might there be forward-looking consequences to using it that should be considered in the present? Will your wife find out? Everything matters. As some very bright people have said:
"You can never do only one thing." -- Marc Stiegler.
"TANSTAAFL!" -- Robert A. Heinlein.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
I am very well aware of third party tools. Actually we use one which costs a lot. The project on it has about 20 Forms, 30 UserControls, 10 classes, each one using that software more or less.
The first 2 years worked out fine. Then came a "major upgrade". And, guess what: they changed about all of the namespaces (from productxyz.xxx to productxyz.xxx.zzz). And nothing worked anymore, so rebuild, reinstall over a 100 clients, ecc...
And the next case: well known ChartFx. License (even paid) after 7 years expired.. What dit I do: forget ChartFx and use Microsoft.Net Chart...
|
|
|
|
|
I am with you totally. I see complaints like the ones which have already followed your post all the time. Fact is most people have such large egos that it is easier for them to write something than to learn to use code someone else wrote - because they are already "experts" and no longer students.
We use boost all the time for as much of what it can do as we can possibly use. We use Google code (kml libs), we use zlib, we pretty much use anything open source that fits our needs.
If a half decent C++ dev can't wrap a library to give us a stylistically appropriate interface in less time than it would take to write the entire library, then that C++ dev is no use to us.
Most of the arguments against are straw men (presuming open source here). Will a 3rd party library be maintained going forward? Dunno - but sure as heck our own home grown solution won't be maintained by anyone else either. Is it any good? There are a large number of excellent libraries out there for many, many common programming needs. They have had thousands of eyeballs and hundreds of consumers testing them and fixing them. Sure beats the size of our QA team. Code Project itself is an excellent resource for working code that has been peer reviewed the heck out of.
Do your research. Set aside your ego. Borrow code.
|
|
|
|
|
I've been a little surprised at just how negatively people perceive using 3rd party stuff.
Your point about ego is spot on.
|
|
|
|
|
I think there's a bit of a knee-jerk reaction among most developers when facing a need like that: hell I'm a programmer, this is what I do, I'll write it myself and get exactly what I want.
But that isn't always the right way to go. I used to work at a software company where just about all of the tools were built in-house, from source control to back-end processing frameworks to load balancing. This was a fairly small shop where there weren't really enough programmers for the workload and projects were always behind. It amazed me that so much time was spent building and maintaining software that could be pulled off a shelf, when the programming that really had to get done was behind.
Worse, due to time constraints the in-house software was frighteningly buggy and unreliable, and no one wanted to fix or maintain any of it (especially the guys who wrote it). It got so bad that in one meeting the CEO blew up on the guy who was the main push for in-house solutions, pretty much saying that it had been a mistake. From his point of view, he was paying programmers to write code that was already written and didn't make money, instead of getting cracking on the code that actually did make money. When you're a software company, you don't want your programming resources tied up in creating software you can't sell.
Of course, the main argument for the in-house solutions was that the off-the-shelf solutions didn't fully meet the needs, and that was somewhat true although those things could have been worked around. I guess the moral of the story is, if you want to go the in-house route, make sure that you have the resources to do it right and maintain it. And make sure that management knows that it will require extra time and resources (a.k.a money), and that it will be hard to go back once the in-house software is entrenched.
|
|
|
|
|
I'm not dismissing the use of libraries, I just haven't had good experiences with them so far.
We once ran into a bug with a communications library (back in the days of dial-up) and after we identified it, we called the vendor. They said it was a known issue and would be fixed in the next release. We said, "Great, when's the next release?" They said, "In six months." We had a 6 week delivery date. So we had to trash it and write our own, which ended up being smaller and faster.
Libraries add bloat. The library does 10 things, you're only interested in 2 of them.
Management decided to get involved because they didn't like our delivery estimate and so they went out and purchased a library that they had seen a demo of and then gave it to us expecting that all we had to do was integrate it into our existing system. That's simple, right? No excuses for bugs since it was a purchased product the only cause for errors would be from our staff. As you can imagine, it didn't go well and caused much animosity with management that didn't need to be there.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
BrainiacV wrote: gave it to us expecting that all we had to do was integrate it into our existing system. That's simple, right?
Haha, reminds me of my old CEO. Whenever asking for (sometimes major) code changes he'd always say something like "it's an object, right? Don't you just have to change a couple of lines?"
Apparently someone had explained OO to him in glowing terms at some point. A little knowledge can be a dangerous thing.
|
|
|
|
|
Third party drawbacks:
1. Have to learn their api. sometimes its mind bending sometimes simple.
2. Depend on their support/consceintiousness for bug fixes and upgrades.
3. Can't fix a bug if you have a special case. even if you get the source code.
4. Don't always know you cant solve a problem until you have wasted a week on the componenet.
5. Don't own it cant enhance it.
Pluses:
1. debugged already
2. learn from other peoples problems - may get features you hadn't even considered.
|
|
|
|
|
Great article.
It is supposed third party tools are the salvation to those activities one is not the best at. But, how many hours are spend before buying? How many hours are dedicated to understand other's logics? What if the documentation lacks of good examples to understand how to get the best of tool?
Sometimes, you have to start from scratch.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
