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?
What knowledge level is required of a language before I should consider myself capable of answering it?
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.
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, ruby? 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.
There are aspects that you can review in a language even if you don't know it at all, for example:
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:
That's really a lot of things, just off the top of my head.
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.
Example 1: Given this javascript 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 javascript 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 c 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.
goto example though. ;)
\$\endgroup\$
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 linked-list implementation doesn't seem quite right without touching the actual code per-se, but if the question is not about reinventing-the-wheel, 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.
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.
