Re: Commonly accepted style guide?

If I see someone criticizing style in response to a question about the content of the code, I usually assume the respondent is an ass. For whatever reason, that person is making someone jump through hoops to be helped or thinks style is just as important as functionality. Even worse, the respondent has forgotten that TMTOWTDI.

I think contributing here at perlmonks or other forums is like being a teacher: we're trying to promote learning. The best way to get someone to learn is to engage them in the subject matter. The best way to turn a student off and completely disengage their minds is to give them a lot of facts and rules for rote memorization.

Answering questions is also like being a maintenance programer. Our job is to adapt and work within an established framework, not rewrite as we see fit.

Promote readability and understanding of the language. Solve problems with content of a newbie's code, not the style. Once the newbie becomes a hacker, they'll develop the desire to write using clean style on their own.

--
jpg

Comment on Re: Commonly accepted style guide?

Replies are listed 'Best First'.
Re^2: Commonly accepted style guide? by chromatic (Archbishop) on Sep 26, 2005 at 00:24 UTC
...that person ... thinks style is just as important as functionality. I think it is, if you have to maintain code. Certainly working code is important. If it's truly a one-off and you never have to maintain it, style isn't as important as completeness and correctness. I think it's a bad habit to write unstylish code even for one-offs, though. I've maintained too many programs that managed to stick around far longer than anyone expected. I've also seen too many buggy sections of code written poorly because someone rushed to make a fix. If you don't have the discipline to write code well even when you're experimenting, do you have the discipline to write code well when you're under pressure? Even worse, the respondent has forgotten that TMTOWTDI. That's a silly argument. It's stupid to pound nails in with a rock (or your forehead) when there's a perfectly serviceable hammer right next to you. You don't have to take style advice, but it's free and it comes from a community that has, as a whole, orders of magniture more experience designing, developing, and maintaining programs than any one poster. I think failing to consider that advice, because Perl allows you to solve problems in many ways, is a mistake.	[reply]
Re^3: Commonly accepted style guide? by Juerd (Abbot) on Sep 26, 2005 at 15:55 UTC
Your post is very good and matches the way I feel very closely. ++ If it's truly a one-off and you never have to maintain it, style isn't as important as completeness and correctness. Agreed. But I would like to add that I don't expect code I get to see to be a one-offs, and criticize all style flaws in code I'm asked to comment on. In other words: one better not bothers others with one-offs. Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }	[reply]
Re^3: Commonly accepted style guide? by wolfger (Deacon) on Sep 28, 2005 at 16:44 UTC
[TMTOWTDI]'s a silly argument. It's stupid to pound nails in with a rock (or your forehead) when there's a perfectly serviceable hammer right next to you. But who is to say which way is the forehead, and which is the hammer? More important is that the nail achieves its final destination. Maintainability is secondary to that. The tool used for the job is a far-distant third, or possibly even fourth (Forth?). -- Random Synapse Firing	[reply] [d/l]
Re^2: Commonly accepted style guide? by chanio (Priest) on Sep 25, 2005 at 19:35 UTC
There might be some 'extra' radio boxes when submiting some code block that would dissable the use of perltidy to reformat every piece of code submited. Or other options to add to perltidy: do not erase comments, etc. All these would preserve certain PM standard style for every code displayed, wouldn't it? Landlords production is only eaten by landlords... Wherever I lay my KNOPPIX disk, a new FREE LINUX nation could be established	[reply]


Don't ask to ask, just ask
	PerlMonks