Is it really necessary to explain trivial answers? [closed]

Question

OP: How do I rewrite x = a + 1 + b - 1?

Me: x = a + b.

Community: hey, you didn't explain how you did that! Take 5 downvotes!

Me: x = a + b -- oh, so... you know... here I... emm... blablabla... removed + 1 - 1... because it was + 1 and then - 1... you know... you I just removed it, so... ok?

Community: wow, it's much better! It was totally impossible to understand until you added these two sentences to your insanely complex 4 chars edit. Thank you! Take 2 upvotes back.

This is pretty much what I do experience on this site for last year. I don't actually know how at all I still find a will to post any answers here with such things. If it was a way to send a private message to OP I would just send him reviewed code without letting it be attacked by such insane community attitude.

Answer 1

Your example of x = a + 1 + b - 1 is a bit disingenuous. As on the main site, we should be discussing real code rather than hypothetical examples.

I see from your history that this is not your first complaint. The community consensus is that code-only answers are not acceptable. Several of your past answers have been forcibly deleted:

• Alternately taking elements from an array
  Code dump with one line:

  Another "little of code" approach:

  def alternate_take a, b
    raise ArgumentError, "Unequal length" if a.length != b.length
    pool = a.zip b
    pool.each_slice(2){ |x, | x.rotate! }
    pool.map &:last
  end
  

• Print multiplication tables
  Code dump with no explanation at all:

  def print_multiplication_table max
    pad = (max * max).to_s.size + 2
    (1..max).map do |i|
      (1..max).map{ |j| i*j }
    end.each do |row|
      puts ["%%%ss" % pad] * max * "" % row
    end
  end
  

• Brainfuck Printer Generator
  Mild derivative of another answer without explaining why it's better. This one even prompted a comment from the original poster asking why you thought the solution was clearer than the original code.

  I'll edit the @Flambino 's answer:

  def brainturing_printer_generator(text)
    [0, *text.chars.map(&:ord)].each_cons(2).map do |previous, current|
      delta = current - previous
      (delta < 0 ? "-" : "+") * delta.abs + ".\n"
    end.join
  end
  

  And show the approach without ? "+" : "-":

  SAMPLE = "-" * 255 + "+" * 255
  
  def brainturing_printer_generator(text)
    [0, *text.chars.map(&:ord)].each_cons(2).map do |previous, current|
      delta = current - previous
      SAMPLE[Range.new(*[255, 255 + delta].sort, true)] + ".\n"
    end.join
  end
  

Simply put, you have a history of posting answers that aren't code reviews.

---

That said, you do have a point that in some circumstances, "Behold!" is all the explanation that is needed. I call this the "Oh, duh!" test, and it's very difficult standard to meet. Basically, for a code-only answer to stand, it has to be obviously the "right" solution, such that once you've seen it, you could not possibly consider doing it any other way.

So far, I have only been aware of two examples of answers that qualify:

• Infinite list of strings containing 'a'
  Flagged as "Not an answer", and I declined to delete.

  Another way to do it:

  aStar = iterate ('a':) ""
  

• Check if a string has 20 numbers in a row in it

  This answer contained an alternate solution that made no reference to the original code, but I felt that none was needed. (There were some complaints that it was not a valid answer by our rules, so I edited it for good measure.)

  var twentyDigits = /\d{20}/;
  if (twentyDigits.test(myString)){
    console.log("My string has 20 running numbers");
  }
  

  This is using a regular expression to look for 20 digit characters (\d) in a row.

  You can shorten this further as just:

  if (/\d{20}/.test(myString)) console.log("Yup. 20");
  

I don't believe that your solutions, such as this most recent one, meet the "oh, duh!" test.

Answer 2

Stack Overflow is about solving a problem. A question, an answer. "Try this {code dump}" are somewhat frequent and often acceptable SO answers, especially when trivial.

Code Review is about reviewing OP's code. It's not quite Q&A, so it's not quite "a question, an answer". "Try this {code dump}" are somewhat frequent, but never quite acceptable CR answers, even when trivial (excluding the odd "oh, duh!" answers).

This is pretty much what I do experience on this site for last year.

The message this community is trying to get across, is that code dumps are not reviews; code dumps are not the kind of answers we value and want on this site.

A quick browse through these search results should help clarify the kind of answers we do value and do want to see on Code Review: Answers created after 2014-01-01, sorted by vote (filters out older answers from before the site's scope and policies were carefully fine-tuned).

The takeaway is that we're looking for answers that provide insightful observations about the OP's code. Many excellent CR answers don't even include a code block!

If you're answering CR posts in "SO mode", you're doing it wrong.

Answer 3

I don't think that there's anything wrong with code-only answers when the point you want to make is straightforward and the code is short.

But it's also clearly the case that the community here doesn't like code-only answers, and so my advice to you is to roll with it and not fight it. There's nearly always something you can say about the reason why your suggested code is an improvement, or you could describe the language feature or API that you are using, and link to the documentation.

For example, here's a very short answer of mine that (so far) has received only upvotes:

The documentation for itertools.accumulate notes that you can pass min as the second argument to get a running minimum. So the maximum profit can be computed like this:

profit = max(p - m for p, m in zip(prices, accumulate(prices, min)))

I feel that the one-liner passes 200_success's "Behold!" test and could stand on its own, but adding an explanation satisfies the community's requirements and might do some good.

Answer 4

As luck would have it, an interesting example of a answer with minimal explanation has just been posted.

Comparing 2 ints without using comparative operators

I was looking for questions that might be asked in a technical interview and I found this one:

Write a function that determines if two integers are equal without using any comparative operators.

public static boolean equal(int a, int b){
    Integer first = a;
    Integer sec = b;

    return (first.toString()).equals(sec.toString());
}

Observation: this isn't such a good question for Code Review, since the artificial restriction makes it more of a Programming Puzzle. One could argue that it violates the "Do you want this to be good code?" rule, and may therefore be off-topic. But that would be a separate Meta question.

Answer:

This function doesn't use any of comparative operators:

public static boolean equal(int x, int y) {
  try {
      int r = 1/(x - y);
  } catch (RuntimeException e) {
      return true;
  }

  return false;

}

---

The current score is +1/-4, and an "insufficient justification" moderator notice has been attached to it.

If we go strictly by the rules, this solution would need to be accompanied by an explanation such as:

As others have said, your solution uses String.equals(), which arguably is a comparison operator (or uses one behind the scenes). Here is a function that doesn't use any comparison operators. Instead of testing x == y, we can detect whether x - y == 0 by seeing whether it triggers a division by zero error.

Would that explanation add any value? I think that "Behold!" would work just as well. Therefore, I think that in this case, the downvotes and the moderator notice are unjustified.