- There are lots of good styles and exposure to them all will help you develop your own.
Yes, but unless the different styles are being presented as examples of different styles, there is a danger of an infrequent monk adopting the style of the script he just happens to have read. I suggest an additional list item under the text boxes that links to a short and simple code formatting tutorial that covers only the basics, such as the few things that I've read Larry Wall considers important. I believe that such a tutorial and the various benefits of a tidy feature outweigh the bad points.
Some tips on making the current bulleted items under the text boxes more concise and readable--eliminate "Are you posting in the right place..." Just include helpful subtitles under the section names on the pages of the sections. Such a helpful subtitle ("This area is for discussion relating to this site. If you're looking to ask a question about a Perl problem you should go to the Seekers of Perl Wisdom page.") is already included on the Perl Monks Discussion page. Keep the "Perl Monks Approved HTML tags" item, but make it read:
Perl Monks Approved HTML tags (avoid pre): a, b, big, blockquote, br, center, code, dd, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, li, ol, p, pre, readmore, small, span, strike, strong, sub, sup, table, td, th, tr, tt, u, ul
Note the addition of "avoid pre" and "code." Make "avoid pre" into a link to Perl Monks Approved HTML tags
with details on why to avoid pre at the top of the page. The "Snippets of code" item should be eliminated.
I also recommend using title attributes containing brief descriptions for the upper right links to the sections. They are displayed when hovering over links, at least in IE.
- Reading poorly formatted code will help you improve your maintenance skills.
- A disconnect between the code they are helped with and their actual code will make it harder for them to implement suggested changes.
- If someone needs to improve their style, but they can hide that fact with the push of a button, they may never receive some much needed advice and direction.
Applies mostly if the code in one of the help sections, where the reader might be looking to improve it. Reading bad form is more likely to result in more bad form. As I said, the tidy feature could be limited to the snippets
- This would be a poor alternative to suggesting to someone that he download perltidy himself and learn to use it.
No argument there. I suggest noting the importance of learning to use PerlTidy rather than avoiding the feature.
- Just try getting all the editors to agree on one recommended style.
I wouldn't try it, but I'd like to read the debate.
- Formatting code fragments would often not give desirable results anyway.
If there is still a problem with a warning, then maybe offer the tidy feature in the Code section only, or sniff for a full script by checking for a "user/bin/perl line at the top.
- I don't see an easy way to integrate this into the existing interface. We can have multiple code sections, for instance. They can be inline if we want. Etc. How can you decide which to run through perltidy?
The last code section only. To tidy more than one code block, you would enter one, click tidy, enter another, click tidy, etc. Inline code wouldn't be tidied.
I don't think there are that many new entries in the Snippets
sections each day. You might get slowdown spikes when PerlTidy is run though. Don't know how well the Perl Monks servers could handle that.
Somewhere else in this thread you said, "Indentation isn't really standardized, but on a single message board (perlmonks.com), it should be." I disagree, but that's okay. You've expressed an opinion. Now, present an argument to support it.
I know that writing style is standardized in magazines. I'm not sure about coding style, though I'm sure it's standardized in books. There's not the same style in every book, but within a given book, the coding style would probably be consistent. Doing the same on PerlMonks would be in keeping with the standard for code conformity set by the non-electronic media. There isn't much of a standard on the web. I don't know of another message board with a significant number of full length scripts. But more important than that is setting a good example with the posted code.