> we mandate comments as follows:
> /*
> * something
> */
No we don't. We had a long discussion about multi-line comment styles
some years back and I made the same argument there. ;) That's why our
coding style now allows two versions so you can pick whatever suits
the situation at hand better:
/*
* long
* form
*/
/* short
form */
> I note that the changing our comment style would have zero impact on
> code safety. The improvement of requiring a { on the ifs is known to
> have positive impact; it's why Rust and Go both require it to my
> understanding.
How is this actually "known"? Does that take the (relatively recent)
-Wmisleading-indentation into account? I think after all these years
where this has not (to my knowledge) caused any problems to coreboot,
"fixing" it now that we even have a compiler check to catch it seems
weird. It's complicating things for humans in favor of something that
a machine can (and already does) solve just as well.
> As for "the kernel" and its coding style, we are going to increasingly
> see people coming from worlds where "the kernel" and its coding style
> matter less and less. Maybe adherence to "the kernel" coding style
> mattered ten years ago; I don't think it is as important now. In my
> case, increasingly, "the kernel" coding style is looking a bit dated.
Are we? Why? I've helped dozens of SoC vendor engineers get started
with coreboot in the last couple of years and they all came from
kernel-style backgrounds (Linux, U-Boot or other projects using the
same style). Of course there are also people coming from elsewhere,
but I don't see kernel style becoming "unimportant" anytime soon. I'd
bet 95+% of coreboot systems run Linux afterwards, and when adding
support for new platforms it's just normal that the hardware vendor
has the same people working on both kernel and firmware drivers for
the same component.
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
