# New answers on old questions using new language features

Times and technologies advance, and, as a consequence, code that was up for review 'years ago' would be done differently using current technology.

Is it OK on Code Review to add answers to old questions that suggest ways to solve those old questions using the new technologies/language features?

A specific example came up: Remove-Last-Comma-Problem

This three-year-old question has now had two new answers given today (here and here). Both answers rely on Java8 Language features which did not exist (and were not even speculated) at the time the question was asked.

Is this OK? If it is, are there any constraints?

• Why wouldn't it be ok? Why would there be constraints? Is anything wrong with that? – Mathieu Guindon Jul 31 '14 at 3:40

Yes, modern suggestions should be allowed on old questions.

Initial authorship of code is only part of the software lifecycle. It is quite possible that code that was posted to Code Review years ago is still alive today, and the author might even be interested in maintaining it up to modern standards. Times change, and unmaintained code can "rot". For example, Y2K was once not much of a concern, MD5 was considered a reasonable hash algorithm to use, and Java's String.substring() used to have different performance characteristics. Having a modern perspective added to the pool of knowledge can only be beneficial.

Furthermore, we can't reasonably prevent modern replies to old questions, unless we delete anachronistic answers or place historical locks on all old questions. As with any answer on Code Review, reviewers contribute advice that they feel is helpful, and the original author can take it or leave it. Anachronism might not be a concern: we don't know the original author's answer-acceptance criteria, and in any case the original author is not the only audience for answers.

