On 2014/1/20 1:54, Serge Hallyn wrote: > Quoting Qiang Huang (h.huangqi...@huawei.com): >> Hi Serge and Stéphane and list, >> >> I'm sorry but I need to complain about this :( >> >> I saw LXC's CONTRIBUTING file, it says: >> "The coding style follows the Linux kernel coding style" >> >> But after reading code these days, there are too many very-long-line >> codes, especially in cgroup.c, this really cause some inconvenience, >> when reading LXC code, I can't vsplit my vim any more :( > > I think that's overstating it... I do it all the time and I have > tiny cheap low-resolution laptops. > >> I don't know if this is an issue for other guys, can we keep the >> rules for the future reviews? >> >> Thanks and best regards. > > It's something I've had mixed feelings about over the years. I'd > like to enforce it, but the code never really followed that to > begin with and I haven't wanted to have some big patch doing random > code churn to follow that guideline. > > The vsplitting is a minor nuisance, and that effect is mentioned > in the guidelines, but the *main* point of that rule is not for > controlling line length itself. The main point is to de-facto > control condition nesting in functions. So if you have too much > > if (a) > if (b) > if (c) > ..
Yes, vspliting is a minor complain, the bad nesting and bad naming and bad format are my real points. I'll try to clean up some of that conditions when I spotted again. > > then you should be considering introducing some well-named helper > functions. I do try to enforce that rule, and patches (small, > targeted, clear) to improve code flow would be welcome. > > -serge > > _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
