On Wed, Feb 18, 2009 at 9:45 PM, Bryan Ischo <bji-keyword-pacman.3644cb@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