From 40fb2db8a4ca60811c07d70ad8c049bd5446409a Mon Sep 17 00:00:00 2001 From: Alex Hirsch Date: Thu, 26 Nov 2020 14:16:56 +0100 Subject: [PATCH] Assignment 1: Fix typos + punctuation --- assignment1/feedback.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/assignment1/feedback.md b/assignment1/feedback.md index 08b002a..563bf51 100644 --- a/assignment1/feedback.md +++ b/assignment1/feedback.md @@ -53,14 +53,14 @@ - This allows getters to be named without the `get` prefix (e.g. `Vec3 position() const;`). - Setters get prefixed with `set` (e.g. `void setPosition(const Vec3 &);`). -- Leverage RAII +- Leverage RAII! - No need for `.close()` or alike with classes like `std::ifstream`. - Consider wrapping non-RAII objects with dedicated classes or `std::unique_ptr` with a custom deleter. -- Do not use `.h` for C++ header files +- Do not use `.h` for C++ header files. - C++ header files typically cannot be used by C projects, this should be highlighted by the file extension. - Only use `.h` if that header is meant to be used in C projects. - - I am aware of [the corresponding core guideline](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf1-use-a-cpp-suffix-for-code-files-and-h-for-interface-files-if-your-project-doesnt-already-follow-another-convention) + - I am aware of [the corresponding core guideline](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf1-use-a-cpp-suffix-for-code-files-and-h-for-interface-files-if-your-project-doesnt-already-follow-another-convention). - Personally, I prefer `.hpp` and `.cpp`. - Include order @@ -74,7 +74,7 @@ - Header guards - See [Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf8-use-include-guards-for-all-h-files) - - Personally, I am okay with `#pragma once` but the argument of *not being standard confirm* stands. + - Personally, I am okay with `#pragma once` but the argument of *not being standard conform* stands. - A header guard should span the *entire* file (maybe except the license header). - `-Werror` @@ -86,44 +86,44 @@ - Unused parameters - In C++ just omit the name; no more warning. -- Use namespaces +- Use namespaces! - Do not prefix symbols with the project name as you'd do in C. - Prefer at least one top-level namespace (e.g. `lit`). - Do not hesitate adding sub-namespaces (`detail` is rather common for in-file utility functions). - Namespaces commonly model the directory structure of a project. -- Avoid `using namespace` inside header files - - Already talked about this on stream. +- Avoid `using namespace` inside header files. + - I've already talked about this on stream. - Personally, I avoid `using namespace` inside headers. - Be considerate. - Keep namespace aliases inside your namespace. - `namespace fs = std::filesystem;` is fine in a header, but not in global scope. -- Exceptions as error reporting for library functions +- Use exceptions as error reporting for library functions. - A library function should never terminate the whole application. - Throw a custom error indicating failure, or resort to `std::runtime_error`. -- Libraries should not directly use `stdin` / `stdout` / `stderr` +- Libraries should not directly use `stdin` / `stdout` / `stderr`. - Input / output should always be done via function arguments / return value. - Use some configurable logging mechanism. -- Use `enum class` over `enum`, over preprocessor define +- Use `enum class` over `enum`, over preprocessor define. - `enum class` gets type-checked and is therefore preferred. - `enum` is still valid as it allows you to combine multiple members out-of-the-box (flag enum). - Do not use preprocessor defines as alternatives to enums. - Modern compilers emit debug symbols and warnings for enums, but not for preprocessor defines. -- Avoid `std::endl` +- Avoid `std::endl`. - Just prefer `\n`. - `std::endl` also flushes the stream which can cause performance issues. -- Avoid low-level functions like `strcmp` +- Avoid low-level functions like `strcmp`. - Usually it's better to convert your data to *better typed* C++ objects (e.g. `std::string`) - With `std::string` you can just write `myString == "foo"`. - Only use low-level functions directly when encountering performance issues. -- Consider `std::string_view` - - This can prevent unnecessary conversion to `std::string` from C strings. +- Consider `std::string_view`. + - This can prevent unnecessary conversions to `std::string` from C strings. - Take `std::string_view` by value. - Only use `std::string_view` as function argument. - String may *not* be null-terminated! @@ -133,9 +133,9 @@ - These may differ between compiler and versions; therefore, do not use them. - Symbols with a single underscore as prefix are to be viewed as *private* or *internal*. - Do not use this pattern yourself, it's often unnecessary. - - Putting stuff into a `detail` or `anonymous` namespace is the way to go. + - Putting stuff into a `detail` or anonymous namespace is the way to go. -- Use Out-of-source builds +- Use Out-of-source builds! - Do not pollute your source files with build artifacts. - Out-of-source builds allow you to have different build configurations side-by-side. - Build folders should not be tracked by your version control system (use `.gitignore`).