On 5/14/19 4:08 PM, Petr Štetiar wrote: > Paul Spooren <m...@aparcar.org> [2019-05-10 17:36:21]: > > Hi, > >> Currently some files use a mixture of spaces and tabs within a single >> file, instead of fixing style manually, a tool could do the job. > I find consistent coding style important, but I also know, how hard is it to > achieve it. It's some time already, so I don't remember all the glory details, > but different clang-format versions produce different results, doesn't support > certain options etc., so it's pretty confusing and introducing another > overhead. True, that's why I liked the idea of using the kernels style. > Then you should enforce it somehow (commit hooks, make target), > otherwise it's going to bitrot after sometime again etc. I'd start working on some CI to test for functionality and also code style. > >> +static struct init_handler handlers[] = { { >> + .name = "sysinit", >> + .cb = runrc, >> + }, >> + { >> + .name = "shutdown", >> + .cb = runrc, >> + }, >> + { >> + .name = "askfirst", >> + .cb = askfirst, >> + .multi = 1, >> + }, >> + { >> + .name = "askconsole", >> + .cb = askconsole, >> + .multi = 1, >> + }, >> + { >> + .name = "respawn", >> + .cb = rcrespawn, >> + .multi = 1, >> + }, >> + { >> + .name = "askconsolelate", >> + .cb = askconsole, >> + .multi = 1, >> + }, >> + { >> + .name = "respawnlate", >> + .cb = rcrespawn, >> + .multi = 1, >> + } }; > it's just me or is this very ugly?
Very true, I think. For some cases it could make sense to disable clang-format: int formatted_code; // clang-format off void unformatted_code ; // clang-format on void formatted_code_again; >> - list_for_each_entry(a, &actions, list) >> - if (!strcmp(a->handler->name, handler)) { >> - if (a->handler->multi) { >> - a->handler->cb(a); >> - continue; >> - } >> + list_for_each_entry(a, &actions, >> + list) if (!strcmp(a->handler->name, handler)) >> + { >> + if (a->handler->multi) { > eh? (I've stopped reading the changes any further) I think it's because I removed the ForEachMacro definition, I'll send a v2. Best, Paul _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel