search

beman-project / exemplar

Example Beman project
Other
6 stars 12 forks source link

Define `.clang-format` or equivalent #29

Open wusatosi opened 3 days ago

wusatosi commented 3 days ago

.clang-format file defines the formatting rule for cpp files and allow modern tool chain to lint & auto-format

This file has already been defined for Optional26 and net29 (note: those files are equivalent in terms of content).

camio commented 3 days ago

This is a good idea.

wusatosi commented 3 days ago

This is a good idea.

I am interested in setting up clang-format linters and auto formatting prs, I cannot move forward without a .clang-format file. Should I just pull the .clang-format config from those two projects for now and leave this issue open?

neatudarius commented 2 days ago

This is a good idea.

I am interested in setting up clang-format linters and auto formatting prs, I cannot move forward without a .clang-format file. Should I just pull the .clang-format config from those two projects for now and leave this issue open?

Yes, pleae pull the one from optional26 repo. I think @steve-downey revised that file in https://github.com/beman-project/optional26/pull/52 and it's up to date. Please check his PR and see what logic can be reused. I think optional26 may be ahead of other repos in Beman project, so I would like to get what is good there, and put in exemplar.

wusatosi commented 2 days ago

This is a good idea.

I am interested in setting up clang-format linters and auto formatting prs, I cannot move forward without a .clang-format file. Should I just pull the .clang-format config from those two projects for now and leave this issue open?

Yes, pleae pull the one from optional26 repo. I think @steve-downey revised that file in beman-project/optional26#52 and it's up to date. Please check his PR and see what logic can be reused. I think optional26 may be ahead of other repos in Beman project, so I would like to get what is good there, and put in exemplar.

The update to .clang-format you mentioned in the pr apply to formatting the paper, link to change . I presume you mean pull the .clang-format from the root directory? (File: link, last updated one year ago on this commit?

neatudarius commented 2 days ago

This is a good idea.

I am interested in setting up clang-format linters and auto formatting prs, I cannot move forward without a .clang-format file. Should I just pull the .clang-format config from those two projects for now and leave this issue open?

Yes, pleae pull the one from optional26 repo. I think @steve-downey revised that file in beman-project/optional26#52 and it's up to date. Please check his PR and see what logic can be reused. I think optional26 may be ahead of other repos in Beman project, so I would like to get what is good there, and put in exemplar.

The update to .clang-format you mentioned in the pr apply to formatting the paper, link to change . I presume you mean pull the .clang-format from the root directory? (File: link, last updated one year ago on this commit?

ooohh, I had the impresion the .clang-format file from root directory (main) was also updated. @steve-downey , what you would adivice here? TLDR: we need .clang-format file up to date to be promoted in exemplar repo (and then in all repos in Beman).

camio commented 2 days ago

The .clang-format used in optional26 looks very hand crafted. I think we should use this .clang-format as I mentioned here.

steve-downey commented 2 days ago

The LLVM style is terribly idiosyncratic and only easy to get at because clang-format is an LLVM project.

The one in Optional26 closely matches the format used in the Standard.

camio commented 1 day ago

The LLVM style is terribly idiosyncratic

IMO the same can be said about any style, which is why the engineering argument is compelling: the LLVM style is the best supported. I don't think actively maintaining a .clang-format that looks like the standard is where our time should be spent (See [CORE.INDUSTRY_STANDARD]). That being said, my opinion is for only beman.exemplar; other Beman projects should be free to choose different styles.

neatudarius commented 1 day ago

The LLVM style is terribly idiosyncratic

IMO the same can be said about any style, which is why the engineering argument is compelling: the LLVM style is the best supported. I don't think actively maintaining a .clang-format that looks like the standard is where our time should be spent (See [CORE.INDUSTRY_STANDARD]). That being said, my opinion is for only beman.exemplar; other Beman projects should be free to choose different styles.

I would really want to have the same .clang-format file in all repos. My wish would be to move such tooling (linting, CI support etc), as much as possible, into a new repo / git submodule, and be able to reuse everywhere in Beman!

My preference would be to use a default config - e.g., LLVM style - and have fewer entrie/exceptions in the file.

I will add this topic on next sync agenda.

wusatosi commented 17 hours ago

The LLVM style is terribly idiosyncratic

IMO the same can be said about any style, which is why the engineering argument is compelling: the LLVM style is the best supported. I don't think actively maintaining a .clang-format that looks like the standard is where our time should be spent (See [CORE.INDUSTRY_STANDARD]). That being said, my opinion is for only beman.exemplar; other Beman projects should be free to choose different styles.

I would really want to have the same .clang-format file in all repos. My wish would be to move such tooling (linting, CI support etc), as much as possible, into a new repo / git submodule, and be able to reuse everywhere in Beman!

My preference would be to use a default config - e.g., LLVM style - and have fewer entrie/exceptions in the file.

I will add this topic on next sync agenda.

This doesn't sound that much like a good idea?

  1. Lint files could get bloated up easily for special cases after special cases or custom config.
  2. Tweaking small sections of lint files for specific projects do sometimes make sense.
  3. As long as the default format is sane, it is fine for formatting to be behind the standard.
  4. Updating formatting files sometimes require mass refactoring, which makes merging/ git blame a pain and would be best to keep in minimal, syncing format files across multiple projects increase the chance of this happening.

But definitely a good subject to chat at next sync!

wusatosi commented 17 hours ago

Hey I just made a pr #34, with the cpp code in this project formatted against the standard from optional/ net repo. Take a look and comment if we need to change anything.