[pacman-dev] Code style (was: [PATCH 2/3] Enabled a new prompt...)
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
Dan McGee wrote:
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.
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
On Wed, Feb 18, 2009 at 10:55 PM, Dan McGee <dpmcgee@gmail.com> wrote:
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.
I think it's neat that lots of people encourage 8-wide. This way you automatically know when you're indenting too much because your_code( starts, looking, like this);
participants (3)
-
Aaron Griffin
-
Bryan Ischo
-
Dan McGee