To be honest this GNU style is a bit awkward as I tend to use K&R.. but I must admit it is really easy to read and understand when reading new code.. but NuttX seems to use GNU derivative anyways so no "generic tools" can be used here and this is the main problem? :-)
https://nuttx.apache.org/docs/latest/contributing/coding_style.html I would be careful with Python, I use it myself, but it becomes more and more self-incompatible in the long term, so I would suggest focusing on generic minimal C-like tools that does not change often with time :-P The coding style is not that important if there are good tools to verify and convert to whatever style is required i.e. vim / emacs / vscode plugin or some script that can convert/validate specific file(s). We can adapt GNU, K&R, Allman, or whatever seems best to the community. Assuming this change will make our life easier :-) Thanks :-) Tomek On Tue, Mar 18, 2025 at 5:18 PM Luchian Mihai <luchiann.mi...@gmail.com> wrote: > > Well, this is what I fear, working for something that may change anyway. > I cannot force this change, If we come to an agreement I'll continue the > work I've started, else it is just a waste of time. > Can we make a choice regarding code style? > > Cheers, > Mihai > > > On Tue, 18 Mar 2025 at 00:32, Michał Łyszczek <michal.lyszc...@bofc.pl> > wrote: > > > Peter van der Perk: > > > The main issue I was facing with clang-format was the indentation with > > NuttX > > > BreakBeforeBraces style see > > > https://github.com/llvm/llvm-project/issues/44188 > > > > Maybe it's time to say it out loud. GNU indent style for curly brackets > > should die ;). Changing these to Allman style should be trivial without > > the risk of breaking anything. > > > > This would enable use of well established project insead of maintaining > > internal one. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
