|
New features in a language never make it possible to do something you couldn't do before. Their purpose is to make coding easier to do and potentially easier to understand. So why in the world would you, just for the sake of using a new language construct, rewrite perfectly good code?
On the other hand, if I'm writing new code (whether for a new product, or to implement a new feature in an existing product, or to fix a problem with an existing product, if the feature is useful and makes my code more readable, then of course, but never for the sake of its newness.
|
|
|
|
|
because i have to write code that's used across multiple platforms, with many different compilers.
|
|
|
|
|
CodeProject brags on 10 million users.
976 responses to the survey.
That's a response rate of 0.00976%. 
Even at 1 million users, that's only be 0.0976%; less than 1%. 
Time to code those vote-bots!  
|
|
|
|
|
I will use new features in new code, but the only time I'll change code is when I'm fixing a bug in it or otherwise modifying it and the new feature will completely eliminate a third party library or compiler specific functionality that can be replaced with language features that are in the standard supported most of the current compilers. An example of such a feature would be command-line arguments between Fortran 95 and Fortran 2003 where it went from only being provided as a compiler specific function and went to something that is part of the standard for the language.
However, if the new functionality has been implemented in a way that causes a major rewrite or if the functionality will not allow me to remove a dependency, I will likely not change to the new feature, though if I am already modifying some other part of the file, I may add a comment to the code in that region to say why I didn't and possibly what conditions would need to be met for me to switch to that feature.
|
|
|
|
|
Seasoned developers will tell you that you shouldn't change old working code without a good reason. Joel Spolsky has had more than one blog about how bad it is to do a complete rewrite. His most famous one is Things You Should Never Do, Part I[^]. He speaks of a tragic story when Netscape decided to completely rewrite their browser. This decision was made at the height of the browser wars, and put them way behind their competition. This single decision may have led to the downfall of the entire company. There are many other examples of this happening, but this was the most egregious.
However, there are a variety of code analysis tools which make it very easy to refactor existing code that have come out in recent years. These tools do everything from telling you that you are missing your documentation headers, to rewriting entire blocks of code automatically. For many years this all had to be done with 3rd party tools. When Visual Studio 2015 is released, these tools will be included in the Roslyn platform. .Net developers may be more likely to be willing to rewrite old code to use new language features after this functionality becomes part of the standard Visual Studio platform. With the addition of automated unit tests, this proposition is much less risky.
|
|
|
|
|
Although not quite the same, I'll use the analogy of clipping coupons for discounts on purchases.
For some people, when they see the coupon they clip it and buy the item.
For others, if they see a coupon for an item they buy they clip the coupon.
There's a certain satisfaction to using the coupon, but it should not control your taste.
On the other hand . . .
Seeing a coupon for an item may peak your interest in something you've not considered and will find it most enjoyable, your life richer, and all is well in what is now the best of all possible worlds. So, too, with a new language feature. Presumption: you've got good enough judgement in this latter case to waste neither time nor money.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I think that's a great and accurate analogy. While I like to read about new language features, I'm going to adopt them if they're going to help me solve a current problem. After testing the new features I'll keep them in mind for refactoring of older projects. However, unless the older projects are bug-laden I'm not going to do a rewrite just for the sake of using the new features. As others have written, don't fix what isn't broken.
|
|
|
|
|
I use them if and when I need them.
Admittedly, if it seems really interesting, I might check it out.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Whenever something new is introduced (to the world, or to me; because I am pretty much late in programming world), I try creating a sample project that uses the feature.
For example, when I was introduced with async/await programming. I create a new project, named it HelloAsyncAwait and then wrote the application's code to test the capability and pros and cons of the async/await methods.
Similarly, I would never use anything that I have no idea of in my application projects that are working fair. Using a code, that I have no idea of, is just like adding more and more salt when I need some sugar in my juice. Perhaps, that is what I think of new features. They can be of a great importance to one framework, but not of any good to a few.
I would suggest that when anything new comes to public (or if you are a beta fan), try them in a separate project, I create Console applications. They help me to first gain grip of the framework or feature and then use them efficiently in my own applications.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
And usually in new projects or forced edits (updates, fixes). And after these features have been used, understood and tested by a number of people.
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
|
|
|
|
|
Only in case where the new feature solves me a bug/problem that can not be solved in other way I will use that feature in existing code...The reason? I rather do not update framework version of running application...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Depends on what the new feature is, is it useful for something I have bodged in the past, is it useful for something I have been meaning to do, is it useful for something that isn't working right, is it useful for something that is coming up, is it of no immediate use at all?
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
I worked on projects with people who incorporate new features just for the sake of incorporating them. *shudders* The rest of us on that project pretty much had to do a rewrite.
I prefer to use the correct tool to solve a problem.
|
|
|
|
|
The biggest factor when deciding whether to use new features is whether they will be available on the target platform, it's no good writing in .net 5 if the target server only has 4.5 installed.
|
|
|
|
|
Gone are the days when something utterly revolutionary would appear in a programming language.
Game-changers are few and far between - compare the addition of MS's Jet engine to Visual Basic to, say, the introduction of Entity Framework. One opened up a whole new world, and made VB as serious a contender as anything else that was in the market at the time - the other is just the latest in a long, long line of data access tools.
If you're facing a problem, odds are that many others out there have already faced it, and solutions exist.
The majority of new features to most mainstream languages tend to be tweaks of old ones, or alternatives to existing ones. So there's no rush to put the latest and greatest into existing code, and deadlines tend to prohibit adding brand new things that are not yet fully understood to new code.
So, and I suspect I'm not alone in this, my approach tends to be to have test projects on the go, where I experiment with the new features, until I feel comfortable enough to include them in production code.
|
|
|
|
|
I first let new features settle before using them.
I prefer a stable release over a new one.
A lesson I learnt the hard way.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
...I wouldn't increase the target framework version on an existing project - it would make updating customer versions potentially a lot more fraught.
A new project though would likely be at the new target version, though I'd probably want to play with new features on private or internal utility projects before they got into new code.
If it ain't bust, don't fix it! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
That basically sums it up...
|
|
|
|
|
|
Yes, it should have been new features.
Piyush K Singh
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
