Hello, I have tried to make a clang format configuration to use, but I have the same problem where there are a couple style items that clang format has no options for. Things like enforcing lowercase hex or putting curly braces indented on a separate line after static initializers.
On Mon, Mar 17, 2025, 8:52 AM Mark Stevens <m...@thepcsite.co.uk> wrote: > Has anyone looked at using a custom .clang-format file to see if we can > get close to the NuttX style? > > I’ve used this route in a couple of projects. I did have to compromise on > one or two rules as I could not get the exact format I wanted. I thought > this was worth it as it saved me writing my own tool to do the job. I then > used a docker script to run the checks on every PR. > > Just wondering if it would save some effort. > > Regards, > Mark > ------------------------------------------- > Mark Stevens > Blog: blog.mark-stevens.co.uk > > > > On 17 Mar 2025, at 11:31, Luchian Mihai <luchiann.mi...@gmail.com> > wrote: > > > > Hello Nuttx, > > > > *--- Summary ---* > > I've been in the habit of fixing small issues regarding nxstyle. > > > > One of the last conclusions drawn was that it does not tokenize the file, > > which leads to limitations in checking syntax. > > Please check https://github.com/apache/nuttx/pull/15847 for further > details. > > > > I am working on a new implementation of nxstyle using python and > > tree-sitter for parsing and checking the source code. > > Treesitter is getting more traction in the past years. Some editors are > > making use of treesitter, such as zed, neovim, helix, and others. > > GitHub uses if for code navigation > > > https://docs.github.com/en/repositories/working-with-files/using-files/navigating-code-on-github > > So, I think it may be a suitable solution for nuttx as well. > > > > This will take a lot of work, but you can track my progress at > > https://github.com/LuchianMihai/nuttx/tree/nxtool. > > Please feel free to add any suggestions you may see fit. > > > > *--- Questions ---* > > > > 1. > > I've also set up the work for an new tool, calling it nxtool (at the > time I > > did not know that is not a new name/concept), > > Mostly, it's a "boilerplate" to add more subcommands under a common > command > > called nxtool. > > Currently only a single subcommand is present, checkpatch, equivalent to > > the present checkpatch.sh so basically call > > *nxtool checkpatch file* > > Now I've dug the mailing archive and found that nxtool, or similar > projects > > were proposed in the past, such as > > https://gitlab.com/nuttx-upm/upm or > > https://gitlab.com/nuttx_projects/nuttx_workspace_manager > > But both of them seem abandoned or not actively worked on. > > I feel like I'm missing some info regarding the work I'm doing. > > Why did the work stop, what was the issue with them? > > I saw mentions of zephyr meta-tool west, and they weren't bad, or against > > tools alike. > > > > So my question basically is, what is the take of the nuttx community > python > > based meta-tool? > > > > 2. > > Although I've already started investing time in this, I'm not sure how > much > > effort the nuttx community is willing to invest for enforcing > > this custom coding style in favor of using clang-format and gnu style. > > If I'm to add a new tool for enforcing nuttx coding style, I'd like to > know > > that there is no talk about deprecating this work. > > > > *--- Cosing words ---* > > > > As mentioned previously, please reply with any proposals, ideas, thoughts > > you have for such a tool, if any, > > or any counter arguments you may have. > >
