TIMTOWTDI, but enough rope to hang yourself?

[pmas]

This meditation was inspired by tilly response Re (tilly) 2: lifetime of refs to DBI handles passed to sub as hash elements and assigned to scalar within it to original VSarkiss response.

I am meditating about how to encourage forming good perl-coding habits.

VSarkiss advises: Don't make a habit of calling subs with the &. You're better off ... using () -- and gives good reason (IMHO) for it.
tilly agrees, says he prefers (), too, but says I wouldn't say that that choice is the One True Rule that everyone should follow. Which I agree - TIMTOWDI.

But still: clemburg in his response to Is Perl the End-All? he says perl (because of it's flexibility) is ill-suited to development in large teams (which I agree - I am also struggling with it right now). His node has rather high reputation (I ++ too), and I believe that part of it is for mentioning CPAN, but also part of it for above mentioned feeling about development in large teams. There was another discussion here about some boss preferring Java or VBasic before perl - because of less coding freedom means easier to enforce and maintain coherent coding style across whole development team.

I have to say that I came into perl with experience in many less forgiving languages, so all this freedom often amazes me - and I like it, why not. I also understand that perl started as language for writing simple scripts, and many users are coming with admin needs and background, and all this freedom is just fine in small programs.

Perl idea of freedom is to give you enough rope to hang yourself, if you are tempted to. But sometimes I got paranoid feeling that there is enough rope around my neck, and I cannot feel it ... yet, but rope is still there. Sometimes I am making decisions without fully understanding the price I just agreed to pay.

Example: I started using hashes a lot, but then I read runrig response (last one) in Array vs. Hash (newbie perlguts), and now I am rethinking my design decision, using arrays where appropriate (Thank you, runrig, for pointing this out). I had gut feeling I could later pay the price for hashes, but it was simpler to begin with them - and then adding one more is even easier...)

If perl allows a lot of freedom, but in one way there might be later steep price to pay, I believe it is decent to warn. If your colleague has no time or temptation read why, it's better to tell "if you do not want to read all use CGI or die;, just believe me and use CGI", than let him hang yourself, right?

I know there is no one simple correct answer, a lot depends on personal preferences, many of perl hackers do not work in teams at all (so they do not think about differences in style), TIMTOWDI after all... But still, I will prefer if next perl6 was optimized more for writing projects in teams, and less for writing poetry and obfuscation. I know this is not going to happen, so I hope at least perl7 will be? ;-)

Back to beginning, for me very good reason to use notation function() instead of &function is also that with () I can immediately see it is a function call (in many languages). When trained to see this from start on, beginner's eye will just get used to it - in all languages coming next. That is why I like changing -> into . in version 6.

Basically I have group of colleagues which are just typing code in perl, and I would like to have some guidelines, but I am not in position to enforce them. They claim they have freedom to do it, because perl allows it. So I hardly can do something about it. And I know that is easier to learn good habits, than learn and unlearn wrong, and re-learn good habits later. And I cannot do anything for my colleagues (and my project).

So I was thinking what we (PM) can do for other monks around here. Sometimes I do not have time to read explanation why something is dangerous, it's faster just to believe gurus. Even if something is preferable in only 90% cases, if you are beginner and not sure why, it's safer to do it as gurus do - you have 90% chance to do it right. You do not want too much rope...

I hope my thoughts were not too obfuscated - I should put this into obfuscation, maybe... :-). Other than that - perl is just fine...

pmas
To make errors is human. But to make million errors per second, you need a computer.

[the_slycer]

I am speaking from very little experience here, as I have never worked on a perl project with another person - always solo

However, I think that every project (be it perl, or one of the more business type projects) needs a plan in order to succeed. Included in the plan should be guidelines as to what is accepted for the results you are trying to get.

Did that make any sense? I think not, let me try to explain further. On a non-code type project (and no I am not a project-manager) there is always a set goal. In order to achieve this goal with the best possible results, there must be a plan put in place. In that plan, there are often rules included - such as when expenses need to be handed in (weekly, monthly, end of project), and when documentation is expected by. Often, there is a template so that all the documentation for each portion of what each team member is working on looks and feels the same. These are just guidelines that I have come across in my non-code projects.

