h44z/uibk_703807-Advanced-CXX
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Assignment 1: Fix typos + punctuation

Browse Source
This commit is contained in:
Alex Hirsch 2020-11-26 14:16:56 +01:00
parent b661fea4a7
commit 40fb2db8a4
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
assignment1/feedback.md
View File

@ -53,14 +53,14 @@
- This allows getters to be named without the `get` prefix (e.g. `Vec3 position() const;`). - 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 &);`). - 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`. - 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. - 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. - 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. - 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`. - Personally, I prefer `.hpp` and `.cpp`.
- Include order - Include order
@ -74,7 +74,7 @@
- Header guards - Header guards
- See [Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf8-use-include-guards-for-all-h-files) - 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). - A header guard should span the *entire* file (maybe except the license header).
- `-Werror` - `-Werror`
@ -86,44 +86,44 @@
- Unused parameters - Unused parameters
- In C++ just omit the name; no more warning. - 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. - Do not prefix symbols with the project name as you'd do in C.
- Prefer at least one top-level namespace (e.g. `lit`). - 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). - Do not hesitate adding sub-namespaces (`detail` is rather common for in-file utility functions).
- Namespaces commonly model the directory structure of a project. - Namespaces commonly model the directory structure of a project.
- Avoid `using namespace` inside header files - Avoid `using namespace` inside header files.
- Already talked about this on stream. - I've already talked about this on stream.
- Personally, I avoid `using namespace` inside headers. - Personally, I avoid `using namespace` inside headers.
- Be considerate. - Be considerate.
- Keep namespace aliases inside your namespace. - Keep namespace aliases inside your namespace.
- `namespace fs = std::filesystem;` is fine in a header, but not in global scope. - `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. - A library function should never terminate the whole application.
- Throw a custom error indicating failure, or resort to `std::runtime_error`. - 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. - Input / output should always be done via function arguments / return value.
- Use some configurable logging mechanism. - 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 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). - `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. - Do not use preprocessor defines as alternatives to enums.
- Modern compilers emit debug symbols and warnings for enums, but not for preprocessor defines. - Modern compilers emit debug symbols and warnings for enums, but not for preprocessor defines.
- Avoid `std::endl` - Avoid `std::endl`.
- Just prefer `\n`. - Just prefer `\n`.
- `std::endl` also flushes the stream which can cause performance issues. - `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`) - 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"`. - With `std::string` you can just write `myString == "foo"`.
- Only use low-level functions directly when encountering performance issues. - Only use low-level functions directly when encountering performance issues.
- Consider `std::string_view` - Consider `std::string_view`.
- This can prevent unnecessary conversion to `std::string` from C strings. - This can prevent unnecessary conversions to `std::string` from C strings.
- Take `std::string_view` by value. - Take `std::string_view` by value.
- Only use `std::string_view` as function argument. - Only use `std::string_view` as function argument.
- String may *not* be null-terminated! - String may *not* be null-terminated!
@ -133,9 +133,9 @@
- These may differ between compiler and versions; therefore, do not use them. - 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*. - 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. - 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. - Do not pollute your source files with build artifacts.
- Out-of-source builds allow you to have different build configurations side-by-side. - 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`). - Build folders should not be tracked by your version control system (use `.gitignore`).