How to answer code related questions?

Question

Are hard-coded answers preferred over pseudo code?

Hard coded answers do provide other visitors to the site with some code examples, but at the root of the question is usually not understanding how to accomplish a task programatically.

Pseudo code seems to help people (me at least) think like a 'robot,' which might help with future programming questions too. For more detailed code-related questions, a pseudo-code answer may prevent the need for several loooong code responses.

Both have their advantages and disadvantages -- quite a dilemma. I suppose there is room for both, but maybe there's a good way to differentiate the two?

Answer 1

This is a great question.

Many people come here with questions that may be seeking just a tweak in their code. That's fine and it's wonderful that we have community members who can provide that service. But I think that's rather peripheral to the Stack Exchange mission, which is to provide great and lasting answers.

Some of the problems with providing "hard" code (that is, working code specific to a platform) are

1. Usually it will be correctly understood only by a minority of readers;

2. It does not easily translate to a solution to the same problem that might crop up on another platform;

3. Changes in the technology will likely break the solution within a few months or years.

Because of #1, I have long suspected that great hard-coded answers don't get many upvotes. This is a shame, but we can't expect readers to vote up things they don't understand (or don't really care about, anyway).

Hard code does have some advantages, though:

1. It serves as an executable witness to the correctness (or incorrectness!) of the answer.

2. It can be immediately usable.

Point #2 often leads to grateful questioners who go away with exactly what they were looking for.

On the other hand, pseudocode is attractive because

1. Almost all readers should be able to follow it.

2. It ought to generalize to many platforms.

3. It should have lasting value as a conceptual description of a solution to a problem.

Pseudocode has some weaknesses, including

1. It is (usually) not executable--and therefore more likely to have bugs.

2. It requires porting (translation) to be implemented in any given situation.

3. It does not have a clear definition and so can be misinterpreted.

Evidently, judgment is needed in deciding how to write a reply. I favor--and vote up--replies that identify and isolate the crux of the issue at hand, generalize it broadly, and then address the general problem. For example, a question may be about how to perform a zonal summary in QGIS (although not in so many words, because likely the asker doesn't even know what a zonal summary is). A reply that identifies the question as a request for a zonal summary, describes how this operation works, points out that an equivalent operation is available in almost any raster GIS, and then provides a QGIS code snippet would be a great, lasting contribution. In effect, the "hard" QGIS code also serves (by virtue of the accompanying explanation and analysis) as "executable pseudocode." You can have the best of both approaches.

A good example of this strategy--even though no code was involved--appeared recently at https://gis.stackexchange.com/a/27059, where a reply to an ArcGIS-specific question (about projections) was framed in a way that will be useful on all GIS platforms.

Despite the foregoing, it is apparent that many questions on our site are of the form "what line of code do I need to get service XXX to do YYY on platform ZZZ." There's not a whole lot more we can do to help than give that code.

Answer 2

I generally prefer something in between, both as an asker and answerer. Pointers, not a complete homework, to put it simply. As an asker that allows me to grow and as an answerer it saves me time. ;)

In many cases you don't have a choice though, since the question is too scarce with the details and background plus the fact that it's not easy to get dummy data.