Downvoting trivial answers

Question

I think the most important question when reading an answer is: Will this answer make the code better? If the answer is yes!, that merits an upvote. But if the answer is meh??, I think the answer needs to be reconsidered.

Oftentimes, with questions that do have serious issues worth mentioning, answers get posted that are trivial. By trivial, what I mean is that an answer mentions an issue that is accurate (e.g. "your variable s should be named size", or "your 15 line C++ program shouldn't use using namespace std;") but extremely minor compared to other potential issues (e.g. having a really bad algorithm, repeating code unnecessarily, poor code structure, failure to encapsulate data, undefined behavior, not realizing the standard library has a function doing what they want to do, etc).

I'm not going to link any here, but I see a several such such trivial-only answers every day. I think we as a community should actively discourage such answers, by downvoting them. Because, ultimately, the point of Code Review is to make code better - and if you're not making the code better, if you're not addressing the actual problems in the code by just grabbing the low-hanging free-rep fruit, then you're really not helping anybody.

Thoughts?

Answer 1

I agree that insightful reviews deserve more points than answers that are merely linting. However, I believe that no answer should be downvoted unless it contains advice that is actually harmful.

Code Review's policy is to allow critique on any and all aspects of the code. As per in Let's work together to offer ultimately better content, faster and Short answers, we don't require any single answer to be a comprehensive review, or even an attempt to be comprehensive.

I'd much rather enforce a policy that all critiques be given as answers, so that they can be voted and commented on. Discouraging trivial answers would merely encourage people to post those remarks as comments, which would make a mess.

Instead of downvoting trivial answers, let's focus on upvoting insightful reviews. If you think that an answer is merely "meh", then I suggest that you not vote on it at all.

Answer 2

You are conflating trivial with bad. In the specific case you complained about, I agree that it's useless. The original proposal of template aliases was not to introduce a redundant feature for typedef.

In general however, the other stuff you mentioned isn't useless. People make the same mistakes over and over or ignore advice, thinking it's unimportant. Downvoting answers which offer this advice is nothing but harmful. The fact that answerers have to constantly provide this advice (some question askers ignore previous advice and post questions with the same mistakes constantly) is not the fault of the answerers.

using namespace std; is not a big deal in trivial code. It is a big deal when they start to create multi-file programs, use third party libraries, or anything remotely non-trivial.

Readability and formatting is easy to comment on. That doesn't make it less important. A lot of time could be saved if people would just plop their code into an IDE, and press CTRL+ALT+F, or an online beautifier. But it's a fact of life that people don't. The laziness extends to other aspects of code: poor choice of variable names, horrible program structure, not using tools (i.e, the standard library) effectively, and so on. Since these things aren't taught in schools, it's not a surprise that it's a skill that's highly valued on this site.

Also, you can't expect everybody to be at the same level of skill you are. If commenting on "minor" things was disallowed, it would be impossible for lower rep users to gain rep at all.

Finally, and least important, this is from the help center:

Use your downvotes whenever you encounter an egregiously sloppy, no-effort-expended post, or an answer that is clearly and perhaps dangerously incorrect.

The only point I can kind of see applying here is "no-effort-expended post", but as experienced programmers know, repeating general advice which falls on deaf ears is not low-effort, it's actually quite exasperating.

Answer 3

Everyone is free to vote as they see fit. Even if we would encourage people to down-vote "too trivial" answers, there will be a discussion about "what is too trivial?" - which is a highly primarily opinion-based discussion that I'm not interested in engaging in.

Personally, I have down-voted answers that I consider "too trivial" or "not really important in this case" and I plan on continuing to do so. In my opinion, answers shouldn't be posted just for the sake of answering a question ("killing a zombie") or for the sake of getting more or less easy reputation.

Answer 4

Because, ultimately, the point of Code Review is to make code better - and if you're not making the code better, if you're not addressing the actual problems in the code by just grabbing the low-hanging free-rep fruit, then you're really not helping anybody.

The points you mentioned, while they are easy suggestions, they do make the code better. size instead of s is clearly better, and not using namespace std is clearly better.

I'm not a fan of nitpicky answers either. I typically "punish" them by not upvoting. If you think they are not useful, you're free to downvote them. That's consistent with the suggestion of the tooltip too: "This answer is not useful". But encouraging to systemically downvote these is not right, because, despite being low-hanging fruits, they still make the code a little bit better.

There are some relatively rare cases of really nice code of a clearly skillful programmer, and nitpicky answers with a superior tone. Those I downvote.

Answer 5

I both agree and disagree with this. I agree partially because many of my answers feel so inadequate compared to many other answers around here. I disagree because telling someone to use size instead of s usually applies to to many other variables in the program, and the hardest code to read is the code that uses 1-letter variable names, poor indentation, etc. Overall, I think these answers are reasonably good, but try to cover several of these minor points, or have them as additional information alongside one or more major points.