On Wed, 2009-04-22 at 00:05 -0700, Rick Altherr wrote: [snip] > I'm going to hold off on this one. We don't have an established > standard for comment-based navigational aids. I've used a few > different styles over the years and each project seems to have a > different preferred form. I'm a fan of consistency, so I'd like to > pick a form and stick with it. I'd also like to set some guidelines: > > - Only use navigational comments (rulers) to break up a large file > into related blocks of functions (not individual functions) > - Rulers between a #define block, a type definitions block, and a > prototypes block are encouraged > - The line immediately after a ruler should be a comment containing a > description of the next block > > This makes them not only a visual cue but also informative. > > FWIW, my preference is to use: > > /* -------------------------------------------------------- */ > > I also like using "#pragma mark -" if your editor supports it, but > that seems to be a very hit or miss item.
I had forgotten about that #pragma for some time, but I know it was for the reason that you just gave. I use vim but without any code-folding or other visual tricks; I end up visually scanning up and down through files. Full-width markers are critical for me to do that quickly, as I tend to use them against the overall pattern of the code above and below them (without having to read the code itself). I prefer '=' because it proves a little more substance than '-', and the patch shows that I use two of them where you want only one. I will only use them after every function when each one spans more than 40-50 lines or so (which to me is exceptionally long), otherwise I use a single line to de-mark logical sub-groups more or less at the same interval. Since I am about to spend a lot of time in that module, it was just a last little touch to make myself completely at home in that module. While it would be nice, it's obviously not on my critical patch. :) Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
