(Ovid) Re(2): Why our company doesn't use Perl :(

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.

Comment on (Ovid) Re(2): Why our company doesn't use Perl :(

Replies are listed 'Best First'.
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]