15
\$\begingroup\$

I frequently read in chat users saying things about not being able to answer this question or that because they don't know the language used in the question.

Is this true? What knowledge level is required of a language before I should consider myself capable of answering it?

\$\endgroup\$
16
\$\begingroup\$

What knowledge level is required of a language before I should consider myself capable of answering it?

NONE!

You don't necessarily need to know a language at all in order to answer a question.

Consider this answer of mine. I don't know anything about PHP, and yet that's my highest upvoted answer.

There's also answers like this one. While I do know Swift quite well, I'm convinced anyone could have posted that answer. It only addresses white-space, and anyone who knows any C-based language could see how big of a mess the original code was in, purely in terms of white space.

I want to encourage everyone to look outside their comfort zone. And don't feel bad about getting "easy rep" on these answers.

First of all, looking at these questions and making these answers will increase your familiarity and comfort with that language--you're learning whether or not you realize it.

Second, try thinking of this as a sort of janitorial duty. To me, I think it's crucial that some of these easy & obvious problems are taken care of. They're usually simply habit things, and they're usually really easy to get right... you just have to be in the habit. So I'm always going to comment on these things, even if I'm considered a "domain expert" for that language. But that takes time away from me investigating other issues the question might have. If someone else has already taken care of answering with this easy clean-up, then a domain expert can invest more focus on other, more difficult issues.

Remember, on Code Review, any and all aspects of the code are up for review. And several things that people commonly get wrong are pretty easy to comment on even if you know nothing about the language.

\$\endgroup\$
  • 5
    \$\begingroup\$ Sorry to be a wet blanket, but that PHP question was bad/provocative to begin with, and therefore it's easy to heap criticism upon it. This is especially when you are (rightfully) targeting its malicious comments, rather than the code. Just saying... \$\endgroup\$ – h.j.k. Jul 23 '15 at 3:15
  • \$\begingroup\$ And? It's not the only question that anyone would be capable of answering without knowing anything about the language. As rolfl's answer is pointing out, all you need to write an effective answer is to know something more than what the asker knows, and that absolutely does not have to be language specific. You can comment on white-space. You can comment on comments. You can comment on algorithm. You can comment on naming. \$\endgroup\$ – nhgrif Jul 23 '15 at 11:58
  • \$\begingroup\$ Sorry if I've offended you, that's not my intention... Your answer is good, no doubt about it, just that I think there are better examples to show the exact point you mentioned: knowing something more than what the asker knows. :) \$\endgroup\$ – h.j.k. Jul 23 '15 at 14:23
  • \$\begingroup\$ You're welcome to add examples. \$\endgroup\$ – nhgrif Jul 23 '15 at 14:24
  • 2
    \$\begingroup\$ I've written reviews in languages I don't know by consulting the docs along the way. Great learning exercises. \$\endgroup\$ – RubberDuck Jul 24 '15 at 1:34
  • 2
    \$\begingroup\$ That's not exactly true that you don't know anything about PHP: you were at least able to make the difference between code and comments. \$\endgroup\$ – Morwenn Jul 25 '15 at 21:34
14
\$\begingroup\$

Like many natural languages, computer languages are often much easier to read than to write. This is true for me, so I assume it is true for everyone (correct me if I am wrong).

Speaking from the perspective of an "old man", I have been exposed to many, many languages, and have even maintained code written in many. I have had the "pleasure" of first-hand experience in some of the "foundational" languages, like C (on microcontrollers, mostly), and even assembler. I have database, and object oriented experience, etc.

That's all fine and well, but, can I review, say, ? Well, of course I can. I have never used it, but I can read the code, the logic is well structured, the language makes the concepts I am familiar with seem "shallow", there's no need to dig too deep to understand the code. This is a compliment to the Ruby language, and, guess what, I don't need the landmarks of the language to see the landmarks of the code, and I can review the code, and even write it to prove the suggestions I make work. I have done that sort of thing a few times, in c#, Javascript, LOLCODE, C++, and more.

Notice, though, that in each case I am mostly reviewing the algorithm, and assumptions that are being made, and not the style, or other aspects I am not familiar with. Review what you know, not what you don't know. If you can spot an algorithm that is inefficient, it does not matter what language it is in. If you can spot an edge-case that should be considered, it does not matter about the language.

The language is only a part of the question to be reviewed, and, on Code Review, you can review any, and all aspects of the code, so you can review what the code does, how the functionality is implemented logically, as well as how that logic is implemented in the language of choice.

Just so long as you can spot the logic, and determine how that logic solves the problem, you're fine.

Leave the language-specific parts for people more versed in the language.

\$\endgroup\$
  • 1
    \$\begingroup\$ "Review what you know, not what you don't know.", excellent! Spot on. \$\endgroup\$ – Simon Forsberg Jul 23 '15 at 12:26
8
\$\begingroup\$

Feel free to review any language, but carefully

