I have worked in at least 7+ different companies, both large and small. I have had enforceable code reviews of my code in, count them, exactly 1(!) job. I have attempted to institute them in two others, with varying degrees of success. At my current position, what I have been doing is exactly what kvale suggests - I ask my peers to review my code. That serves several purposes:
  1. I get to verify that my code is good.
  2. As I'm the strongest Perl developer, they get to see what I consider to be best practices.
  3. It starts them thinking that code reviews might be ok.

Now, part of the problem I have had in most places is that management has never felt code reviews to be worthwhile. Say all you want about grassroots efforts, and a lot of it is relevant. But, unless some manager (the higher, the better) indicates that code quality is a priority, then code reviews (and testing, for that matter) will never achieve the level of importance that they deserve.

Now, one thing you can use in an academic setting to help prod your peers into code reviews is the threat that bugs will taint their papers. An academic's reputation is only as good as the last paper published. If that paper is disproven because of a coding error ... ouch! Kinda like you don't want to be the guy that drew the design backwards or confused metric with english measurement.

So, once you get them worried about their code quality, you pull out McConnell's books and show them the single best defense against bugs in new code - code reviews. And then you demonstrate how code reviews leads to the single best defense against bugs overall - code reuse, which also helps reduce the time taken writing the new programs. (This last point is especially important for academics because coding is generally the last thing they want to be doing.)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

In reply to Re: Advocacy of code reviews: how the heck do you do it? by dragonchild
in thread Advocacy of code reviews: how the heck do you do it? by FoxtrotUniform

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.