Hi Aaron, list, Aaron Muir Hamilton writes:
> Some of these misleading indentation errors also look like genuine bugs. > Here's one gem from backends/genesys_gl847.c which turned into a > misleading indent when I ran it through clang-format: > > 660 while (val8 & REG41_FEBUSY); > 661 { > 662 usleep (10000); > 663 status = sanei_genesys_get_status (dev, &val8); > 664 }; > > Pay close attention to the semicolons. Things like this is why I prefer to address the compiler warnings one at a time and ask for feedback where not sure what to do. > As an aside, this is probably why the 1TBS is superiour to GNU-style. Not familiar with 1TBS, so I looked it up[1] [1] https://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS_.28OTBS.29 OK, got it. Fine with me, though most of my own C/C++ code uses GNU. We all have our preferences and I am not going to step on people's toes trying to enforce a "one true style" for all of sane-backends. Backend maintainers can use whatever works for them in those files that make up their backends. All I would like to ask is to use whatever they prefer consistently throughout a file. If the file includes hints for common editors that's great but that is typically limited to emacs and vim. Adding an EditorConfig[2] entry would be better as that ought to work for even more editors and IDEs. [2] http://editorconfig.org/ What I would like to apply throughout though is - UTF-8 encoding everywhere - no trailing whitespace at the end of line - no trailing empty lines are the end of file - new line at end of file That shouldn't be too controversial but I'll stay away from the coding style (and tab versus spaces) wars ;-) > Aaron Muir Hamilton <aa...@correspondwith.me> writes: > >> Olaf Meeuwissen <paddy-h...@member.fsf.org> writes: >>> # Never even mind Fedora 26 and Debian 9 on the horizon which'll trigger >>> # a small "tsunami" of compiler warning fixes and autotools updates ... >> >> It's ugly work, but maybe it's time we normalize the formatting in some >> of the files (especially ones which are abandoned-ish and don't have >> open patches). A lot of the compiler warnings I see (I run Arch Linux, >> so I'm on bleeding-edge-ish GCC most of the time) are things like >> misleading indentation warnings. We don't need to invest in any >> infrastructure for formatting IMHO, we could just do a once-over with >> clang-format on some of the files. As mentioned above, we all have our coding style preferences and some of the developers may be more outspoken than others. Since I like to keep as many of them around as possible, I prefer to tread carefully with a blanket re-indent of (some of the) code files. If the indenting is more or less (more rather than less) consistent, I don't see any need to redo the indenting. We have a number of builds[3] among which Fedora 25 should give results close-ish to what you see. Checkout out one of the recent logs[4]. [3] https://gitlab.com/sane-project/backends/pipelines [4] https://gitlab.com/sane-project/backends/builds/16802918 I try to keep the ci-envs[5] up-to-date with *stable* releases, so Fedora 26 (and Debian 9?) should be just around the corner. [5] https://gitlab.com/sane-project/ci-envs Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org