On Thu, Sep 1, 2016 at 2:34 PM Barret Rhoden <[email protected]> wrote:
> On 2016-09-01 at 21:10 "'Christopher Koch' via Akaros" > <[email protected]> wrote: > > The style guide Akaros has chosen to follow is slightly different from > many > > of the common ones (kernel, llvm, ...) and setting up tools to automate > the > > formatting doesn't quite do it right. > > The intent is to be like Linux's format. > > If you have code that is formatted in accordance with the Linux kernel, > then that is fine. If I, or some tool, complains about code that is > OK by Linux's standards, let me know or ignore that tool. > > The only major deviation we have is 4-space vs 8-space indents. I > regret that choice, but I am also reluctant to do a blanket change > because I value the results of git blame. Last I checked, blame did > not have an option to ignore a commit. > > That being said, the comments I regularly make about tools not being > perfect when it comes to code formatting are also true for the Linux > style. I forget where I saw that same point on LKML or wherever. > Akaros seems to require some things that the Linux kernel style guide doesn't ask for. For example, parameters of a function definition are indented with spaces if they do not fit into 80 characters. Same for function calls and arguments. The Linux kernel style guide does not specify spaces, which means it's tabs, and it only specifies that the new line be indented "substantially to the right" (as opposed to aligning with parens). This is not something that I can easily configure in vim (but something that clang-fmt easily does -- that's why I had switched). But clang-fmt indents struct initialization with spaces instead of tabs. So I have to either sit here and hit space 20 times to indent function args, or replace space-indentation with tab-indentation in clang-fmt. It's a pain. > > > It seems I can either choose to (a) format manually, (b) use one out of a > > number of broken/unconfigurable tools, (c) spend hours or days fixing the > > broken tools or adding configuration options. It seems that all three of > > these are a huge waste of time. (And a huge source of frustration.) > > Honestly, I do option 'a' (manual format), in that I write to that > particular style from the get-go. > Not everyone is as familiar with the style guide. It's one of too many to keep straight in my head -- I need and want tools to do it for me in every project so I can concentrate on the stuff that matters. Even if I knew it easily off the top of my head -- I don't want to be sitting here hitting space 20 times for function arguments, because I can't configure vim to indent correctly when I hit tab for that. > > > You should especially take this into consideration given the developer > > velocity points that have been brought up over the last few months. > > I wonder how much time is spent on formatting versus the endless > discussions about formatting. > I'm not sure I've argued about formatting before. So I've definitely spent way more time formatting. But it's time now. Let people automate this. A tool serves two purposes here: it kills the time spent formatting manually, and it kills the time spent arguing (because you can just point to the tool). Chris > > Barret > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Christopher Koch | Software Engineer | [email protected] | 650-214-3546 -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
