Zach Welch wrote: > Sheesh. One religious war per week isn't enough? ;) We made it past > the C vs C++ language war only to be caught up in whitespace wars? :) > Just my thought. We have had this discussions - what, half a year ago?
I do not understand why such taste discussions have to pop up every time a new developer joins a project. It is simply not possible to satisfy everyone's taste, so IMHO a project should stick to the project's styleguides until there is *very good* reason to throw them out. > I have been a tabstop=8 guy for 10 years, and tabstop=4 prior to that. > 8 spaces is much easier on the eyes; blocks are more clearly visible. > Work on the Linux kernel finally made me switch for good. > I tend to prefer 2 spaces, but I don't really care since emacs does the indenting for me most of the time - I just need to know the preferred style for a project directory. > However, even that project helps make the point that most style rules in > a project can be traced back to one or more initial contributors, and > inertia keeps the project on that track. In this respect, OpenOCD has > been using tabs and should continue to use tabs; tabstop=4 was its > original standard and should continue to be. Any gradual change at this > point would result in a mixed soup, and total conversion offers dubious > value at the cost of completely disrupting everybody's working copies. > Full ACK from me. If part of the code is indented wrong, it should be fixed, but changing *all* of the source to a new style is not the right fix for such a problem. > So the type of whitespace should be less concern than how much is used; > excessive indentation is a pandemic problem in the OpenOCD code. This > does not mean to apportion blame; it is my observation as a professional > software developer. If I were its architect, much of the code in the > tree would be rewritten to fix these problems, as it is virtually > unreadable (and thus practically unmaintainable) in its present state. > I think that comes from incremental development: in order to provide small, easily reviewable patches, it is easier to just make the needed changes instead of refactoring code where is is needed. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