There are aspects that you can review in a language even if you don't know it at all, for example:

  • Poor choice of algorithm (too complicated or inefficient)
  • Logical errors
  • Missing test cases, missing corner cases
  • Lack of input validation
  • Certain formatting issues
    • Not enough / too many empty lines
    • Excessively long lines (> 200 characters)
    • ...
  • Certain naming issues
    • Excessively long, outright weird or nonsensical names
    • Inconsistent naming style, mix of conflicting conventions
    • ...
  • ...

There are aspects that you can review in a language if you know it a little bit, or if you know a similar language very well, for example:

  • Lack of decomposition to smaller functions
  • Arrow-shaped code
  • Duplicated code blocks
  • Duplicated literals
  • Violation of standard coding style
  • Lack of documentation
  • ...

That's really a lot of things, just off the top of my head.

Tread very carefully

If you don't know a language very well, it might have surprising rules or conventions that might never cross your mind. See below some example bad suggestions.

enter image description here

Example 1: Given this code:

 for (var i = 0; i < players.length; i++) {
    var player = players[i];
    // ...
 }

To programmers coming from Java, C#, or similar, it may seem logical to suggest: if you don't need the index variable i, change the counting loop to a for-each loop, for example for (var player in players) { ... }

=> Incorrect: arrays are very different animals in these languages; the suggestion breaks the code

Example 2: given this code:

 var i;
 for (i = 0; i < players.length; i++) { ... }
 for (i = 0; i < scores.length; i++) { ... }

To programmers coming from one of the many block-scoped languages, it may seem logical to suggest: declare variables in the smallest possible scope, so move the var i into the loop initializer statements

=> Incorrect: JavaScript doesn't use block scope; the suggestion breaks the code

Example 3: given this code:

if (pipe(in))
    goto error_in;
if (pipe(out))
    goto error_out;
...

To programmers with little exposure to lie Leuven system programming in C, it may seem logical to suggest: goto is evil, period (a.k.a prepare for velociraptor attacks)

=> Incorrect: it's not so simple. goto has acceptable uses in system programming, for example in the Linux kernel.


I could go on an on. Be careful what you recommend. If you butt your nose in a language you're not so familiar with, then you'd better be sure your recommendations are solid. Definitely check the docs first before posting non-sense. Feel free to ping users in the 2nd monitor chat room to double check.

\$\endgroup\$
  • 3
    \$\begingroup\$ I think I'd still recommend braces on that goto example though. ;) \$\endgroup\$ – nhgrif Jul 24 '15 at 11:55
  • \$\begingroup\$ Nice job finding and using part of the linux kernel source as an example. \$\endgroup\$ – SirPython Jul 26 '15 at 18:41
5
\$\begingroup\$

Short answer: No.

Long answer: While it's true that all aspects of the code are up for review, not understanding the language in question tend to give rise to short, brief answers which may not be very effective. Sure, it'll be good if we can marginally prop up our site's answer rate/ratio with short, still-on-topic answers, but in the long run we should still expect longer and more insightful ones to give the OP a bigger bang for the buck.

This is slightly related to this old Jon Skeet's blog post about programming "in" a language and programming "into" a language:

There is a happy medium to be achieved, clearly. You certainly shouldn’t restrict your thinking to techniques which are entirely idiomatic, but if you find yourself wanting to code in a radically different style to that encouraged by the language, consider changing language if possible!

If I were attacking the same problem in C# 1 and C# 3, I could easily end up with radically different solutions. Some data extraction using LINQ in a fairly functional way in C# 3 would probably be better solved in C# 1 by losing some of the functional goodness than by trying to back-port LINQ and then use it without the benefit of lambda expressions or even anonymous methods.

Fact that there are two sides to a coin aside (read more on the post itself), what's important to highlight from the blog post is that good, effective answers should try as much to take advantage of a language's (latest) features, rather than sticking to what is taught under "theoretical computer science" in schools ahem we know from theory/another language.

In a more practical example, a non-Java person may comment how a Java question's implementation doesn't seem quite right without touching the actual code per-se, but if the question is not about , I'll simply suggest using a LinkedList.

Therefore, we don't have to necessarily speak the language, but it'll be a whole lot helpful for the OP if we do.

\$\endgroup\$
  • \$\begingroup\$ rate/ratio is unintended, BTW. \$\endgroup\$ – h.j.k. Jul 23 '15 at 3:32
1
\$\begingroup\$

I know I am one of the people you are referring to who have said things such as "I can't review that as I don't know the language", but I think you have misunderstood me. I did not mean that no one should ever write a review for a question in a language that they do not know. What I did mean was that I did not feel confident enough in my ability to write a sufficiently high quality answer in that language. I do not know why others have said similar things, but I suspect their reasons might have been the same.

If you feel confident enough - go for it!

There is a clear distinction between what posts are on topic and what posts are good. You regularly say that a close vote is not a super downvote. That is true and applies to this question as well. An answer written by someone who does not know the language might or might not be as good as an answer written by someone who does, but that is up to the voters to decide. We should not enforce redundant rules.

A rule against writing reviews in a language the reviewer does not fully understand would even be detrimental as it is fully possible to write a good answer without knowing the language as has been demonstrated in other answers to this post.

\$\endgroup\$

You must log in to answer this question.

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