遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/5365)
<a href="https://www.bestpractices.dev/projects/5365"><img src="https://www.bestpractices.dev/projects/5365/badge"></a>
A multi-system emulator project with a .NET front-end. Features recording/playback and debugging tools for TASers, plus some QoL stuff for casual players. Built for Windows 10+ and Linux x86_64.
Coding conventions are briefly mentioned in the contributor's guide.
Our template for Pull Requests includes a primitive CLA: contributors declare they are able and willing to transfer the copyright for their contribution to us.
Bus factor for managing the repo and contributions is at least 2 (via GitHub org owners).
Bus factor for emulation work is definitely 1; we've run into that case (thankfully not because of a bus, drama explained here).
We only have the issue tracker and individual devs' microblogging.
While the readme matches the latest release, other fragmented documentation does not.
Various badges are shown at the top of the readme on GitHub, and on GitLab.
Our GUI framework, WinForms, gives us some a11y support on Windows. At least one user has had success with a screen reader.
Not even close.
Repo / issue tracker are hosted on GitHub. CI management is hosted on AppVeyor/GitLab. Some external documentation is hosted on TASVideos.org but is available without login.
Config from older releases is not importable. Movies aren't really importable either, but that's not feasible. Lua/ApiHawk deprecations are well-documented.
issue tracker on GitHub
no reports
The indentation and brace styles are specified explicitly, and some other smaller points are specified by static analysis rules. These are still in flux as of 2024-01.
Those code style rules which have been specified in the config are enforced by CI, or in local builds with an extra flag.
Build output is a Portable Executable (CIL bytecode).
Build with dotnet -c Debug.
dotnet -c Debug
MSBuild doesn't do this.
The Nix expression is fully reproducible. MSBuild on its own is very close.
Executable is "portable", reading and writing files in the directory it's extracted to (for the most part).
Manually installed. On Linux, installed from AUR, or "installed" with Nix.
Devs on Linux can get a perfect, ephemeral copy of the build tools using Nix; this includes the unit tests but, due to a bug, they only work in the Nix sandbox (slower). Devs on Windows are vaguely told to use the Visual Studio installer. Devs working on C++ or Rust subprojects are expected to get the extra toolchain(s) themselves at the moment.
Third-party assemblies are either downloaded from NuGet, managed centrally here, or checked-in. In either case all .NET assembly references are listed in MSBuild project files like this one in the standard format. "Unmanaged" dependencies can be found by grepping for one of 2 P/Invoke attributes (since only some are Git submodules, the rest checked-in).
.NET packages on NuGet are checked at compile-time and also periodically by GitHub's dependabot. Checked-in .NET assemblies are not, nor are "unmanaged" dependencies.
The remaining checked-in assemblies are those which could not easily be correlated to a NuGet package.
While technically still supported, EmuHawk is a WinForms app targeting .NET Framework, which has been superceded by .NET Core.
GitLab CI always runs test suite.
Not feasible to test GUI.
See above.
Warning categories that aren't muted are mostly treated as errors, including by CI.
警告:需要更长的理由。
One of the Analyzers includes some checks for common security pitfalls.
See also Real-Time Corruptor project.
后退