<h3class="anchor anchorWithStickyNavbar_LWe7"id="windows">Windows<ahref="#windows"class="hash-link"aria-label="Direct link to Windows"title="Direct link to Windows"></a></h3>
<p>Most likely WSL, VM or VPS. If you consider setting up either of those PITA, then
VSCode + SSH to <em>aisa</em> might be the best option for you.</p>
<divclass="theme-admonition theme-admonition-caution admonition_xJq3 alert alert--warning"><divclass="admonitionHeading_Gvgb"><spanclass="admonitionIcon_Rf37"><svgviewBox="0 0 16 16"><pathfill-rule="evenodd"d="M8.893 1.5c-.183-.31-.52-.5-.887-.5s-.703.19-.886.5L.138 13.499a.98.98 0 0 0 0 1.001c.193.31.53.501.886.501h13.964c.367 0 .704-.19.877-.5a1.03 1.03 0 0 0 .01-1.002L8.893 1.5zm.133 11.497H6.987v-2.003h2.039v2.003zm0-3.004H6.987V5.987h2.039v4.006z"></path></svg></span>VSCode @ aisa</div><divclass="admonitionContent_BuS1"><p>Be careful when using VSCode on aisa, most notably:</p><ol>
<li>VSCode can leave lingering processes running in the background that can „eat
up“ your quota for running processes.
AFAIK UNIX team has implemented some periodic clean up of those.</li>
<li>Disk quota can be also affected, because of the C/C++ extension toolkit that
has a cache for IntelliSense.</li>
</ol></div></div>
<p>Either of those will be linux distros, so jump to <ahref="#linux">next section</a>.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="linux">Linux<ahref="#linux"class="hash-link"aria-label="Direct link to Linux"title="Direct link to Linux"></a></h3>
<p>Majority (if not all) of the provided materials include makefile (contains absolute
path, so in case of linting and compiling, you need to adjust to your needs). You
basically need following list of tools:</p>
<ul>
<li><code>gcc</code> - for compiling</li>
<li><code>clang-tidy</code> - for linting (depends on distribution, might be provided with
clang itself or in separate package, e.g. <code>clang-tools-extra</code>)</li>
<li><code>clang-format</code> - for your own sanity of keeping consistent formatting</li>
<li><code>make</code> - since you are provided makefiles and it might be quickest to set up</li>
<li><code>valgrind</code> - in case you manage to create memory errors in your code</li>
</ul>
<p>In case of Fedora it is following set of packages:</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="macos">macOS<ahref="#macos"class="hash-link"aria-label="Direct link to macOS"title="Direct link to macOS"></a></h3>
<p>In case of macOS you should be able to find all of the packages in brew.sh, except
<code>valgrind</code>, not sure if you can solve with podman/docker.</p>
<p>There is also an alterantive to homebrew, that is nixpkgs.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="nixos">nix(OS)<ahref="#nixos"class="hash-link"aria-label="Direct link to nix(OS)"title="Direct link to nix(OS)"></a></h3>
<p>In case you run nixOS or linux distribution with nixpkgs or you use nixpkgs as a
replacement for homebrew on macOS. You should be fine with the following config:</p>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="ides">IDEs<ahref="#ides"class="hash-link"aria-label="Direct link to IDEs"title="Direct link to IDEs"></a></h2>
<p>Choice of the IDE is mostly up to you, you do not need to use IDE at all ;)</p>
<p>I would probably recommend VSCode + appropriate extension or CLion if you are used
to the JetBrains IDEs.</p>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="git">git<ahref="#git"class="hash-link"aria-label="Direct link to git"title="Direct link to git"></a></h2>
<p>I recommend you using some basic versioning for your code, even though you submit
only the sources on <em>aisa</em>. There are specific reasons why I suggest it:</p>
<ul>
<li>if you build a <em>commit, tag and submit</em> habit, you might be able to address
some of the smaller problems in your sources even before submission; more info
in the <ahref="#pre-commit">pre-commit section</a></li>
</ul>
<p>In case you are planning to use git branches for separating different
assignments and/or merge requests I suggest you to keep specifications and
skeletons on your default branch, since <em>frag</em> on <em>aisa</em> automatically downloads
everything that is not present and by that can create conflicts when switching
correctness of your implementation and also identify bugs, since they are better
contained.</p></div></div>
<p>Since frag creates a lot of support files (majority of them are dotfiles, i.e.
hidden files), I recommend you to use following
<ahref="/files/cpp/environment/gitignore"target="_blank"rel="noopener noreferrer">gitignore</a> configuration that
should cover most of the scenarios.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="pre-commit-link">pre-commit (<ahref="https://pre-commit.com/"target="_blank"rel="noopener noreferrer">link</a>)<ahref="#pre-commit-link"class="hash-link"aria-label="Direct link to pre-commit-link"title="Direct link to pre-commit-link"></a></h3>
<p>Pre-commit basically allows you to "check" your code before committing. It functions
as a git hook, i.e. you want to make a commit, pre-commit checks it before-hand.</p>
<p>In case of C++ there are few use-cases:</p>
<ul>
<li>
<p>formatting</p>
</li>
<li>
<p>linting</p>
</li>
<li>
<p>building and/or running tests, in case you feel like masochist</p>
<p>However this might be a challenging task to implement, since most of the tasks
are published from the beginning.</p>
</li>
</ul>
<p>In case of formatting and linting, there are already existing hooks (there is a
list of supported ones on the page), but there is also an option for you setting
it up yourself (it is just a matter of specifying command and files it should run
on).</p>
<divclass="theme-admonition theme-admonition-tip admonition_xJq3 alert alert--success"><divclass="admonitionHeading_Gvgb"><spanclass="admonitionIcon_Rf37"><svgviewBox="0 0 12 16"><pathfill-rule="evenodd"d="M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"></path></svg></span>Formatting</div><divclass="admonitionContent_BuS1"><p>For formatting you can the following <ahref="https://github.com/pre-commit/mirrors-clang-format#using-clang-format-with-pre-commit"target="_blank"rel="noopener noreferrer">git hook</a>.</p><p>This hook follows the formatting conventions defined by the <code>.clang-format</code> file
that is looked up recursively all the way to the root of the filesystem, therefore
it is ideal to keep it in the root of the git repository.</p><p>You can look up the different codestyles <ahref="https://gitlab.fi.muni.cz/pb071/codestyles"target="_blank"rel="noopener noreferrer">here</a>.</p></div></div>
<h2class="anchor anchorWithStickyNavbar_LWe7"id="testing">Testing<ahref="#testing"class="hash-link"aria-label="Direct link to Testing"title="Direct link to Testing"></a></h2>
<p>I have tried 2 frameworks for testing, one of them will be probably showcased in
lectures. If you have not picked one yet, you can take an inspiration from the
following.</p>
<h3class="anchor anchorWithStickyNavbar_LWe7"id="catch2">catch2<ahref="#catch2"class="hash-link"aria-label="Direct link to catch2"title="Direct link to catch2"></a></h3>
<p>It is quite popular, only one header-file, also might be easier to set up.</p>
<p>Might feel slow to compile, this can be addressed by having one object file with
<h3class="anchor anchorWithStickyNavbar_LWe7"id="google-test">Google Test<ahref="#google-test"class="hash-link"aria-label="Direct link to Google Test"title="Direct link to Google Test"></a></h3>
<p>It is faster compared to catch2, even if you do not precompile the <code>main</code>. Might
be more complicated to set up, since there are multiple files (it is not one header
file). Not very user friendly on <em>aisa</em>. However can be installed through package
