<div dir="ltr"><div>Thanks Brendan for putting this list together and getting the discussion going.</div><div>It's an important discussion to have.  A coding style or coding guidelines is crucial developing software collaboratively and effectively.  Especially since we all want OpenBMC to have other contributors eventually.</div><div>I'm still catching up on thread.  I wanted to give my reply to Patrick's msg even though Brendan's has already replied.</div><div><br></div><div>On Wed, Nov 2, 2016 at 10:18 AM, Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>> wrote:<br></div><div>> Our legacy product is somewhere between 1 and 3 MLOC.  Titus talked<br>> about the internal Google repository being on the order of 10 MLOC.<br>> Code bases this big certainly have unique problems and the code rules<br>> were put in place to mitigate some of these problems.  The two key<br>> points of Titus' talk were:<br>><br>>     1) Have a style guide; tailor it to your situation.<br>>     2) Use your guide to encourage "good" and discourage "bad".<br>><br>> I strongly feel that if we simply leap to a style guide targeting a<br>> monolithic N-MLOC codebase, we are taking on solutions that are not<br>> relevant to our own problems.  My expectation is that OpenBMC is a<br>> collection of small, self-contained repositories on the order of 5 -<br>> 50kLOC each.  The dependencies between repositories (interfaces) are<br>> purposefully segmented via the DBus interfaces, which represent a very<br>> different problem from a monolitic codebase where a new dependency is<br>> simply an #include away.  With small repositories, the code itself can<br>> "fit in the head" of a maintainer or active contributor fairly easily[1].<br></div><div><br></div><div>The features Brendan discusses may appear in the Google style guide but they are equally applicable to smaller code bases.  In fact, I've worked on embedded systems with a much smaller code base, prior to working at Google, and the style guide had most, if not all, these items.</div><div><br></div><div>As for fitting in the head of the contributor or maintainer, I don't think it's reasonable.  One of the points made during our meeting was that openBMC should be a project other people can come in and contribute to.  Future contributors may or may not be devoting all their time to openBMC and may not have the bandwidth to "fit" one of the repos in their head.</div><div><br></div><div>Btw, Google's codebase is not monolithic.</div><div><br></div><div>> My typical philosophy regarding coding practices tends to be fairly<br>> pragmatic.  I don't tend to see practices as "black" and "white" but<br>> more along a scale of how much justification you need to have to use a<br>> practice (more on this in the specifics, maybe).  The aspects that<br>> concern me more, when I am doing code reviews, are in the general sense:<br>><br>>     1) Conciseness:<br>>         - Did you use far more lines of code to solve the problem than<br>>           necessary?  Those are lines we have to maintain.<br>>     2) Modern, widely-accepted practices:<br>>         - This is already spelled out in the 'contributing' doc, having<br>>           priority over any specific style statements. [2]<br>>     3) Performance:<br>>         - Favoring in order { Code size, CPU utilization, memory size }<br>>           due to the unique concerns of the OpenBMC project and current<br>>           technologies used.<br>>         - Macro-level optimization that does not violate conciseness and<br>>           clarity:<br>>             - Are the algorithms used of the appropriate algorithmic<br>>               complexity?<br>>             - Are you avoiding practices that would contribute to large<br>>               generated code sizes?<br></div><div><br></div><div>We're not suggesting the style guide be black and white.  Every rule has it's exceptions.  But rules provide structure which is necessary when trying to collaborate.</div><div><br></div><div>Thank you for this list.  It's general, but still helpful for those of use sending code to you for review.</div><div><br></div><div>> Quantifying "code smell" into a set of non-ambiguous rules is a hard<br>> problem and, as such, one that I have avoided up until now.  I would<br>> prefer we start with industry recognized experts opinion[3] and then<br>> document deviations specific to OpenBMC as they come up.<br></div><div><br></div><div>I haven't read all of [3] in detail but,Brendan's list isn't meant to replace any industry guideline, just spell out guidelines for a few things that we feel are particularly important to writing concise, debuggable code.</div><div><br></div><div>And while it's hard to write a set of guidelines, it's a worthwhile task to complete.  From [3] "Please remember that one purpose of a guideline is to help someone who is less experienced or coming from a different background or language to get up to speed."  Ideally, as OpenBMC is adopted, there will be more contributors, so this guideline will help them.  Right now, it'll help us collaborate.</div><div><br></div><div>I also want to echo Brendan's caution in his reply with regard to citing industry experts.  [3] is not a list of do and don't dos by industry experts.  Their abstract clearly states "Please try to verify or disprove rules! In particular, we'd really like to have some of our rules backed up with measurements or better examples"</div><div><br></div><div><div><br class="gmail-Apple-interchange-newline">> >     * Variables of class type with static storage duration (including<br>> > constants),<br></div><div>> CppCoreGuidelines I.22 and R.6 already have this point covered<br>> sufficiently to me without further elaboration.<br></div></div><div>> >     * Implicit conversion constructors and operators<br></div><div>> CppCoreGuidelines has a "To-do: Unclassified proto-rules" section which<br>> says "Avoid implicit conversions".<br></div><div><br></div><div>For these items, I think the CppCoreGuidelines are more or less in line with what Brendan has proposed.</div><div><br></div><div>> > On the other hand, we do not think restrictions should be placed on using<br>> > virtual<br>> > functions.<br>><br>> I was not proposing an elimination or prohibition on virtual functions,<br>> but a "justification required".  As in, you need to be prepared to<br>> answer how this is better and why compile-time polymorphism would be<br>> insufficient.<br>><br>> CppCoreGuidelines C.10 suggests effectively the same thing: "You need a<br>> reason for using a hierarchy."<br></div><div><br></div><div>CppCoreGuidelines do list reasons for using a hierarchy in C.120-122.  I think these are sufficient for most of the cases of inheritance that we'd be interested in.</div><div><br></div><br>----------<br>Nancy<br><br><br></div>