Re: My coding guidelines

[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

[Aristotle]

The reason I like tabs is because of metainformation - one tab = one level of indentation. I use tabs only at the beginning of the line and only to indent. If I need to vertically align, say, the fat commas in a hash assignment, I use spaces; even if for some reason I wanted to right-align said hash keys I would indent them with tabs then add spaces in front of the keys.

That way, so long as you don't vertically align things on lines across different levels of indentation (and if you want to do that, something is probably wrong), everything will always line up regardless of the reader's tabwidth setting.

(See Re: download progress with gtk for an example of how I indent.)

Makeshifts last the longest.

[fruiture]

Ok. In the sense of an RFC "SHOULD" is more appropriate.

Tabs give me the possibility to indent code as I prefer it (Tab=4 Spaces) without forcing anyone to view it exactly the same way. People use indentation from 1 to 8 columns, why should i have to force anybody to like 4?

And about the 80-character width: You'll need a 48 character statement on a line after 4 8-Space-Tabs to hit 80 characters. For two reasons this cannot/should not happen: You should always break lines after about 30 characters for readability AND indentation deeper than 4 levels should indicate that a subroutine to split up the nested logic is needed.

--
http://fruiture.de