How much does/should your style imply about your skill in a language? [closed]

Question

Two things I've noticed in the past week that make me wonder:

• An interview where my Perl skills were reviewed. I always use C-style for loops and use map about once in every 10,000 lines of code, so I almost always have to reference it before using it. While I can interpret others code using that, it's not my style and that is for reasons involving readability and ease of changing between languages. I at least perceived that I was dinged for that.
• This answer to my question in which the answerer proceeded to refactor and bullet-proof my tiny script. I admit I was a little bit offended and kind of annoyed at that, though I can understand how that as a habit may be helpful.

I understand that in a team, my style will need to adapt what the team has decided is correct -- this is necessary in every project and everybody has their own ideas. Yet I feel like I'm judged for what is syntactically fine and readable code.

How much does the style of your smaller snippet code weigh in? Does code like that imply to others that I don't have control of the language because I didn't use all the features? Does my code imply that I'm not familiar with unit testing and proper testing because I didn't fully error-protect a tiny script?

Answer 1

Most popular modern languages have a similar syntax (with small tweaks here and there). But each language has its own very unique style of being used. This style has usually developed over many years and is result of how the language works underneath combined with the experience of users to avoid nasty problems in the language.

When most developers migrate from one language to another they take the style of their favorite language with them and try and apply it to the new language. Now this is fine while you are learning (as you have no other reference to go by). I am not good at perl so I write perl like C++ (with a few tweaks (but I recognize my perl is not good)). I see Java developers try and use C++ like Java and it makes a complete mess of the code (because it does not fit well).

But in the long term this is a bad approach. The language has a particular style for a reason and it is best to try and understand this and learn the style for that language. It makes the learning curve steeper (and you may fall back to your old style now and then to get things done) but in the long term it will definitely be advantageous to learn the correct style for the language.

Reason to learn the correct language style:

• Integrate with existing code better
• Avoid pitfalls of the language that are not obvious
• Allow other users to easily understand your code
  • You can always work it out but reading code that is styled differently to what you expect is a lot harder work than reading it the style you expect.

Answer 2

Does code like that imply to others that I don't have control of the language because I didn't use all the features?

Yes, it does. Good Perl programmers know Perl well, and use it effectively.

If you are writing five lines of Perl where one would do very nicely, do not expect a warm welcome from a team of Perl programmers. Teams choose Perl and similar languages to get more done with less code. It's not just a question of style, it's a matter of time and money. It takes a lot longer to read and understand:

my @selectedThings
for (my $i = 0; $i <= $#things; ++$i) {
  my $t = $thing[$i]
  if ($t ... ) {
    @selectedThings.push $t
  }
}

than:

my @selectedThings = @things.grep { ... }

The grep call is clear to a Perl programmer. The multi-line equivalent could say anything, and could easily contain a bug.

There is a huge difference in the cost to develop and maintain a 25,000 line application than a 5,000 line application, even if they do exactly the same thing.

I always use C-style for loops and use map about once in every 10,000 lines of code, so I almost always have to reference it before using it.

This is a form of what Larry Wall called "false laziness". Each time you could use map, but instead write longer but more familiar code, you save a few seconds one time. But taking a few minutes to really learn map would save you hundreds of lines of code and many hours in the future.

While I can interpret others code using that, it's not my style and that is for reasons involving readability and ease of changing between languages.

This attitude does not work well in a team. The team knows Perl, and does not have time to wade through extra code because it's not your style.

Answer 3

1) Like ikegami, I spend a fair bit of time on SO answering Perl questions and one of my common pieces of advice is "don't use C-style for loops in Perl; use the list iterating version instead because it's harder to mess it up". If you write for my $i (1 .. 10), there's no way you're going to get the boundary conditions wrong, plus it's quicker to write and requires less thought than the C-style equivalent. If I were an interviewer and saw you write for (my $i = 1; $i <= 10; $i++) instead, I would question how well you know Perl and whether you were writing Perl directly or if you were thinking in C, then translating it to Perl.

If I saw you write for (my $i = 1; $i <= 10; $i++) { $data = $some_array[$i];... } instead of for my $data (@some_array) { ... }, on the other hand, then I would conclude that you clearly don't know Perl very well and the interview would be pretty well over in my mind, assuming it was for an experienced Perl position. (Unless $i was going to be used for something else beyond just sequentially indexing into @some_array, but even then I'd favor for (..) over for (;;).)

Style does matter, especially with a language that's as TIMTOWTDI as Perl. There are many ways to do it, but not all are equally good (for any given value of "good", which does vary from situation to situation). Using all the language features isn't necessary for good style, but using the right ones when they're appropriate will get you pretty far in that direction.

2) Regarding the linked answer, your code there looks fine to me overall. The main thing I question is the & prefix on your final function call. You don't need it (unless you're writing Perl 4, in which case you have far bigger problems!) and it's generally discouraged these days because it has side-effects which aren't immediately obvious. Definite bonus points for using strict, three-arg open, lexical filehandles, and CPAN modules, though.

On the larger point of your second question, I frequently rewrite people's code to clean it up and show (at least some elements of; I try to match it to their apparent skill level) how I would do it. It's not meant as a slight on the original author; it's an attempt to help and to educate beyond the immediate question at hand. It's usually pretty fun, too. But, perhaps most importantly, the simple fact of the matter is that Perl has an image problem. There are a lot of people out there (*cough*Job*cough*) who think that "there is no such thing as good Perl style" and I feel that it's important to disprove that belief by showing off well-written, maintainable Perl code when the opportunity presents itself.

Answer 4

I don't think the particular style matters in an interview code question, but it is good to see that you have one and are aware of why you do things the way you do it.

Based on your question, it sounds like you may not have reacted favorably to the criticism. You say you realize your style will need to adapt, but you may not have given that impression. Do you think you were defensive? That can be interpreted as unwilling to change.

Answer 5

While I can interpret others code using that, it's not my style and that is for reasons involving readability and ease of changing between languages.

This seems odd to me. I find it much more difficult to switch between two similar languages than to switch between two that are very different. When two languages have a lot in common, there's a tendency to fit them both into a common mental model and you end up having to constantly remind yourself about all the differences.

I'm sure that anyone who uses both C and C++ has at some point let some C++ slip into their C code or forgotten to take advantage of useful language features in C++. You never have that problem when you switch between, say, C++ and Scheme, because the two languages aren't remotely alike.