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?

2 Answers 2


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.

  • I hadn't even considered the hard-coded answers 'going out of style' as languages/ implementations change when I posed the question, great point.
    – Roy
    Commented Jun 19, 2012 at 13:17
  • 2
    Considerations of passing out of style come naturally to those of us who have posted code in Avenue (through the early 2000's), Fortran (through the early 90's), AWK (ditto), MASM (through the late 80's), dBase (ditto), and many other languages that were once quite common! Anybody care for APL, Algol, or Snobol? :-)
    – whuber
    Commented Jun 19, 2012 at 15:03
  • 1
    +10. pros and cons of each, and how to do both at once. Commented Jun 20, 2012 at 20:08
  • 1
    +1 Maybe we could leverage Google's Endangered Languages Project to help preserve our heritage. Commented Jun 21, 2012 at 23:07

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.

  • My preference is for hard coded -- with comments. I'm not very likely to take the trouble to figure out how to convert pseudo code into real code before even getting to the point of exploring the actual question. The commentary is the pseudo code, that is, it should explain the purpose and general methodology of the hard code, and thereby allow porting to the language du jour. Commented Jun 20, 2012 at 20:03
  • In the asker bit I was talking about the kind of answer I would like to get — pointers, snippets, not everything on a plate. Commented Jun 20, 2012 at 20:49
  • oh, right, thanks for the clarification Commented Jun 20, 2012 at 21:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .