Re: My coding guidelines

[fruiture]

I think it's no great use making guidelines in general. You'll have to agree on guidelines in one project and it's good to have concrete ideas. The actual decisions will depend on the group.

Some of the things you mention are in my eyes means of sane programming (system calls, exit code). I don't think you can work seriously with someone who has to be told these things. Also, I'd never say "SHOULD". Say "MUST", so first of all there is no doubt: "Use strict! No exceptions. That's it." Someone who _really_ knows when to disable strictness, will do it. Someone who doesn't will struggle for a solution and ask for help and then someone else may tell him "This is the exception, you may disable strict here."

So there are some general rules i'd make (and in general i agree with you):

1. use strict! Always.
2. use warnings! Always.
3. Doing CGI? use CGI.pm! Always.
4. Parsing commandline options? use Getopt::Long and Configure() it POSIXLY_CORRECT! Always.
5. check system calls! Always.
6. Use comments to comment, use POD to document. Don't mix these two.
7. Avoid Globals!
8. Globals are all variables with a scope that is larger (in the sourcecode) than an average screen.
9. Name Globals wisely. Follow perlstyle rules
10. Use spaces to make things clearer

These are the rules I consider "general". Other things are matter of personal taste but should be equal inside a project:

1. open the curly on same line as keyword. Indent next line.
2. closing curly on single line, indented as deep as keyword of opening curly.
3. curly-rule exceptions are special short blocks (map,grep,sort)
4. No space between function name and opening parens.
5. No space between array identifier and opening square bracket.
6. No space between hash identifier and opeing curly

Now finally the Tab-issue: I really think that one should use tabs, but only for indentation. Don't use tabs for alignement.

if( $a > $b ){
T---return
T---T---cond1 ? val1 :
T---T---cond2 ? val2 :
T---T---        default
T---;
}

This way your alignement won't break in someone else's editor using a different tab-width, but logical indentation is still present. I am really convinced that this is a solution.

--
http://fruiture.de

[mpeppler]

Also, I'd never say "SHOULD". Say "MUST", so first of all there is no doubt: "Use strict! No exceptions.

And I was just going to commend Abigail for using SHOULD for a lot of the guidelines.

They are guidelines after all - and there are situations where this or that rule is not appropriate. The programmer should not have to go through hoops to code around the limitation imposed by the rule (but should provide appropriate reasoning why the rule should not be applied).

Michael

[Abigail-II]

I object to those "always" you are using in your list. You wouldn't be able to create useful modules like Exporter and Memoize, if you always had to use strict. Same with warnings. Perl generates warnings if it things the programmer makes an error. But sometimes, Perl is wrong. The right thing to do is turn warnings off, instead of having to go through hoops to satisfy Perl.

As for point 3, I couldn't agree less. CGI.pm is a monster, doing far more than just CGI (come on, producing HTML shouldn't be a part of a module calling itself CGI). In the rare cases I do any CGI programming, I tend to avoid it like the plague.

As for you tab issue, it's a good example why tabs should be avoided. Your example indicates a tabwidth of 4. Any idea how that's going to look like on a terminal with a default tabstop of 8? Sure, the left indents will all be lined up, but can you garantee none of the lines will exceed 80 characters? Any idea what's going to happen if one of the tabs is replaced by 4 spaces, and someone using tabstops of 8 is going to view it? It won't align correctly anymore.

Tabs are evil. The savings in disk space and I/O might have been significant 30 years ago, but they aren't nowadays. With spaces, the indentation will always look the way the author intended it to be (given fixed width fonts). With tabs, it will only look right if all authors and viewers used the same tabstops.

Abigail

[fruiture]

No, this is a misunderstanding: The rule says "you must", because it doesn't want to leave any doubts to somebody who doesn't know enough to break it with sense. I know that if i want to mess around in some symbol tables (e.g. Export or an Accessor Method Creator...) I will turn off strict 'refs' as well, and I want anybody else to do that then. But someone who isn't sure, must not break the rule.

Same with CGI.pm. There's a "must", because you should not question CGI.pm until you know better.

Tabs: This is not about disk space, but it's no use disuccing this. Tabs aren't evil. :)

To clarify: whom are you making these rules for? Do you need to tell yourself "use strict, you(=I) know when I may disable it!"? Such guidelines are usefull in two ways: a) for people who learn Perl, for them I wrote the "MUST". To say "SHOULD" tells them there are exceptions, but there are no exceptions they need to know about yet. b) For a project, to keep it all consistent and easier to make many people work on the same Code. There the "MUST" fits because an exception should be rare and known, because it is an exception. And: I wouldn't work with people who need to be told to use "strict" and when to disable it.

--
http://fruiture.de

[Abigail-II]

As I said in the article, these are my rules, and I don't enforce them on anyone (I don't work with people who need other peoples guidelines - and usually I don't work with anyone). It's my code that needs to adhere to the given guidelines.

Furthermore, I was using SHOULD and MUST in the same sence RFCs use them (that's why they are capitalized). MUST means MUST. It doesn't mean "most of the time, but there are exceptions". That's what SHOULD means. MUST means the rule should be followed always. SHOULD means the rule should be followed usually, but there might be exceptions.

You don't want to discuss tabs, but I'm interested why your preference for tabs. What do tabs give you that spaces don't give you?

Abigail

[strat]

Consering strict, I use the following rule:
Always use strict. If you can't do something with strict, think about if you really need to do it without strict, and if you really need to, disable the part of strict locally and explain why this has to be done, e.g.

if ( ... ) {
  # disabling strict refs temporary because of blabla.....
  no strict 'refs';
  *{ $AUTOLOAD } = $codeReference;
  use strict 'refs';
}

++ Abigail-II

Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

[Anonymous Monk]

That's exactly right. use strict always does not mean you shouldn't no strict when appropriate :)