Your example looks quite badly indented, actually. And I find the colors (insert fancy word for "ugly" here). The contrasting rendering of the letters is distracting and makes the code harder to follow. The extra dark letters have strokes that bleed together, making them harder to read, the "m" looking mostly like a rectangular smudge, the "y" like some sloppy triangle, the square brackets looking at first like vertical bars. The light blue and green are indistinguishable (it wasn't until the fourth viewing that I even noticed that there was more than one cool pastel text color) and look rather washed out against the tinted background.

And that didn't even include any misapplications of "syntax highlighting" (at least that I noticed).

I'd be quite shocked if stackoverflow is automatically re-indenting code posted there (as you seemed to claim in your root node). I certainly don't want the code I post here re-indented and I certainly don't want to see some indenting other than that done by the author unless I am able to toggle such drastic rewriting (with the default being that such rewriting is not done).

I wouldn't be surprised if stackoverflow was using some low-impact, language-agnostic, common-keyword-recognizing, common-quoting-scheme-recognizing, "syntax highlighting". In fact, visiting stackoverflow (and taking quite a while to remember how to log in there) I find no evidence of it re-indenting my unindented code. And I find evidence of it using pretty much what I said in the first sentence of this paragraph. It was quite easy to come up with common Perl constructs that it highlighted incorrectly (// is assumed to start an end-of-line comment, for example). Most Perlish quoting is not properly handled.

At least the coloring at stackoverflow is so very subtle as to not be very distracting (and no use of bolding), but that is only appropriate as the very generic nature of the highlighting means that it can easily be wrong (depending on what language or non-language the blocked text actually contains -- certainly often wrong in the case of Perl code).

So I think you are quite mistaken in your original impression that many sites automatically re-indent code. My experience is that such an activity can so easily go astray that it wouldn't be long before such a feature were abanodoned (seriously changing the apparent meaning of code need only happen a very few times before such drastic attempts at enforced aesthetics lose favor, surely). I expect most who thoroughly consider the idea would at least be conerned about potential problems with it, especially for Perl code.

As for just adding some color to the contents of <code> tags at PerlMonks, I have plenty of experience with code being strangely (or "badly", depending on how charitable I want to be) written because writing the code more sanely illustrates a bug in some syntax highlighter. And I almost never use syntax highligting myself but I've still run into many such cases (and I never use it for Perl code and most of the bad examples are for Perl code).

There actually have been very rare times when I've found syntax highlighting helpful. They were always when I missed something small but drastic like an unclosed quotation or an unclosed comment (in SQL, FYI -- and SQL usually has really sucky error messages so the extra help is more appreciated there). But I find incorrectly highlighted code to be a much more serious problem than I find correctly color-coded code to be a help, especially for the high-impact things like the highlighter thinking way too much is quoted.

And I find giving vague color hints that are sometimes going to be incorrect hints to newbie Perl coders on a site like PerlMonks to be a pretty bad idea as well.

And I have yet to notice stackoverflow offering users a choice of color schemes and having quite a few users who have customized their own color scheme still further. So I doubt anybody could produce a code colorizer for PerlMonks that didn't produce ugly even unreadable results for quite a few members.

So any syntax highlighter one picks is going to get some things wrong for Perl code (which isn't the only thing put into CODE tags here, of course). So it should be up to the person who is choosing to use a syntax highlighter to pick one whose quirks don't outweigh its benefits to them. For me, my choice is "none". But many make other choices. If there is a syntax highlighter that you like, then arrange to use it in your client. We even supply tools to assist in such client customization. Running into bugs and quirks in a syntax highlighter that was forced upon you by some site admin surely quickly becomes very frustrating. Let's not go there.

In addition to what jettero said this reminds me of why PHP has the big web share now. Many important Perl hackers resisted or even ridiculed the possibility of building code and sites in dressed-up, simpler on the end-dev ways. The web being what it is, mostly vapid and ephemeral, went there.

Tangent: Last night I was playing with Perl6 and thinking, "Wow, this is really neat. I'd love to hack on this a lot." In the light of what I just said about PHP I can't help but wonder if Perl6 is actually a box of coffin nails in disguise. :(

I personally like the style/interface of the PerlMonks site though and agree with most of your points. (I don't really care for the perldoc.perl.org redesign for example. It was easier to read before even if not as visually appealing.) PPI does a very good job now and could be used for a solid highlighter which, as most of us have said in the past, should be opt in for the reader if we ever have one, not the writer.

This attitude is probably part of the reason perlmonks looks so dated where other sites do not. You have a lot of influence here.

-Paul

"Dated"? And the problem with that is...? Are UNIX command line utilities "dated"? (They are even older than PM.)

Having to put in explicit html tags for paragraph breaks and (un)ordered lists is admittedly a "dated", antiquated, tedious process (and tables? jeez!), but I put up with it here because in the long run, it's less work to exert that sort of explicit control than to cope with the vagaries and quirks of "smart markup".

As for making the code snippets more "appealing", this bit from the OP points to an issue that is, I think, essentially unavoidable:

...I had to copy&paste it in my editor and indent it there and benefit from the syntax highlighting.

Yeah, I do that a lot around here too (I'm so grateful to have emacs' "perl-mode" and "perl-indent-exp"). But guess what: if the page layout were trying (and occasionally failing) to apply some sort of "normalized" indentation and syntax highlighting, I'd still have to do that -- but now I'd be doing it on code posted by people who aren't novices at writing perl, but are only novices at controlling the "automatic" formatting.

(Either that, or the experienced posters would be wasting time trying to circumvent the "normalization", or simply turning it off.)

And would the imposition of indenting and highlighting really help the newbie posters who seem to need it most? Or would it simply be another source of frustration and confusion? ("My code isn't showing up the way I expect it to! What's wrong with this web site?" Try explaining to such people that the web site is now also trying to function as "smart editor", pointing out the syntax errors in their code... before other monks even have a chance to respond to their posts!)

I'm with GrandFather: it's more effective for all concerned when posted code is presented "as-is" and unadorned from the poster's own source. On a cost/benefit basis, I think the proposal to add automatic formatting of code will fall be the wayside.

What kind of information are you referring to ?

As people develop their programming style they also tend to develop a preferred style of code layout. Often the layout of the code can convey something of the author's level of expertise and experience. Reformatting tools strip that information out, but at least if the author does the reformatting it shows a higher degree of interest in obtaining a good answer.

Now, sometimes distraction is good. For instance, if you want to display an example, and you want to attract the attention to a specific construct in the middle of line 3. Then it's ok to colour this in a different way - it'll distract from the context, and focusses on the important part.

But code in red, green, purple and six shades of yellow? Horrible.