[pacman-dev] Code style (was: [PATCH 2/3] Enabled a new prompt...)

[Bryan Ischo]

Dan McGee wrote:
> On Wed, Feb 18, 2009 at 9:45 PM, Bryan Ischo
> <bji-keyword-pacman.3644cb at www.ischo.com> wrote:
>   
>> Dan McGee wrote:
>>     
>>> You can wrap this if you want, ignore my earlier weird recommendations.
>>>
>>>       
>> Are you talking about the line length issues you pointed out before?  And
>> are you saying here that it's OK to wrap the lines to fit 80 columns in my
>> editor, rather than trying to match another environment?
>>
>> I think that's what you're saying.  I will henceforth wrap wherever makes
>> the most sense for me.  You hadn't commented on my comments before, but I
>> think you agree that the pacman code style guidelines unfortunately cause
>> problems like these.  Using tabs for indentation only works for unbroken
>> lines; as soon as a line is broken and the second half needs to be lined up
>> on a non-tab-boundary (with function arguments on the second line lining up
>> with those on the first, for example),
>>     
> Here is the false statement. Lining things up makes for a hellish
> experience, and never seems to work right, and only encourages the
> spaces vs. tabs debate. Just let the editor do the hard work for you-
> I don't want it to line up at all. Two additional tabs is the standard
> going rate in our codebase, as this is what vim does by default
> anyways.
>
> The only way lining them up makes sense is if your function name is
> super short- as soon as your function name and return type are more
> than 30 characters, you are just needlessly cramming everything over
> to the right.
>   


Fair enough; I don't think we're likely to agree on indenting issues (my 
philosphy is "if emacs does it it must be right :)") but I am happy to 
obey the pacman conventions as necessary.

I've thought about this issue a bit outside of this particular 
discussion and I think what would be awesome (and what I think I would 
do if I owned a project like pacman - although I'm not suggesting that 
the pacman devs ought to follow my ideas here), is for the checkin 
process to automatically run the 'indent' program on each source file to 
normalize the indentation to some vanilla predefined format, and the 
checkout process would run a user's custom version of indent to make the 
code look how they want.  So in your own tree, you'd always be looking 
at code indented how you like, but the code as checked into the 
repository would always have a set indentation (otherwise, there would 
be pointless whitespace diffs in every checkin as people's 
locally-indented files change indentations on checkout).  Of course the 
source control system would have to be smart enough to run indent as 
necessary when doing diffs as well, and probably there would be a 
million corner cases making the whole thing a nightmare but ... wouldn't 
it be so cool if everyone could have the source indented how they want 
it to be indented, all the time, in their own view of it, but the 
repository always used a single standard indentation style?  I think it 
would be awesome!

Bryan