Dick, While I am responding to your initial post, I also use it as launchpad for sharing my broader position on the topic, so it's not all aimed at you. :)
On Fri, 2009-05-01 at 08:02 -0500, Dick Hollenbeck wrote: > Are other folks having problems with tab expansion differences between > editors? 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? :) If some code cares about indentation, one cannot avoid using spaces; however, code should not care about its indentation. Tabs allow even the most basic editors to provide user adjustment, whereas using spaces forces users to go through extra steps to have the same basic freedom. Consequently, I believe the argument for using spaces instead of tabs suffers from the broken window fallacy. Beyond the essence of "do not use spaces for indentation," my theory on whitespace holds numerous corollaries: comments should not follow code, never indent code more than 2 or 3 levels, and so on. > I load jtag.c into two different editors and get two different results > when tab width is set to 4. > > This makes it difficult to view a table like tms_seq in the two > editors. The editors are well established, JEdit and gedit. This is a design bug stemming from the lack of a consistent set of rules for editor writers to follow. For example, what should be done if there are both spaces and tabs? I could come up with different answers that would result in exactly the kind of problems that you were seeing. Since the code in question mixed both kinds of whitespace, I removed the extra spaces to "fix" this problem. It looks fine now at tabstop=4, except for the fact that I normally use vim in an 80 column terminal. If this solves yours problem, you can probably use this information to figure out which editor produces the anomalous output and why. It would be ludicrous to suggest that OpenOCD change its style in reaction to the fact that editors everywhere will not display tabs consistently, when most do handle them just fine. It seems more reasonable to claim that editors have bugs in them if their output does not match de facto standards used by emacs, vim, SlickEdit, BBedit, and other professional-quality editors. Further, not all editors support tools for reformatting code, nor should they be assumed capable of performing lossless reverse transformations after edits have been made to these supposedly beautified files. Still, the idea of such is entrancing; it's a Holy Grail of editor features. > This reminds me why in my own source code internally, we don't use tabs. > > It extremely hard to mis-interpret the width of a space, and my hard > disk, compiler, and eyes cannot tell the difference. 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 think the Linux kernel has the best style rules on the planet. Beyond some basics, its style was evolved by the brutal forces of natural selection; countless developers have debated this topic. Only the best and fittest style rules survived in that meme pool, so I would like to see the OpenOCD project draw from it. 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. I have no complaints about tabstop=4, but I will try to contribute patches that also conform to tabstop=8 (with a soft 72-80 column limit, no less). The reasons for this practice stem from a lesson that I learned many years ago (though cannot properly attribute at the moment): If a function has grown to require more than 2 or 3 levels of indentation (at 8-spaces per tab level), then it probably needs to be factored into smaller pieces, have its flow control restructured, or otherwise be rewritten. In other words, such style guidelines become an effective tool for measuring and improving the quality of the code. I have tried to help demonstrate these principles in recent patches to the J-Link driver, but I believe much of the OpenOCD tree needs similar work. 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. This may sound like very harsh opinions, so I want to end by saying that these apparent shortcomings OpenOCD project in no way detract from its functional accomplishments. These are purely stylistic issues, and everyone here should know better than to judge a book by its cover. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