I feel that the same concepts can be applied to code type projects as well. There need to be guidelines, for example, any web stuff, we use CGI, we don't use Lingua::Romana::Perligata, we comment all subroutines with an explanation etc.. If the guidelines are well enough defined at the start of the project, the code should be "standard" enough in the group that anybody can look and see what the other person is doing. This is probably especially important for a large coding effort.

In this method, I think that the freedom of perl will be somewhat negated by the restrictions placed on the project, in this case, that's not a bad thing at all.

[pmas]

Sure we use CGI, obviously. I am not talking about obvious decisions, but more about less obvious, allowed by perl standard. I.e. to make group to use use strict I needed to sneek it in: add it to include what is used by others - and my colleague fixed the code only after it broke, she complained that my incude is wrong, and I suggested I'll add my to all her variables for her.

If you never worked in team, you'll never experienced feeling when your colleague is doing something wrong what you never thought doing yourself for obvious reasons, and stlii cannot to anything about it - complaining about wrong style to your boss is out of question, right?

About having plan: Dilbert cartoon: Dilbert ask Poity-Haired Boss: "In order to write project plan, I need to know our strategy". And PHB answers: "My strategy is make you to write a plan." ;-)

So you can ask to have a plan, it sounds nice in theory. In real life, your boss is busy to handle multiple projects, meetings and all, and plan is to make customers happy ASAP. Then you are voting on non-obvious design decisions... And we all know how voting system failed BIG TIME last time...;-)

Guidelines... I was just meditating that if perl was less flexible, less guidelines will be required. Because less effort to persuade your boss about that guidelines needs to be will be needed. And all large coding effort start from small efforts - often started by people who are just starting and do not know how to handle big projects at all.

Probably big part of my problem is I am part of a project started before I came on board, and I was called in for my experience in big projects, but other have longer experience in perl (although less in application development), and it is also in university environment where freedom to create as you wish is more important than discipline to work in team is in industry.

I am having good time learning perl, I do love CPAN and PM, I am just afraid the time when I will need to fix some of the code being written...

pmas
To make errors is human. But to make million errors per second, you need a computer.

[Maclir]

A few brief comments regarding team programming that are applicable to any language. If you are the development manager, project leader, whatever - you should have the ability to set (among many other things) the coding standards. Often a large organisation have these already, otherwise as a project leader I have set the rules myself. For example, back in 1994, one standard I set was that when displaying a date, the format WILL BE dd mmm yyyy - making today 31 Aug 2001. (of course, the internal representation was as an integer counting from the start of epoch, but here we are specifying how dates are visually presented to users)

If I was managing a project where Perl was the language to be used, I would set standards that I believe are good - such as mandating use strict; and so on.

Remember, in any good development project, you should be having code walkthroughs with other team members - and a senior developer to ensure standards are being followed. This may sound outrageously fascist to some people, but this is one way to make sure your project will be a success. So - set sensible programming standards, and make sure they are followed.

[dragonchild]

Heh. In other words, follow Code Complete's advice. :)

------
We are the carpenters and bricklayers of the Information Age.

Vote paco for President!

[jepri]

I started programming in the laguage famous for ruining peoples style - basic. After some years ripping out code in QuickBasic I cam to the conclusion that it wasn't ruining my style, as my snotty C coder friends would frequently comment.

It was improving my style.

In the free form languages you can be astoundingly sloppy. But when you start churning out a few hundred lines of code you rapidly realise that if your style sucks, you won't even be able to finish your program. It will be too large and confusing. If you are sloppy, it will never work. If you discipline yourself, you can write huge programs in basic.

So to your problem - you can do anything with perl, but you can prevent yourself from achieving your goal. Clearly you realise this but your other coders don't. Have you tried explaining what could go wrong if they continue their bad habits?

In a team collective discipline is all important. You may not be able to convince them to work together, but perhaps you can head off the worse abuses by pointing out how they could torpedo the program with really bad practises.

If you don't know why the gurus do things, it is fine to ask. Most people here are ready to debate the finer points of just about any technique.

Finally some people just don't learn until they've done it the hard way. You can talk to them until you are blue in the face, but they won't change without the personal experience. I still encourage the people I work with to program correctly, but there will always be someone who insists that he doesn't need to comment his code at all because it is self-documenting, or that he doesn't need taint checking because his code is so good, or...

____________________
Jeremy
I didn't believe in evil until I dated it.