Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
20  
Do not sweat it; there is no such thing as good Perl style. –  Job Oct 3 '11 at 20:35
    
@Job I want to thank you from the bottom of my heart for that anecdote. –  Yam Marcovic Oct 4 '11 at 15:11
1  
@Job. But there is definitely bad(er) Perl. –  Loki Astari Oct 4 '11 at 20:51
add comment

5 Answers

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.

share|improve this answer
    
I think in-person, I didn't react unfavorably (though I've got a lot of other, "Gee, I'm bad at interviews" moments -- never had to do the tradition resume / interview thing until now and that's a steep learning curve). The 1st reply from @ikegami makes me want to reach out and smack him a little. ("Hint: use subs"; "You just didn't figure out how to do it cleanly")... and I decided that was worth communicating to him just now. –  Jeff Ferland Oct 3 '11 at 18:46
add comment

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.
share|improve this answer
2  
s/defiantly/definitely/ ? –  Péter Török Oct 3 '11 at 18:42
    
@Péter Török: Done. Thanks :-) –  Loki Astari Oct 3 '11 at 20:25
1  
+1 Learning the philosophy behind the language not only makes you a better programmer with respect to the language but a better programmer overall. –  Oliver Weiler Oct 4 '11 at 14:28
add comment

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.

share|improve this answer
    
I already expect to adapt to the standard of the team as each team is likely require adapting to -- I question about how I'm judged before I'm part of a team where there are invariably differences. –  Jeff Ferland Oct 3 '11 at 22:11
4  
@Jeff: Here's my view from the other side of the table: If you claim to know Perl (or Ruby, or Python, ...) , but are translating from C (or Java) token by token, I can only conclude that your knowledge is superficial, and you will not be as effective as my teammates with deeper knowledge. You will be slower to produce working code, because you are writing more code. It will probably perform badly, because you are hand-rolling library functions like map . Finally, the rest of the team will not want to maintain your code. It's not a good fit. –  kevin cline Oct 3 '11 at 22:55
2  
While I agree with the overall idea of this answer, it also reminds me why Perl is kind of a dying language. Perl isn't taught formally anywhere these days; expecting new programmers to instantly conform to an obscure language doesn't help create a healthy community. –  joshin4colours Oct 4 '11 at 16:27
1  
@joshin4colours: I understood that the OP presented himself as an experienced Perl programmer. Anyway, it doesn't matter if the language is Perl or C++ or Python or Ruby. A good programmer will learn the features of the language and embrace them. A C++ programmer should use the STL when appropriate. A Python programmer should use list comprehensions and generators. A Ruby programmer should use collection methods and closures. –  kevin cline Oct 4 '11 at 19:01
2  
@joshin4colours: On your first reply, the Perl community has no such expectation; it's widely accepted as OK to write "Baby Perl" if you're new to the language, not primarily a programmer, etc. But experienced developers are expected to know the norms and best practices for the language regardless of which language it is. On the second, I agree that "cramming everything into as few lines as possible" isn't a compelling feature, but, then, it's also something generally discouraged in the Perl community these days unless you're participating in a round of golfing. –  Dave Sherohman Oct 5 '11 at 10:09
show 2 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.