Re: Why our company doesn't use Perl :(

I suppose I'd better give a little background on my learning Perl for this reply: I learned, or more correctly I started learning, Perl during a summer internship. I had relatively little recent coding experience except in VB, which was 1994-ish for a school project (A levels for non-'merkins).

I have to say that I genuinely found Perl quite nice to handle: Okay, my first few programs looked like bad BASIC with C syntax but this is to be expected. In time I learned about 'coding standards', although I would call these 'standardised coding standards', mainly because I already used a series of my own devising. Most were in the style of indenting code in loops, map blocks and so forth: The first was, of course, use strict; at all times.

The last rule, when boiled down to its essence, was that they didn't care too much what code standard we used provided that the code was easy to read and maintain and that there was plenty of commenting on the code itself: It must be noted that this kind of mindset, ie. "You've got a brain, use it!", tended to be fairly common. You were expected to just get on with it and use your common sense to know when to shout for help, rather than just ploughing on regardless.

My conclusion is that provided that your code does things in a sensible manner, is secure and is readable and maintainable, imposing extreme or artificial coding standards can waste more time than it saves. I would guess that this depends on the standard of the coders involved.

Just, as they say, my Ł0.02.

Elgon

Comment on Re: Why our company doesn't use Perl :( Select or Download Code

Replies are listed 'Best First'.
(Ovid) Re(2): Why our company doesn't use Perl :( by Ovid (Cardinal) on Feb 28, 2001 at 22:15 UTC
Elgon wrote: My conclusion is that provided that your code does things in a sensible manner, is secure and is readable and maintainable, imposing extreme or artificial coding standards can waste more time than it saves. It would seem that way, but as an organization gets larger, you wind up with a much greater range of ability and style. This can have a significant impact on code quality and maintainability. Consider the following: Bob decides that the best way to deal with a particular issue is to use a pseudo-hash. Hmm... well, that's an experimental feature. Is it appropriate? Jane thinks that CGI has too much overhead, so she uses CGI::Lite. No one else uses it. Hmm... Irving uses incredibly descriptive sub names like `grab_the_headers_and_look_for_a_id_cookie(\@headers)`. Well, it's descriptive and he argues that it cuts down on documentation. Sally hates having subs that require arguments be passed in a particular order, so she keeps writing wrappers for everyone else's code that allows her to pass a hash. One of the coders I work with right now refuses to declare hashes. Instead, he always declares a scalar and makes it a reference to an anonymous hash. (`%hash = ();` versus `$hash = {};`). As an interesting side note, he's gotten in trouble for writing production programs in Perl :) Every one of the above programmers could make an argument for their particular coding practice. They may even be reasonable arguments. How do you settle issues like that? That's what coding standards are for: to remove that guesswork. I think that it does take some of the fun out of coding, but it does tend to ensure a bit of sanity in larger shops. Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply]
Re: (Ovid) Re(2): Why our company doesn't use Perl :( by footpad (Abbot) on Feb 28, 2001 at 22:32 UTC
Okay, you've got a slightly different problem here. You need to encourage a culture of communication and idea-bouncing. It may help to encourage a discussion area where the team can asked stylistic questions and learn from each other's experiences. In one of my previous "lives," we held these during lunches, called these "brown bags," and kept them very informal. It took some time to get everyone on board, but eventually, we were all learning from each other and the resulting code because more consistent. You could still tell each person's style from their bits, but you could also see where the discussions had made a difference. I forget who said it, but one of the classics on software development practices notes that it takes ~18 months for an organization to move up a level in the Software Maturity Model. The same source also notes that each level must be met. This means it'll take roughly six years to move from a Level 1 organization to a Level 5 (world-class) organization. It may also help to ensure that each resource has time for research. Personally, I like to allocate 15-20% of my time to that, for if I'm not allowed to try things out, I can never learn new things except by experimenting with them in production code--which is a bad thing. Also, leave room for some disagreement and try to find the compromises. --f	[reply]
Re: (Ovid) Re(2): Why our company doesn't use Perl :( by Elgon (Curate) on Mar 01, 2001 at 01:50 UTC
Ovid, it's a fair point: I agree with your point in general but footpad below makes some good ones too: There is a difference between a coding style making sense to one person and it making sense to a group of people who have, in essence, to peer-review the code when it needs updating. Bob, for example, is dead wrong unless there is an extremely compelling reason for using them: Some data structures just lend themselves to certain ways of doing things. Pseudohashes are, as you say, experimental and from what many have said to me, not the greatest tool in the world. In business situations it pays to code defensively. Ultimately, though, settling issues like that should be (IMHO!) by coder fiat: If your manager is a coder (mine was) and there is a dispute, they rule on it. Otherwise the most senior/competent coder (alpha geek ;-) rules on the issue, which, I guess ultimately leads to a coding standard, sigh. I certainly agree that life is different for small and large businesses: Where I worked (and will hopefully be working again this summer) is going through the transition phase. Cheers, Elgon	[reply]


Think about Loose Coupling
	PerlMonks