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

[Dan McGee]

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.

> then it all goes to pot, since the
> number of tabs/spaces needed to make these broken lines line up properly is
> entirely dependent on your tab width.
Exactly why I'm proposing we do this *not* based on tab width at all.
Two extra tabs, always, end of story.

> The same problem is true for breaking lines to avoid going over 80 columns;
> where 80 columns is for a given line depends on your tab width when you use
> tab indenting.  I use width 4 tab stops, which I think is just about as
> "standard" as you can get with tab widths, but if you're using width 2 tab
> stops, then you can fit quite a bit more on deeply nested lines than I can.
We probably should be using 4-wide tab stops, but as you can see in
the files, the modeline currently sets it to 2. If we were to change
this we would have an awful lot of ugly code staring at us, and I'm
not quite ready to take that plunge yet.

-Dan