Beefy Boxes and Bandwidth Generously Provided by pair Networks BBQ
Syntactic Confectionery Delight
 
PerlMonks  

Re: Re: Tidy feature to implement recommended code style

by Wassercrats
on Nov 23, 2003 at 11:01 UTC ( #309257=note: print w/ replies, xml ) Need Help??


in reply to Re: Tidy feature to implement recommended code style
in thread Tidy feature to implement recommended code style

  • 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 and code sections.
  • 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.
  • Server load.
I don't think there are that many new entries in the Snippets and Code 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.


Comment on Re: Re: Tidy feature to implement recommended code style
Re: Re: Re: Tidy feature to implement recommended code style
by Anonymous Monk on Nov 23, 2003 at 12:22 UTC
    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.

    There are a lot of people on this site contributing a lot of content for a lot of different reasons. Some of the code in the snippets and code sections may be there for pedagogical purposes, but most is probably posted with only the intent of sharing the code. Trying to enforce a particular style on those sections would be like trying to enforce a coding style on CPAN submissions. Shall we also set up a GrammarTidy for non-code content?

      I guess I should have emphasized that tidying would be an option, not a rule.
        I guess I should have emphasized that tidying would be an option, not a rule.

        I guess I have wonder what your whole point about a "standardized" style was then? If it is optional, then there is no site standardization, so that argument is null. If what you want is to be able have perlmonks tidy up your code for you, then I'd have to say that that is your responsibility, not perlmonks.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://309257]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2014-04-20 02:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls