CurtHagenlocher opened a new pull request, #417:
URL: https://github.com/apache/arrow-dotnet/pull/417
### Rationale for this change
The repository was split roughly in half on byte order mark usage — 272 of
539 `.cs` files carried a UTF-8 BOM. Editors and tools that save without one
silently strip it, which shows up as spurious first-line changes in otherwise
unrelated pull requests. #406 is a recent example: five of its six files had a
BOM removed from line 1, unrelated to the change itself.
Nothing enforced either convention, so the churn could go in both directions
indefinitely.
### What changes are included in this PR?
Two commits.
**1. Strip the BOM** from all tracked `.cs`, `.csproj`, and `.json` files
(275 files). Every change is exactly one line, at line 1, differing only by the
removed `EF BB BF` bytes — verified with `git diff --numstat` (all `1/1`) and
by confirming every removed line matches its added line once the BOM is dropped.
`examples/Examples.sln` and `src/Apache.Arrow/Properties/Resources.resx` are
deliberately left alone, since Visual Studio rewrites both with a BOM and
stripping them would just churn back.
**2. Enforce it** so this does not drift again:
- `charset = utf-8` under `[*.cs]` in `.editorconfig`. The existing `format`
pre-commit hook runs `dotnet format`, which honors `charset`, so this is
enforced by the `Lint` CI job as-is. (`*.{csproj,props,targets}` already
declared this; two `.csproj` files were quietly in violation.)
- The upstream `fix-byte-order-marker` hook, to cover what `dotnet format`
cannot see: files outside the solution such as `launchSettings.json`, and
anything under the `src/Apache.Arrow/Flatbuf/FlatBuffers/` directory that the
`format` hook excludes.
Contributors who run `pre-commit install` get the check locally as well.
### Are these changes tested?
Yes.
- `dotnet build Apache.Arrow.sln -c Release` succeeds with 0 warnings and 0
errors. 38 `.cs` files already lacked a BOM while containing non-ASCII bytes
before this PR, so Roslyn's UTF-8 default was already being exercised; removing
the remaining BOMs does not change how any file decodes.
- `dotnet format --verify-no-changes` exits 0 on the resulting tree, and
exits 2 with `error CHARSET: Fix file encoding.` when a BOM is reintroduced.
- `fix-byte-order-marker` passes on the resulting tree, and fails when a BOM
is reintroduced into `launchSettings.json` or `FlatBufferBuilder.cs` — the two
blind spots `dotnet format` misses. The two excluded files keep their BOMs.
### Are there any user-facing changes?
No. This is an encoding-only change to source files; no API, behavior, or
build output is affected.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
