PLEASE READ: Whitespace rules

[Kevin Ballard]

* Why have rules for Portfiles? Isn't that the maintainer's prerogative?

Yes it is, which is why I marked those rules as SHOULD rather than  
MUST. Having consistent rules for Portfiles aids reading of  
Portfiles, especially if the Portfile is marked openmaintainer@ as  
those are edited by multiple people. But if a maintainer prefers  
their own style, they may use it.

* Last time we decided that developers working on base/ code should  
conform to the surrounding style.

No we didn't. Last time one person loudly objected, and the  
discussion eventually died without coming to any consensus. However,  
having consistent style rules is very important. As it stands, every  
single time I edit base/ code I have to worry about my tab settings  
and I frequently have to go back and re-tab things to conform to the  
surrounding style simply to avoid extraneous lines on the diff. This  
is especially bad when the surrounding style itself isn't consistent.  
Additionally, some code has tabstops of width 8 and most has tabstops  
of width 4, so I can't even read some code without changing my own  
tab width. There's a reason most open source projects have style rules.

* Why add modelines to files? I don't use vim/emacs so they're  
useless noise.

vim and emacs are the two most common command-line editors, and they  
(well, emacs) are also responsible for the 8-width tabs scattered  
throughout the code as this is what emacs and possibly vim (I don't  
remember anymore) defaults to. Since we have the power to explicitly  
mark our files as wanting certain spacing rules in vim and emacs, we  
should. If other popular editors supported modelines then we'd  
consider adding rules for those, but I'm not aware of any other  
popular editor which supports modelines. As for it being useless  
noise, I disagree. All our files are already prefixed with license  
text, so adding one more line of comment won't make any difference.  
If it hadn't been pointed out you probably wouldn't have noticed.

* The modeline is greater than 78 characters, it should be split up.

True, it is larger than 78 characters, which is the traditional line  
length to accommodate terminals. But our source isn't wrapped at 78  
characters. If we ever establish a 78 character line length for our  
source, then the modeline would have to be wrapped. In that case we  
would split the vim modeline off from the emacs modeline.

* I like hard tabs, why can't I use those? Or: I prefer soft tabs of  
size 2.

We absolutely need a consistent standard. The source is a complete  
mess without one. Unfortunately, there's no single standard that will  
please everybody, so we need to go with a common compromise. Soft  
tabs were chosen in order to make it easier to read source code in  
any editor. When hard tabs are used, the source looks different for  
people who have tab size set to different lengths. This is a real  
problem when tabs are mixed with spaces (as is common). You can open  
a source file and see perfect indentation, and I can open a source  
file and see nested scopes indented less than their parents. Soft  
tabs ensures everybody sees the exact same indentation. As for a tab  
size of 4, that was chosen as it's the most common tab size for  
source code, and a standard is needed for this as well to ensure code  
consistency when editing. A size of 2 would work just as well if  
everybody agreed to it, but since 4 is more common, 4 is what was  
chosen.

* Shouldn't we have a vote on this?

No we shouldn't. Every time we've tried to come to a consensus, the  
issue has stalled. Therefore I'm going with a dictatorial approach on  
this. The only way to get a good standard is to force it on  
everybody, and we desperately need one.

* What about style rules for braces, etc?

We probably should write down rules for those, but there isn't really  
a need at this point. Tcl disallows the statement-newline-brace  
syntax favored by some C coders, and that tends to be the biggest  
divide among coders on style rules. There may be other points of  
contention, but they don't affect people anywhere nearly as much as  
the whitespace rules. If someone wants to write up a style document  
for the non-whitespace rules, please do send it to the list and we'll  
have a vote.

* Wait, didn't you just say the dictatorial approach was better?

No, I said it was necessary. Voting is good, but voting didn't work  
for whitespace, and we needed rules. But we aren't in desperate need  
of other style rules, so voting is fine there.

* I have another question/complaint.

Please send it to me and I'll address it in another email.

-Kevin Ballard

-- 
Kevin Ballard
http://kevin.sb.org
eridius at macports.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070907/fce5f548/attachment.html