• “we can't reasonably prevent modern replies to old questions” Why couldn't we just use the tools for dealing with other bad answers (downvoting, flagging, voting to delete)? (I don't actually agree with rolfl that we should do this, just questioning this part of what you said.) – svick Jul 31 '14 at 9:43
• @svick because I also don't consider downvoting and deleting to be reasonable reactions to censor and suppress such answers. – 200_success Jul 31 '14 at 9:58

I don't see anything wrong with posted answers with new technology on old posts. Times change and what would have been good advice 2 or 3 years ago might not be the best advice to give today. It is also reasonable to assume that OP just might still be maintaining the code and should be alerted to new alternatives.

I think we should be careful about two things when adding new answers to old questions though.

1. It must be an acceptable Code Review answer. Meaning, it must be an actual code review. Neither of the answers referenced give a meaningful review. They offer alternative solutions without any explanation as to why the alternatives are better.
2. Answers providing solutions using new technology should probably disclaim themselves a little bit. "I know that Java 8 wasn't around when you posted this, but I think this new feature [x] would be perfect for this because [reasons]." This answer at least mentioned the new technology, but failed to mention that it is a new technology.

Stack Exchange is built to be a question and answer archive. Part of this paradigm is allowing new information and technologies to be taken into consideration long after the question was originally asked and answered. I would say that not allowing new answers goes against the spirit of Stack Exchange in general.

• We must not forget that not only OP is reading the answer and learning, but it's beneficial to other as well. We are more focused on providing something for the OP, but we can also be a little bit more "large". – Marc-Andre Jul 31 '14 at 14:51

# It Depends!

Is it reasonable to assume that the code could be updated and still work? The answer to this question depends on many factors.

If we're talking about MS SQL Server, stored procedure, functions, views, etc., all reside on the server or operate on the server. When we're talking about databases, they're not typically updated until it is 100% absolutely necessary.

SQL Server 2005 is getting a bit old today and there have been several versions of SQL Server since this version... yet there are tons of SQL Server 2005 servers in use today. Language features added since SQL Server 2005 simply won't work on a SQL Server 2005 server. In a case such as this, the server version should be specified in the question, and answers using language features that won't work on the specified server version should be downvoted at a minimum.

On the other side of this coin however, I'll provide the example of Objective-C and iOS development.

When a new version of iOS comes out, users quickly upgrade to the new version and at a high pace.

As of this posting, over 87% of all iOS devices are running iOS 7.x, and another 10% of users are on version 6.x, leaving fewer than 3% of all iOS users on version 5.x and lower. Another interesting aspect is when you look at the per device breakdown and see that the bulk of iOS 6.x users are on either the iPhone 3GS or the iPod Touch 4G, neither of which is capable of upgrading to iOS 7.x.

iOS apps are always doing one of two things. Either they're constantly updating themselves with new language features introduced by the new version of iOS, or they're not being updated at all. Extraordinarily rare is the iOS developer who is still updating his app, but needs to continue to support devices on iOS 5.x.

As such, an answer posted to an old Objective-C question which suggests new language features is absurdly appropriate because either the asker simply won't care to look at the answer because he's no longer maintaining that code (in which case the answer doesn't hurt), or he IS updating his app still and he is always pushing for it to be as modern as possible.

And in fact, while SQL Server questions should specify what server version they're on, I'd recommend iOS questioners let it be known if they're waiting for iOS 8 (or whatever next version) before their release so that EVEN NEWER features of the language can be suggested!

• By token of this answer, are you suggesting that Swift answers are now valid on any Objective-C question ... (as an extreme example)? – rolfl Jul 31 '14 at 22:27
• Maybe... this would obviously be the most extreme example... but given that Swift and Objective-C can exist seamlessly in the same project and there'd be no technical hurdle in implementing the code in Swift, it seems sort of okay. But for this extreme of an example, I think you'd have to go out of your way to demonstrate that the code is significantly better from some sort of performance standpoint. From a readability standpoint, it's automatically worse because it exists amidst ObjC source code and readers may not be familiar with Swift. – nhgrif Jul 31 '14 at 22:47
• But at the same time, this is truly a different language. It would be about akin to writing a C# answer to a VB.NET question, I think. And I don't think that'd be appropriate. – nhgrif Jul 31 '14 at 23:21

Is it OK on Code Review to add answers to old questions that suggest ways to solve those old questions using the new technologies/language features?

Absolutely! If there are new ways to kill a zombie, we want to have them here!

The problem with the linked answer isn't that it's using language features that didn't exist when the question was asked; it's that the answer doesn't quite review the OP's code; it's just showing the shiny new way, without much explanation.

• What else is there to explain, though? "You retroactively reinvented the wheel?" – 200_success Jul 31 '14 at 4:27

I feel a bit differently, for all it is worth. I think killing zombies is great, but I do think Answers should be given in scope of the original Question, as in, review the code with the version that was available at the time the question was asked. I realize this is unpractical in some cases, but I think context should supercede "newest features" of X language.

## No

Reviewing code requires understanding the code context. The context in which the code was written is just as important as the code itself. In many instances, the question asker adds to their context, saying things like: I can't use third party libraries, or I know that I am reinventing the wheel, or I am a beginner.

Those context statements indicate the constraints on the review. There is no value in suggesting an improvement that is not useful to the asker. You can challenge those constraints, and say "why can't you use a third-party-lib", etc., but recommending a third party lib when you've been told it is not possible, is.... useless.

The 'landscape' of the language at the time the question was asked is an important part of the context. At the time the question was asked, it was not possible to suggest the features that were only introduced 3 years later. The language features are an implied 'constraint'.

Unlike Stack Overflow, Code Review is not a perpetually maintained reference for current fixes to old problems. Code Review does not have the same concepts of duplicates as SO, and we don't have the same concepts of many things. Similarly, we review the asker's code in the asker's context, not in the context of our convenience.

If we allow people to start updating old questions with new answers that assume a different context, then we should revise a lot of things about Code Review, like duplicate handling, and so on.

• I have to ask.. What do you mean by "allow people to update old questions with new answers"? Everyone is "allowed" to do that now by default. (Technically speaking.) I just feel like if you're going to take that stand, you should offer some ideas on how to stop it from happening as well. Are you proposing that all questions older than X get locked as "Historically important."? – RubberDuck Jul 31 '14 at 4:08
• Good question @ckuhn203 - not sure what I mean. I am somewhat worried that people will just trawl through old questions and propose updated answers... which just feels icky, and I want to know if my icky feel is common, and, if it is, is there enough ickyness to make it worth finding a way to dissuade people from doing that. one thing at a time though – rolfl Jul 31 '14 at 4:12
• I imagine that it'll only happen with these kinds of old questions that already attracted many (bad) one-liners. I don't think someone will start posting a C++14 answer to older C++ questions. – Jamal Jul 31 '14 at 4:14
• Think of all the auto typed lambdas @Jamal, or whatever. C++ is different-ish because, there are specific specification tags for C++ (like C++14, etc.) which is a different problem entirely. – rolfl Jul 31 '14 at 4:21
• I suppose, but I do know that some do post C++11 answers on plain C++ questions anyway. I try not to do that so much myself. – Jamal Jul 31 '14 at 4:38

I'll have to go with @rolfl's answer instead of @200_success's. While saying 'initial code authorship is only part of the software lifecycle' is a very nice idealism*, code refactoring by current code maintainers of the posted code here can't possibly depend on newer answers to the original question years on. I would imagine that the current code maintainers ought to have posted their own questions, or explored newer and better solutions by themselves in the future.

Very hypothetically speaking, if we have helped someone solve the Y2K problem here (handle YYYY instead of YY), should we allow new answers to solve the Y10K bug (handle YYYYY instead of YYYY) down the road?

Therefore, I think we should naturally let questions 'retire', and if we do come across way-too-helpful answers on ages-old questions suggesting new features that are not available originally, perhaps an edit remarking so should do it.

* - This reminds me of coding for violent psychopaths, but that's another story...

• The Y2K problem and the Y10K problem are different problems. An answer to the Y10K problem should only be acceptable to a question asking about a Y2K problem if it also solves the Y2K problem (and if someone is interested in posting an answer to a 14-year old question). Questions don't have to be 14-years old for the language asked about to have developed new language features. Objective-C gets new language features once a year. – nhgrif Aug 10 '14 at 14:00
• Best case scenario, the answer with new language features helps the person who originally posted the question 18 months ago. Worst case scenario, the answer helps no one but doesn't hurt anyone. Somewhere in the middle is someone who wasn't the original asker who is coming across the same problem. If the old question doesn't have a new answer, this passerby is going to potentially use the old solution since the new language feature solutions were never added. – nhgrif Aug 10 '14 at 14:02