From 85b73a558871d591347bc3a2960df15f72d50eb0 Mon Sep 17 00:00:00 2001 From: MrMijagi Date: Sat, 29 Aug 2020 12:54:14 +0200 Subject: [PATCH 1/3] module1 automatically translated --- module1/01_teamwork.en.md | 122 ++++++ ...entation_teamwork.md => 01_teamwork.pl.md} | 0 module1/02_conventions.en.md | 398 ++++++++++++++++++ ...on_conventions.md => 02_conventions.pl.md} | 0 module1/03_principles.en.md | 289 +++++++++++++ ...tion_principles.md => 03_principles.pl.md} | 0 module1/04_practices.en.md | 269 ++++++++++++ ...tation_practices.md => 04_practices.pl.md} | 0 module1/05_homework.en.md | 41 ++ ...entation_homework.md => 05_homework.pl.md} | 0 module1/index.en.html | 121 ++++++ module1/{index.html => index.pl.html} | 10 +- 12 files changed, 1245 insertions(+), 5 deletions(-) create mode 100644 module1/01_teamwork.en.md rename module1/{presentation_teamwork.md => 01_teamwork.pl.md} (100%) create mode 100644 module1/02_conventions.en.md rename module1/{presentation_conventions.md => 02_conventions.pl.md} (100%) create mode 100644 module1/03_principles.en.md rename module1/{presentation_principles.md => 03_principles.pl.md} (100%) create mode 100644 module1/04_practices.en.md rename module1/{presentation_practices.md => 04_practices.pl.md} (100%) create mode 100644 module1/05_homework.en.md rename module1/{presentation_homework.md => 05_homework.pl.md} (100%) create mode 100644 module1/index.en.html rename module1/{index.html => index.pl.html} (93%) diff --git a/module1/01_teamwork.en.md b/module1/01_teamwork.en.md new file mode 100644 index 0000000..c0cbd6d --- /dev/null +++ b/module1/01_teamwork.en.md @@ -0,0 +1,122 @@ + + +# Group collaboration + + + Coders School + + +___ + +## Philosophical questions + +### a.k.a. joint retro + +* How did you feel while working together? +* Were there problems that you did not foresee at the beginning? +* Was the estimated time of the tasks consistent with reality? +* What went wrong? +* What worked fine and you could suggest implementing this to other groups? + +___ + +## Unexpected problems + +The fact that we threw you a little into this project and forced you to self-organize was a deliberate procedure. + + +We wanted to show you how many things are not taken into account at the beginning before starting the project. + + +And even with several years of experience in project management, some things cannot be avoided. + + +* sickness of team members +* unexpected departures +* additional, unplanned tasks +* wrongly estimated task time +* technical problems (computer restarting, git - conflicts, interrupting the internet) +* changing requirements or their interpretations + +___ + +## Task estimation + +The theory suggests that a fairly cool way to better estimate tasks is to multiply the initial estimate by PI 😄 + + +Other sources indicate that an order of magnitude should be increased (e.g. from 5 hours to 5 days, from 3 days to 3 weeks, etc.) 😄 + + +In practice, poker is used for estimation + + +## 🃏 + +___ + +## Scrum poker + +### Rules + +* We do not estimate tasks in units of time. +* We choose one task for the whole team that is the easiest of all. We give it the value of 1. +* We only use the values ​​from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ♾,? - I have no idea, ☕️). Thanks to this, we focus more on orders of magnitude than on the units themselves, because there is no big difference between 9 and 10. +* The unit is Story Points (SP). This is a completely abstract measure. You can think of it as any other abstract. For example, this task is valued at 5 chestnuts. This information is completely useless, but it allows you to compare tasks. Since that is worth 8, it is more valuable (more difficult). +* For one person, 1 SP may mean 1 hour of work, and for another - 1 day. + +___ + +### The course of the estimation + +* We discuss one selected task with the whole team to make sure that everyone understands it the same. +* When everyone is ready they _simultaneously_ draw the card with their estimate so as not to be influenced by others +* If the discrepancy is large, it means that team members have a different understanding of the task and still need to be discussed. It is worth asking people with the lowest and highest estimate why they give so much. +* If the discrepancies are small, you can average them or agree to some value (usually higher) + +Look for online Scrum Poker tools and use them to estimate tasks in Planning. + + +___ + +## Collective responsibility + +It's hard to blame someone for getting sick. But you can blame him for committing to something and not letting him know that it won't work. So it's important daily to get in the habit of updating your status at least daily. Of course you can more often. + + +As soon as you find out that someone from the crew is ailing you, you should think immediately what to do about it. If the works were started, what has been done so far should be communicated / communicated. This is another reason why small and frequent commits are a good practice. Everyone has access to the current version of the code and it's easy to donate work. + + +For us, outside observers, we can never judge how much each team has done. The team just did it for us. If you feel that you are doing too much / too little and something is unfair, you can write us about your problems and change the team if necessary. + + +___ + +## Good practices for team cooperation + +* Pair programming +* Mob programming +* Peer code review +* Deliver jobs as quickly as possible. Better to deliver 4 out of 8 tasks by working 2 people on each other than 0/8 having all started at the same time. +* No top-down assignments of people to tasks. The person who just has time takes the first task in advance (or one of the first, if not blocked) +* 1 person can only be assigned 1 task at a time. Only after completing the previous quest can you take another one. + +___ + +## [Agile manifesto](https://agilemanifesto.org) + +> We discover new programming methods thanks to programming practice and supporting others in it. As a result of our work, we began to value more: +> +> **People and interactions** from processes and tools +> +> **Working software** from detailed documentation +> +> **Cooperation with the client** from negotiating contracts +> +> **Responding to changes** from the implementation of the assumed plan. +> +> This means that the items on the right are valuable, but the ones on the left are more valuable to us. + +___ + +## Q&A diff --git a/module1/presentation_teamwork.md b/module1/01_teamwork.pl.md similarity index 100% rename from module1/presentation_teamwork.md rename to module1/01_teamwork.pl.md diff --git a/module1/02_conventions.en.md b/module1/02_conventions.en.md new file mode 100644 index 0000000..93cd8e2 --- /dev/null +++ b/module1/02_conventions.en.md @@ -0,0 +1,398 @@ + + +# Conventions + + + Coders School + + +___ + +## Line length + +Max 120 characters + + +## Length of the function + +Up to 10 lines (+/- 5). + + +If there is more then you need to separate the functionalities into smaller functions. + + +___ + + +## Each block (scope) = indent + +Any range that begins with parentheses `{` - even if it is not present, e.g. for one-line ones `if`, `for` - must have an additional level of indentation. + +```cpp +int addEven(const std::vector& numbers) +{ + int sum{}; + for (const auto& el: numbers) + { + if(el % 2 == 0) + sum = sum + el; // bad, no additional indentation + } + return sum; + } + ``` + + ```cpp +int addEven(const std::vector& numbers) +{ + int sum{}; + for (const auto& el: numbers) + { + if(el % 2 == 0) + { + sum = sum + el; // indentation ok, braces added + } + } + return sum; + } + ``` + +___ + +### Exceptions - `switch/case` + +Often with instructions `switch/case` you will meet with that `case` is on the same level as `switch`. We do not consider this a mistake. + +```cpp +switch (value) { +case 1: doSth(); + break; +default: doSthElse(); +} +``` + +___ + +### Exceptions cont. + +* `namespace` +* access modifiers `public`, `protected`, `private` + +```cpp +namespace shm { + +class Ship { +public: + Ship() = default; + // ... + +private: + size_t maxCrew; + // ... +} + +} // namespace shm +``` + +___ + +## Types of naming conventions + +* lowerCamelCase +* UpperCamelCase (PascalCase) +* snake_case (Python convention) +* kebab-case (rare in C ++, often in the front-end) + +___ + +## Hungarian notation - bad practice + +In Hungarian notation, type information is contained in the variable name. [Read on the Wiki and never apply](https://pl.wikipedia.org/wiki/Notacja_węgierska) + +* ~~`iNumber`~~ +* ~~`szName`~~ +* ~~`lpcszText`~~ + +___ + +## Conventions for class fields + +* postfix _underscore_ `_` behind the name +* prefix `m_` before the name + +Prefixes cannot be used `_`. Any name starting with _underscore_ is reserved for the compiler. + +[stackoverflow.com](https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier) + +___ + +## Variable names with prefixes - rather bad practice + +* local variable l_variable +* function parameter p_variable +* class field m_variable +* global variables g_variable +* static variables s_variable + +This may seem cool, but it unnecessarily adds 2 characters to the variable name. Instead, it's better to use what's on the next slide. + + +___ + +## Avoiding prefixes + +Note, these are my opinions based on my experience. + +* local variable: variable + * Functions / code blocks should be small (up to 10 lines). Then we easily find local variables a few lines higher +* function parameter: variable + * For small functions, the parameters are also found a few lines higher without scrolling +* class field: variable_ + * The class variables sit in the header file and we would have to switch to a different file to make sure it's a class field. The convention here is postfix `_` +* global variables: VARIABLE + * Uppercase variables / constants are global. There are arguments for not doing this either, but I don't remember them. +* static variables: s_variable + * Prefix here `s_` can stay, because other ways are already taken :) + +___ + +## What to name? + +All this is a matter of convention and may differ from project to project. The most important thing is that it is uniform throughout the project. +We make the following assumptions. + +___ + +### Classes and structures + +* UpperCamelCase +* noun + adjectives (optional) + +```cpp +class SuperWarrior {}; // ok +class listenMusic {}; // bad, verb instead of noun. Maybe MusicPlayer? +``` + +___ + +### Variables + +* lowerCamelCase +* noun (s) + adjectives (optional) + +```cpp +SuperWarrior mightyBarbarian; // ok +int clickCounter; // ok +``` + +___ + +### Functions + +* lowerCamelCase +* verb + adverbs or nouns (optional) + +```cpp +void generateStructure(); // ok +int calculateCommonSum(); // ok +``` + +___ + +### Class fields + +* as normal variables +* additionally after the name _underscore_ `_` + +```cpp +class SuperWarrior +{ + int level_ = 1; + int strength_ = 50; + int dexterity_ = 10; + int mana_ = 0; +}; +``` + +___ + +### Filenames + +* file name = class name +* UpperCamelCase / lowerCamelCase / snake_case / kebab-case + +`class SuperWarrior` -> SuperWarrior.hpp / SuperWarrior.cpp + +___ + +## Descriptive variable names + +Let's not name variables like this: + +```cpp +int a = 0; // what is a? +bool b = false; // what is b? + +bool compare(int a, int b); // what does a and b represent? +``` + +If you look at this code after a month, you won't know what it does either. This is much better: + + +```cpp +int counter = 0; +bool isValid = false; + +bool compare(int lhs, int rhs); +``` + +___ + +### Allowed short names + +* `i`, `j` - as indices in loops +* `it` - as an abbreviation of `iterator` +* `el`, `elem` - as an abbreviation of `element` in collection loops +* `lhs`, `rhs` - as an abbreviation of `leftHandSide` and `rightHandSide` in comparer functions + +___ + +## Types of parentheses + +### Egyptian (K&R, Stroustrup) + + +```cpp +while (x == y) { + // do sth; +} +``` + + +### Allman + + +```cpp +while (x == y) +{ + // do sth; +} +``` + + +[See others on the wiki and never apply](https://en.wikipedia.org/wiki/Indentation_style) + + +___ + +### My favorite formatting + +Attention, this is an opinion! For features - Allman. For loops, if - Egyptian. For classes - whatever. Reason: + +```cpp +class SuperWarrior +{ +public: + SuperWarrior(int level, int strength, int dexterity) + : level_(level) + , strength_(strength) + , dexterity(dexterity) + { + if (level_ >= 10) { + mana_ = 50; + } + } + +private: + int level_ = 1; + int strength_ = 50; + int dexterity_ = 10; + int mana_ = 0; +}; +``` + +___ + +Constructor initialization lists or too long names and types of function parameters spoil the readability of the code blocks a little. + +In contrast: + +```cpp +class SuperWarrior { +public: + SuperWarrior(int level, int strength, int dexterity) + : level_(level) + , strength_(strength) + , dexterity(dexterity) { + if (level_ >= 10) { + mana_ = 50; + } + } + +private: + int level_ = 1; + int strength_ = 50; + int dexterity_ = 10; + int mana_ = 0; +}; +``` + +___ + +## Sticking `&` and `*` + +* left int& ref + * okay :) +* center int & ref + * I personally like it +* right int &ref + * avoid + +___ + +## The ternary operator `?:` + +One line is usually unreadable + + +```cpp +lhs.size() == rhs.size() ? lhs < rhs : lhs.size() < rhs.size() +``` + + +It is better to write it in two lines. + + +```cpp +lhs.size() == rhs.size() ? lhs < rhs + : lhs.size() < rhs.size() +``` + + +And sometimes even 3 if the condition is long. + + +```cpp +lhs.name == rhs.name && lhs.amount == rhs.amount && lhs.price == rhs.price + ? lhs.value < rhs.value + : lhs.price < rhs.price +``` + + +Although IMO is better to use the usual one in the last case `if`. + + +___ + +## AutoFormat + +### `clang-format` + +The project should include a file `.clang-format`which will ensure that anyone can apply the formatting it describes automatically + +```bash +clang-format -style=.clang-format -i *.cpp *.hpp +``` + +___ + +## Q&A diff --git a/module1/presentation_conventions.md b/module1/02_conventions.pl.md similarity index 100% rename from module1/presentation_conventions.md rename to module1/02_conventions.pl.md diff --git a/module1/03_principles.en.md b/module1/03_principles.en.md new file mode 100644 index 0000000..0319705 --- /dev/null +++ b/module1/03_principles.en.md @@ -0,0 +1,289 @@ + + +# Programming practices + + + Coders School + + +___ + +## Known and liked practices + +* Fail-fast +* Scout rule +* DRY +* DRTW +* KISS +* YAGNI +* RTFM +* No Tests - Don't Touch +* CQRS +* 90-90 rule +* Zen of Python + +[More on Wikipedia](https://en.wikipedia.org/wiki/Category:Programming_principles) + + +___ + +### This we will cover in Best Practice # 2 + +* SOLID +* GRASP +* STUPID + +___ + + +## Fail-fast + +Choke the program as soon as possible in case of problems. It's better than acting and crashing it over Undefined Behavior later. Good luck finding the cause in that case. + + +### Allowed things + + +* unhandled exceptions +* assertions (assert, static_assert) +* in functions, checking necessary conditions at the beginning + +```cpp +void process(std::shared_ptr value) { + if (!value) { + return; + } + // process normally +} +``` + + +### Pros + + +* minimizing UB (Undefined Behavior) +* easier debugging and finding the causes of problems + +___ + +## Scout rule - the scout rule + +> Always leave the campsite at least as you found it. + + +Same with the code as with the camping. If you get dirty in the code - you have to clean it up. Cleaning up after others is also very welcome. + + +If you touch someone's code, e.g. by just adding one line - try to improve it. + + +Cleaning is to be in a separate commite. + + +### Pros + + +* the code can only get more readable +* we are not making a technical debt that we will have to pay someday + +___ + +## DRY + +### Don't Repeat Yourself + + +Often, duplications are caused by a simple "copipasty" operation. + + +Code that is the same or similar in more than 1 place should be extracted into a function and called that function there + + +### Pros + + +* easier refactoring - change only in one place +* less room for mistakes. There is no risk that we will not change all occurrences once we discover a bug + +___ + +## DRTW + +### Don't Reinvent The Wheel + + +Do not reinvent the wheel and use ready-made libraries that provide the given functionality. + + +### Pros + + +* usually you are using already tested code +* less room for incorrect implementations - you may not come up with all test cases +* saving time + +___ + + +## KISS / BUZI + +### Keep It Simple, Stupid + + +### No Record Freaks, Idiot + + +When writing the code, we do not force the tricks and novelties that may make it more universal and easy for future development, but will reduce its readability. + + +Many seniors have a problem with this and complicate the code unnecessarily. They know from experience that this will make the code easier to modify in the future. What if it will never be modified afterwards, but still read many times? + + +We introduce each "improvement" only when there is such a need. We don't write anything "in stock". See - YAGNI. + + +### Pros + + +* easier to understand code, especially for juniors + +___ + +## YAGNI + +### You Aren't Gonna Need It + + +You won't need this. We don't write code in advance, thinking it will come in handy soon. In this way, we generate dead code that is never and probably will not be used. + + +If in the future a given functionality is needed, another person will probably implement it (even you will forget that you have already written something after a month) and will write it again. + + +### Pros + + +The less code the better: + + +* shorter compilation time +* less complicated dependencies +* less to analyze +* less to remember (that something was taken as a spare) +* faster tool use (grep or Ctrl+F have less to scan) + +___ + +## RTFM + +### Read The F * cking Manual;) + + +Before you inundate people with questions about a given functionality / tool, read the manual. + + +In Linux, for the tool `tool` use `tool --help` and `man tool`. + + +If, after reading the documentation, you still don't know what to do, then ask others (team members, stackoverflow, other forum, Discord Coders School 😉) + + +### Pros + + +* More experienced people often have a tight calendar, so they will be grateful if you find a solution on their own or briefly;) + +___ + +## No Tests - Don't Touch + +If you want to fix a piece of code but it's not tested, write some tests first. + + +If you "improve" or "correct" code that has not been tested, how do you prove that its behavior has not changed after your changes? + + +Never change the implementation and tests for it at the same time. If the tests stop passing, you won't know whether it's because of a broken implementation or broken tests. Tests test the implementation, and the implementation tests the tests. + + +### Pros + + +* saving yourself potential problems and time +* writing tests and refactoring will take less time than refactoring without tests (seriously) + +___ + +## CQRS + +### Command Query Responsibility Segregation + + +Separate write from reading. + + +* Query - getting (reading) data - getters +* Command - action on data (write) + +We should avoid methods that do both because: + + +> Asking a question should not change the answer +> +> - * Bertrand Meyer * + + +___ + +## Rule 90-90 + +You will complete 90% of the tasks within 90% of the time allocated to them. + + +The remaining 10% of the tasks will be completed in the remaining 90% of the time. + + +Useful when assessing the progress of work. + + +At first the work goes quite briskly (the general outline of the task), but it is only in the process that unthought out boundary cases are discovered, due to which the task will take longer time expected. + + +___ + + +## Zen of Python + +```python +import this +``` + + +```text +The Zen of Python, by Tim Peters + +Beautiful is better than ugly. +Explicit is better than implicit. +Simple is better than complex. +Complex is better than complicated. +Flat is better than nested. +Sparse is better than dense. +Readability counts. +Special cases aren't special enough to break the rules. +Although practicality beats purity. +Errors should never pass silently. +Unless explicitly silenced. +In the face of ambiguity, refuse the temptation to guess. +There should be one-- and preferably only one --obvious way to do it. +Although that way may not be obvious at first unless you're Dutch. +Now is better than never. +Although never is often better than *right* now. +If the implementation is hard to explain, it's a bad idea. +If the implementation is easy to explain, it may be a good idea. +Namespaces are one honking great idea -- let's do more of those! +``` + + +___ + +## Q&A diff --git a/module1/presentation_principles.md b/module1/03_principles.pl.md similarity index 100% rename from module1/presentation_principles.md rename to module1/03_principles.pl.md diff --git a/module1/04_practices.en.md b/module1/04_practices.en.md new file mode 100644 index 0000000..bc36596 --- /dev/null +++ b/module1/04_practices.en.md @@ -0,0 +1,269 @@ + + +# Good practices + + + Coders School + + +___ + +## Mystery + +Tomek got 3 apples, but he ate 2. How many apples does Tom have? + + +### Reply + + +We don't know, because we don't know how many he had before he got 3 apples. + + +### Moral + + +Always initialize variables. + + +```cpp +int a; +a += 3; +a -= 2; +std::cout << a << '\n'; +``` + + +___ + +## Always initialize variables + +```cpp +int index = 0; // ok +bool completed; // bad +bool finished = false; // ok + +if (completed) { // very bad + // ... +} + +struct Node { + Node* next = nullptr; // ok + int value = 0; +} +``` + +___ + +## Define your own types + +Code full of domain names (own types) is easier to read. Also people who do not deal with programming on a daily basis can deduce a lot from it. + + +Check out these 2 features: + + +```cpp +std::vector> compressGrayscale(std::array, height>&); +std::array, height> decompressGrayscale(std::vector>&); +``` + + +And see them now: + + +```cpp +CompressedImage compressGrayscale(const Image& bitmap); +Image decompressGrayscale(const CompressedImage& compression); +``` + + +To achieve this, it is enough to give different names to the types like this: + + +```cpp +using Image = std::array, height>; +using CompressedImage = std::vector>; +``` + + +___ + +## Forward declarations + +Use forward declarations where possible instead `#include`. + + +In order to use an object, the compiler needs information about its size. + + +```cpp +#include "Fruit.hpp" + +int main() { + Fruit apple; + // ... +} +``` + + +So in order to be able to create a local variable, I need to know its size. So it must have a proper header where this class is defined to know the size of such a variable on the stack. + + +___ + +### Mystery + +* What size is the pointer on int? +* What size is the pointer on Fruit? + +### Reply + + +The size of the pointer does not depend on the type it points to. Usually it is 4 or 8 bytes long (for 32 and 64 bit processors respectively). + + +___ + +### Object size unknown + +Each indicator and reference are of the same size. As long as we use them and do not refer to any methods or fields of the class, we do not need information about its size or content. + + +```cpp +class Fruit; // class forward declaration + +void pass(Fruit* fruit) { + if (!fruit) { + return; + } + // do sth; +} +``` + + +In that case, we just need to tell the compiler that the pointer type is our class by means of a forward declaration. You do not need to apply then `#include` and we speed up compilation. + + +___ + +However, if we refer to a field or method of this object, the compiler tells us that it has incomplete information. + +```cpp +class Fruit; + +unsigned getFruitPrice(Fruit* fruit) { + if (!fruit) { + return 0u; + } + return fruit->getPrice(); // compilation error +} +``` + + +In this case, the correct heading must be attached. + + +___ + +## We avoid implicit conversions + +```cpp +class Apple { + int weight_; +public: + Apple(int weight); // possible conversion from int to Apple +}; + +void takeApple(Apple a); + +int main() { + takeApple(150); // int converted implicitly into Apple +} +``` + + +___ + +### Avoiding Implicit Conversions + +Key word `explicit` prohibits implicit conversions. They are used with constructors that may accidentally convert from the type of argument they take. + + + +```cpp +class Apple { + int weight_; +public: + explicit Apple(int weight); +}; + +void takeApple(Apple a); + +int main() { + takeApple(150); // compilation error, expected Apple, got int +} +``` + + +___ + +## `explicit` + +Key word `explicit` we use for: + +* unary constructors + * `explicit Apple(int weight);` +* multi-argument constructors, with one non-default argument + * `explicit Apple(int weight, int size = 1);` +* conversion operators + * `explicit operator int() const { return weight_; }` + +___ + +## Reading and application [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md) + +___ + +## F: Functions + +* F.1: "Package" meaningful operations as carefully named functions +* F.2: A function should perform a single logical operation +* F.3: Keep functions short and simple +* F.4: If a function may have to be evaluated at compile time, declare it constexpr +* F.5: If a function is very small and time-critical, declare it inline +* F.6: If your function may not throw, declare it noexcept +* F.9: Unused parameters should be unnamed +* F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to const +* F.17: For "in-out" parameters, pass by reference to non-const +* F.20: For "out" output values, prefer return values ​​to output parameters +* F.21: To return multiple "out" values, prefer returning a struct or tuple +* F.60: Prefer T * over T & when "no argument" is a valid option +* F.26: Use a unique_ptr to transfer ownership where a pointer is needed +* F.27: Use a shared_ptr to share ownership + +___ + +## C: Classes and class hierarchies + +* C.1: Organize related data into structures (structs or classes) +* C.2: Use class if the class has an invariant; use struct if the data members can vary independently +* C.7: Don't define a class or enum and declare a variable of its type in the same statement +* C.8: Use class rather than struct if any member is non-public +* C.9: Minimize exposure of members + +___ + +## Enum: Enumerations + +* Enum.1: Prefer enumerations over macros +* Enum.2: Use enumerations to represent sets of related named constants +* Enum.3: Prefer enum classes over "plain" enums +* Enum.4: Define operations on enumerations for safe and simple use +* Enum.5: Don't use ALL_CAPS for enumerators +* Enum.6: Avoid unnamed enumerations +* Enum.7: Specify the underlying type of an enumeration only when necessary +* Enum.8: Specify enumerator values ​​only when necessary + +___ + +## Q&A diff --git a/module1/presentation_practices.md b/module1/04_practices.pl.md similarity index 100% rename from module1/presentation_practices.md rename to module1/04_practices.pl.md diff --git a/module1/05_homework.en.md b/module1/05_homework.en.md new file mode 100644 index 0000000..09226af --- /dev/null +++ b/module1/05_homework.en.md @@ -0,0 +1,41 @@ + + +# C ++ basics + +## Summary + + + Coders School + + +___ + +## What do you remember from today? + +### Write as many passwords as possible in the chat + + +1. Team collaboration +2. Conventions +3. Cpp Core Guidelines +4. Good practices + +___ + +## Homework + +### Pre-work + +* Remember how to build a project in Debug mode +* Watch [is a video about debugging](https://www.youtube.com/watch?v=gFCQ37jVN3g) +* Make sure you have the debugger installed `gdb` +* Play around with the gdb or [onlinegdb.com](http://onlinegdb.com) + +___ + +### Post-work + +* Apply what you've learned in all your projects and homework to date. You don't need to re-submit the PR, but ask other people for a review if you have any doubts. +* From now on, when doing reviews to other people, pay attention to the best practices presented :) +* From boredom, return to tasks on [Firecode.io](https://www.firecode.io) :) +* Review the headings from [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), and in your spare time read as much as you can :) diff --git a/module1/presentation_homework.md b/module1/05_homework.pl.md similarity index 100% rename from module1/presentation_homework.md rename to module1/05_homework.pl.md diff --git a/module1/index.en.html b/module1/index.en.html new file mode 100644 index 0000000..8345dca --- /dev/null +++ b/module1/index.en.html @@ -0,0 +1,121 @@ + + + + + + + Good practices - Coders School + + + + + + + + + + + + + + + +
+
+
+
+ +

Good practices #1

+ + Coders School + +

Mateusz Adamski

+

Łukasz Ziobroń

+ +
+
+ +
+
+ +
+
+
+
+
+
+
+
+
+
+
+ +

Coders School

+ Coders School + +
+
+
+ + + + + + diff --git a/module1/index.html b/module1/index.pl.html similarity index 93% rename from module1/index.html rename to module1/index.pl.html index c08966d..f85249e 100644 --- a/module1/index.html +++ b/module1/index.pl.html @@ -67,23 +67,23 @@

Łukasz Ziobroń

You can change the port by using npm start -- --port=8001. --> -
-
-
-
-
From eb3d5a38ce77dbd5d7c4ca58d9d5189c2155befe Mon Sep 17 00:00:00 2001 From: MrMijagi Date: Sat, 29 Aug 2020 19:35:12 +0200 Subject: [PATCH 2/3] module1 finished --- README.md | 32 ++++++++++++++++------ module1/01_teamwork.en.md | 39 ++++++++++++++------------- module1/02_conventions.en.md | 38 +++++++++++++-------------- module1/03_principles.en.md | 51 +++++++++++++++++------------------- module1/03_principles.pl.md | 2 +- module1/04_practices.en.md | 45 ++++++++++++++++--------------- module1/04_practices.pl.md | 13 +++++---- module1/05_homework.en.md | 22 ++++++++-------- module1/05_homework.pl.md | 8 +++--- 9 files changed, 132 insertions(+), 118 deletions(-) diff --git a/README.md b/README.md index cc20f9e..165abd5 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,33 @@ -# Dobre praktyki - Coders School -## [Moduł 1](module1/) +# Dobre praktyki + +## [Moduł 1](module1/index.pl.html) + +### [Współpraca grupowa](module1/01_teamwork.pl.md) + +### [Konwencje](module1/02_conventions.pl.md) + +### [Praktyki programistyczne](module1/03_principles.pl.md) + +### [Dobre praktyki](module1/04_practices.pl.md) + +### [Praca domowa](module1/05_homework.pl.md) + +___ + +# Good practices + +## [Module 1](module1/index.en.html) -### [Współpraca grupowa](module1/presentation_teamwork.md) +### [Teamwork](module1/01_teamwork.en.md) -### [Konwencje](module1/presentation_conventions.md) +### [Conventions](module1/02_conventions.en.md) -### [Praktyki programistyczne](module1/presentation_principles.md) +### [Programming principles](module1/03_principles.en.md) -### [Dobre praktyki](module1/presentation_practices.md) +### [Good practices](module1/04_practices.en.md) -### [Praca domowa](module1/presentation_homework.md) +### [Homework](module1/05_homework.en.md) diff --git a/module1/01_teamwork.en.md b/module1/01_teamwork.en.md index c0cbd6d..3af676f 100644 --- a/module1/01_teamwork.en.md +++ b/module1/01_teamwork.en.md @@ -1,6 +1,6 @@ -# Group collaboration +# Teamwork Coders School @@ -10,7 +10,7 @@ ___ ## Philosophical questions -### a.k.a. joint retro +### a.k.a. retrospective * How did you feel while working together? * Were there problems that you did not foresee at the beginning? @@ -22,7 +22,7 @@ ___ ## Unexpected problems -The fact that we threw you a little into this project and forced you to self-organize was a deliberate procedure. +The fact that we threw you a little into this project and forced you to self-organize was on purpose. We wanted to show you how many things are not taken into account at the beginning before starting the project. @@ -35,14 +35,14 @@ And even with several years of experience in project management, some things can * unexpected departures * additional, unplanned tasks * wrongly estimated task time -* technical problems (computer restarting, git - conflicts, interrupting the internet) +* technical problems (computer restarting itself, git - conflicts, bad internet connection) * changing requirements or their interpretations ___ ## Task estimation -The theory suggests that a fairly cool way to better estimate tasks is to multiply the initial estimate by PI 😄 +The theory suggests that a cool way to better estimate tasks is to multiply the initial estimate by PI 😄 Other sources indicate that an order of magnitude should be increased (e.g. from 5 hours to 5 days, from 3 days to 3 weeks, etc.) 😄 @@ -62,15 +62,15 @@ ___ * We do not estimate tasks in units of time. * We choose one task for the whole team that is the easiest of all. We give it the value of 1. * We only use the values ​​from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ♾,? - I have no idea, ☕️). Thanks to this, we focus more on orders of magnitude than on the units themselves, because there is no big difference between 9 and 10. -* The unit is Story Points (SP). This is a completely abstract measure. You can think of it as any other abstract. For example, this task is valued at 5 chestnuts. This information is completely useless, but it allows you to compare tasks. Since that is worth 8, it is more valuable (more difficult). +* The unit is Story Points (SP). This is a completely abstract measure. You can think of it as any other abstract. For example, this task is valued for 5 chestnuts. This information is completely useless, but it allows you to compare tasks. Since the other one is worth 8, it is more valuable (more difficult). * For one person, 1 SP may mean 1 hour of work, and for another - 1 day. ___ ### The course of the estimation -* We discuss one selected task with the whole team to make sure that everyone understands it the same. -* When everyone is ready they _simultaneously_ draw the card with their estimate so as not to be influenced by others +* We discuss one selected task with the whole team to make sure that everyone understands it in the same way. +* When everyone is ready they _simultaneously_ draw the card with their estimate so nobody is influenced by others * If the discrepancy is large, it means that team members have a different understanding of the task and still need to be discussed. It is worth asking people with the lowest and highest estimate why they give so much. * If the discrepancies are small, you can average them or agree to some value (usually higher) @@ -81,13 +81,13 @@ ___ ## Collective responsibility -It's hard to blame someone for getting sick. But you can blame him for committing to something and not letting him know that it won't work. So it's important daily to get in the habit of updating your status at least daily. Of course you can more often. +It's hard to blame someone for getting sick. But you can blame him for committing to something and then him not letting you know that it won't work. So daily is important to get in the habit of updating your status at least daily. Of course you can do it more often. -As soon as you find out that someone from the crew is ailing you, you should think immediately what to do about it. If the works were started, what has been done so far should be communicated / communicated. This is another reason why small and frequent commits are a good practice. Everyone has access to the current version of the code and it's easy to donate work. +As soon as you find out that someone from the crew isn't keeping up, you should think immediately what to do about it. If the works were started, what has been done so far should be communicated. This is another reason why small and frequent commits are a good practice. Everyone has access to the current version of the code and it's easy to pass work. -For us, outside observers, we can never judge how much each team has done. The team just did it for us. If you feel that you are doing too much / too little and something is unfair, you can write us about your problems and change the team if necessary. +For us, outside observers, we can never judge how much each team has done. For us it is the team that has done something. If you feel that you are doing too much/too little and something is unfair, you can write us about your problems and change the team if necessary. ___ @@ -97,7 +97,7 @@ ___ * Pair programming * Mob programming * Peer code review -* Deliver jobs as quickly as possible. Better to deliver 4 out of 8 tasks by working 2 people on each other than 0/8 having all started at the same time. +* Deliver jobs as quickly as possible. It is better to deliver 4 out of 8 tasks with 2 people working on each other than 0/8 having all started at the same time. * No top-down assignments of people to tasks. The person who just has time takes the first task in advance (or one of the first, if not blocked) * 1 person can only be assigned 1 task at a time. Only after completing the previous quest can you take another one. @@ -105,17 +105,20 @@ ___ ## [Agile manifesto](https://agilemanifesto.org) -> We discover new programming methods thanks to programming practice and supporting others in it. As a result of our work, we began to value more: +> We are uncovering better ways of developing +software by doing it and helping others do it. +Through this work we have come to value: > -> **People and interactions** from processes and tools +> **Individuals and interactions** over processes and tools > -> **Working software** from detailed documentation +> **Working software** over comprehensive documentation > -> **Cooperation with the client** from negotiating contracts +> **Customer collaboration** over contract negotiation > -> **Responding to changes** from the implementation of the assumed plan. +> **Responding to change** over following a plan > -> This means that the items on the right are valuable, but the ones on the left are more valuable to us. +> That is, while there is value in the items on +the right, we value the items on the left more. ___ diff --git a/module1/02_conventions.en.md b/module1/02_conventions.en.md index 93cd8e2..4499b65 100644 --- a/module1/02_conventions.en.md +++ b/module1/02_conventions.en.md @@ -100,13 +100,13 @@ ___ * lowerCamelCase * UpperCamelCase (PascalCase) * snake_case (Python convention) -* kebab-case (rare in C ++, often in the front-end) +* kebab-case (rare in C++, often in the front-end) ___ ## Hungarian notation - bad practice -In Hungarian notation, type information is contained in the variable name. [Read on the Wiki and never apply](https://pl.wikipedia.org/wiki/Notacja_węgierska) +In Hungarian notation, type information is contained in the variable name. [Read on the Wiki and never use it](https://pl.wikipedia.org/wiki/Notacja_węgierska) * ~~`iNumber`~~ * ~~`szName`~~ @@ -114,7 +114,7 @@ In Hungarian notation, type information is contained in the variable name. [Read ___ -## Conventions for class fields +## Conventions for class members * postfix _underscore_ `_` behind the name * prefix `m_` before the name @@ -143,19 +143,19 @@ ___ Note, these are my opinions based on my experience. * local variable: variable - * Functions / code blocks should be small (up to 10 lines). Then we easily find local variables a few lines higher + * Functions/code blocks should be small (up to 10 lines). Then we easily find local variables a few lines higher * function parameter: variable * For small functions, the parameters are also found a few lines higher without scrolling -* class field: variable_ +* class member: variable_ * The class variables sit in the header file and we would have to switch to a different file to make sure it's a class field. The convention here is postfix `_` * global variables: VARIABLE - * Uppercase variables / constants are global. There are arguments for not doing this either, but I don't remember them. + * Uppercase variables/constants are global. There are arguments for not doing this either, but I don't remember them. * static variables: s_variable * Prefix here `s_` can stay, because other ways are already taken :) ___ -## What to name? +## How to name what? All this is a matter of convention and may differ from project to project. The most important thing is that it is uniform throughout the project. We make the following assumptions. @@ -177,7 +177,7 @@ ___ ### Variables * lowerCamelCase -* noun (s) + adjectives (optional) +* noun(s) + adjectives (optional) ```cpp SuperWarrior mightyBarbarian; // ok @@ -198,10 +198,10 @@ int calculateCommonSum(); // ok ___ -### Class fields +### Class members * as normal variables -* additionally after the name _underscore_ `_` +* additionally _underscore_ `_` after the name ```cpp class SuperWarrior @@ -226,7 +226,7 @@ ___ ## Descriptive variable names -Let's not name variables like this: +Don't name variables like this: ```cpp int a = 0; // what is a? @@ -249,10 +249,10 @@ ___ ### Allowed short names -* `i`, `j` - as indices in loops +* `i`, `j` - as indexes in loops * `it` - as an abbreviation of `iterator` -* `el`, `elem` - as an abbreviation of `element` in collection loops -* `lhs`, `rhs` - as an abbreviation of `leftHandSide` and `rightHandSide` in comparer functions +* `el`, `elem` - as an abbreviation of `element` in loops over collection +* `lhs`, `rhs` - as an abbreviation of `leftHandSide` and `rightHandSide` in comparing functions ___ @@ -286,7 +286,7 @@ ___ ### My favorite formatting -Attention, this is an opinion! For features - Allman. For loops, if - Egyptian. For classes - whatever. Reason: +Note that this is an opinion! For functions - Allman. For loops and ifs - Egyptian. For classes - whatever. Reason: ```cpp class SuperWarrior @@ -314,7 +314,7 @@ ___ Constructor initialization lists or too long names and types of function parameters spoil the readability of the code blocks a little. -In contrast: +For contrast: ```cpp class SuperWarrior { @@ -351,7 +351,7 @@ ___ ## The ternary operator `?:` -One line is usually unreadable +One line notation is usually unreadable ```cpp @@ -378,7 +378,7 @@ lhs.name == rhs.name && lhs.amount == rhs.amount && lhs.price == rhs.price ``` -Although IMO is better to use the usual one in the last case `if`. +Although IMO its better to use the usual one in the last `if` case. ___ @@ -387,7 +387,7 @@ ___ ### `clang-format` -The project should include a file `.clang-format`which will ensure that anyone can apply the formatting it describes automatically +The project should include a file `.clang-format` which will ensure that anyone can apply the formatting it describes automatically ```bash clang-format -style=.clang-format -i *.cpp *.hpp diff --git a/module1/03_principles.en.md b/module1/03_principles.en.md index 0319705..bf4f3ca 100644 --- a/module1/03_principles.en.md +++ b/module1/03_principles.en.md @@ -1,6 +1,6 @@ -# Programming practices +# Programming principles Coders School @@ -8,7 +8,7 @@ ___ -## Known and liked practices +## Known and liked principles * Fail-fast * Scout rule @@ -27,7 +27,7 @@ ___ ___ -### This we will cover in Best Practice # 2 +### We will cover this in Best Practice #2 * SOLID * GRASP @@ -38,7 +38,7 @@ ___ ## Fail-fast -Choke the program as soon as possible in case of problems. It's better than acting and crashing it over Undefined Behavior later. Good luck finding the cause in that case. +Stop the program as soon as possible in case of problems. It's better than it running and crashing due to Undefined Behavior later. Good luck finding the cause in that case. ### Allowed things @@ -66,18 +66,18 @@ void process(std::shared_ptr value) { ___ -## Scout rule - the scout rule +## Scout rule -> Always leave the campsite at least as you found it. +> Always leave the campsite in the same state as you found it. -Same with the code as with the camping. If you get dirty in the code - you have to clean it up. Cleaning up after others is also very welcome. +Same with the code as with the camping. If you do mess in the code - you have to clean it up. Cleaning up after others is also very welcome. If you touch someone's code, e.g. by just adding one line - try to improve it. -Cleaning is to be in a separate commite. +Cleaning should be in a separate commit. ### Pros @@ -93,17 +93,17 @@ ___ ### Don't Repeat Yourself -Often, duplications are caused by a simple "copipasty" operation. +Often, duplications are caused by a simple copy-paste operation. -Code that is the same or similar in more than 1 place should be extracted into a function and called that function there +Code that is the same or similar in more than 1 place should be extracted into a function and call that function in this place ### Pros * easier refactoring - change only in one place -* less room for mistakes. There is no risk that we will not change all occurrences once we discover a bug +* less room for mistakes. There is no risk that we will forget some occurrences once we discover a bug ___ @@ -112,7 +112,7 @@ ___ ### Don't Reinvent The Wheel -Do not reinvent the wheel and use ready-made libraries that provide the given functionality. +Do not reinvent the wheel and use already made libraries that provide given functionality. ### Pros @@ -125,21 +125,18 @@ Do not reinvent the wheel and use ready-made libraries that provide the given fu ___ -## KISS / BUZI +## KISS ### Keep It Simple, Stupid -### No Record Freaks, Idiot - - When writing the code, we do not force the tricks and novelties that may make it more universal and easy for future development, but will reduce its readability. Many seniors have a problem with this and complicate the code unnecessarily. They know from experience that this will make the code easier to modify in the future. What if it will never be modified afterwards, but still read many times? -We introduce each "improvement" only when there is such a need. We don't write anything "in stock". See - YAGNI. +We introduce each "improvement" only when there is such a need. We don't write anything "in advance". See - YAGNI. ### Pros @@ -157,7 +154,7 @@ ___ You won't need this. We don't write code in advance, thinking it will come in handy soon. In this way, we generate dead code that is never and probably will not be used. -If in the future a given functionality is needed, another person will probably implement it (even you will forget that you have already written something after a month) and will write it again. +If in the future when a given functionality will be needed, another person will probably implement it (even you will forget that you have already written something after a month and will write it again). ### Pros @@ -169,17 +166,17 @@ The less code the better: * shorter compilation time * less complicated dependencies * less to analyze -* less to remember (that something was taken as a spare) +* less to remember (that something was made in advance) * faster tool use (grep or Ctrl+F have less to scan) ___ ## RTFM -### Read The F * cking Manual;) +### Read The F*cking Manual 😉 -Before you inundate people with questions about a given functionality / tool, read the manual. +Before you start spamming people with questions about a given functionality/tool, read the manual. In Linux, for the tool `tool` use `tool --help` and `man tool`. @@ -191,7 +188,7 @@ If, after reading the documentation, you still don't know what to do, then ask o ### Pros -* More experienced people often have a tight calendar, so they will be grateful if you find a solution on their own or briefly;) +* More experienced people often have a tight calendar, so they will be grateful if you find a solution on your own or briefly explain problem 😉 ___ @@ -219,18 +216,18 @@ ___ ### Command Query Responsibility Segregation -Separate write from reading. +Separate writing from reading. -* Query - getting (reading) data - getters -* Command - action on data (write) +* Query - getting (reading) data - getters +* Command - working on data (write) We should avoid methods that do both because: > Asking a question should not change the answer > -> - * Bertrand Meyer * +> -- * Bertrand Meyer * ___ @@ -246,7 +243,7 @@ The remaining 10% of the tasks will be completed in the remaining 90% of the tim Useful when assessing the progress of work. -At first the work goes quite briskly (the general outline of the task), but it is only in the process that unthought out boundary cases are discovered, due to which the task will take longer time expected. +At first the work goes quite easy (the general outline of the task), but then edge cases get discovered which were unthought of before, due to which the task will take longer time expected. ___ diff --git a/module1/03_principles.pl.md b/module1/03_principles.pl.md index 92d17ad..b12f76d 100644 --- a/module1/03_principles.pl.md +++ b/module1/03_principles.pl.md @@ -84,7 +84,7 @@ Sprzątanie ma być w osobnym commicie. * kod może być tylko coraz czytelniejszy -* nie robimy długu technicznego, który kiedyś trzeba będzie spałcić +* nie robimy długu technicznego, który kiedyś trzeba będzie spłacić ___ diff --git a/module1/04_practices.en.md b/module1/04_practices.en.md index bc36596..9f2e801 100644 --- a/module1/04_practices.en.md +++ b/module1/04_practices.en.md @@ -8,18 +8,18 @@ ___ -## Mystery +## Riddle -Tomek got 3 apples, but he ate 2. How many apples does Tom have? +Tom got 3 apples, but he ate 2. How many apples does Tom have? -### Reply +### The answer We don't know, because we don't know how many he had before he got 3 apples. -### Moral +### Conclusion Always initialize variables. @@ -59,7 +59,7 @@ ___ Code full of domain names (own types) is easier to read. Also people who do not deal with programming on a daily basis can deduce a lot from it. -Check out these 2 features: +Check out these 2 functions: ```cpp @@ -68,7 +68,7 @@ std::array, height> decompressGrayscale(std::vector -And see them now: +And compare to this: ```cpp @@ -77,7 +77,7 @@ Image decompressGrayscale(const CompressedImage& compression); ``` -To achieve this, it is enough to give different names to the types like this: +To achieve this, you just have to give different names to the types like this: ```cpp @@ -90,7 +90,7 @@ ___ ## Forward declarations -Use forward declarations where possible instead `#include`. +Use forward declarations where possible instead of `#include`. In order to use an object, the compiler needs information about its size. @@ -106,17 +106,17 @@ int main() { ``` -So in order to be able to create a local variable, I need to know its size. So it must have a proper header where this class is defined to know the size of such a variable on the stack. +So in order to be able to create a local variable, it needs to know its size. So it must have a proper header where this class is defined to know the size of such a variable on the stack. ___ -### Mystery +### Riddle * What size is the pointer on int? * What size is the pointer on Fruit? -### Reply +### Answer The size of the pointer does not depend on the type it points to. Usually it is 4 or 8 bytes long (for 32 and 64 bit processors respectively). @@ -124,9 +124,9 @@ The size of the pointer does not depend on the type it points to. Usually it is ___ -### Object size unknown +### Unknown object size -Each indicator and reference are of the same size. As long as we use them and do not refer to any methods or fields of the class, we do not need information about its size or content. +Each pointer and reference have the same size. As long as we use them and do not refer to any methods or fields of the class, we do not need information about its size or content. ```cpp @@ -141,7 +141,7 @@ void pass(Fruit* fruit) { ``` -In that case, we just need to tell the compiler that the pointer type is our class by means of a forward declaration. You do not need to apply then `#include` and we speed up compilation. +In that case, we just need to tell the compiler that the pointer type is our class by means of a forward declaration. You do not need to apply `#include` and we speed up compilation. ___ @@ -186,10 +186,9 @@ ___ ### Avoiding Implicit Conversions -Key word `explicit` prohibits implicit conversions. They are used with constructors that may accidentally convert from the type of argument they take. +Keyword `explicit` prohibits implicit conversions. They are used with constructors that may accidentally convert from the type of argument they take. - ```cpp class Apple { int weight_; @@ -209,7 +208,7 @@ ___ ## `explicit` -Key word `explicit` we use for: +Keyword `explicit` is used for: * unary constructors * `explicit Apple(int weight);` @@ -229,17 +228,17 @@ ___ * F.1: "Package" meaningful operations as carefully named functions * F.2: A function should perform a single logical operation * F.3: Keep functions short and simple -* F.4: If a function may have to be evaluated at compile time, declare it constexpr -* F.5: If a function is very small and time-critical, declare it inline -* F.6: If your function may not throw, declare it noexcept +* F.4: If a function may have to be evaluated at compile time, declare it `constexpr` +* F.5: If a function is very small and time-critical, declare it `inline` +* F.6: If your function may not throw, declare it `noexcept` * F.9: Unused parameters should be unnamed * F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to const * F.17: For "in-out" parameters, pass by reference to non-const * F.20: For "out" output values, prefer return values ​​to output parameters * F.21: To return multiple "out" values, prefer returning a struct or tuple -* F.60: Prefer T * over T & when "no argument" is a valid option -* F.26: Use a unique_ptr to transfer ownership where a pointer is needed -* F.27: Use a shared_ptr to share ownership +* F.60: Prefer `T*` over `T&` when "no argument" is a valid option +* F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed +* F.27: Use a `shared_ptr` to share ownership ___ diff --git a/module1/04_practices.pl.md b/module1/04_practices.pl.md index 2dc8d88..24a77f2 100644 --- a/module1/04_practices.pl.md +++ b/module1/04_practices.pl.md @@ -189,7 +189,6 @@ ___ Słowo kluczowe `explicit` zabrania niejawnych konwersji. Stosuje się je przy konstruktorach, które mogą przypadkiem spowodować konwersję z typu argumentu który przyjmują. - ```cpp class Apple { int weight_; @@ -229,17 +228,17 @@ ___ * F.1: "Package" meaningful operations as carefully named functions * F.2: A function should perform a single logical operation * F.3: Keep functions short and simple -* F.4: If a function may have to be evaluated at compile time, declare it constexpr -* F.5: If a function is very small and time-critical, declare it inline -* F.6: If your function may not throw, declare it noexcept +* F.4: If a function may have to be evaluated at compile time, declare it `constexpr` +* F.5: If a function is very small and time-critical, declare it `inline` +* F.6: If your function may not throw, declare it `noexcept` * F.9: Unused parameters should be unnamed * F.16: For "in" parameters, pass cheaply-copied types by value and others by reference to const * F.17: For "in-out" parameters, pass by reference to non-const * F.20: For "out" output values, prefer return values to output parameters * F.21: To return multiple "out" values, prefer returning a struct or tuple -* F.60: Prefer T* over T& when "no argument" is a valid option -* F.26: Use a unique_ptr to transfer ownership where a pointer is needed -* F.27: Use a shared_ptr to share ownership +* F.60: Prefer `T*` over `T&` when "no argument" is a valid option +* F.26: Use a `unique_ptr` to transfer ownership where a pointer is needed +* F.27: Use a `shared_ptr` to share ownership ___ diff --git a/module1/05_homework.en.md b/module1/05_homework.en.md index 09226af..def1a38 100644 --- a/module1/05_homework.en.md +++ b/module1/05_homework.en.md @@ -1,6 +1,6 @@ -# C ++ basics +# C++ basics ## Summary @@ -12,10 +12,10 @@ ___ ## What do you remember from today? -### Write as many passwords as possible in the chat +### Write as many keywords as possible in the chat -1. Team collaboration +1. Teamwork 2. Conventions 3. Cpp Core Guidelines 4. Good practices @@ -26,16 +26,16 @@ ___ ### Pre-work -* Remember how to build a project in Debug mode -* Watch [is a video about debugging](https://www.youtube.com/watch?v=gFCQ37jVN3g) -* Make sure you have the debugger installed `gdb` -* Play around with the gdb or [onlinegdb.com](http://onlinegdb.com) +* Recall how to build a project in Debug mode +* Watch [this video about debugging](https://www.youtube.com/watch?v=gFCQ37jVN3g) +* Make sure you have installed `gdb` debugger +* Play around with `gdb` or [onlinegdb.com](http://onlinegdb.com) ___ ### Post-work -* Apply what you've learned in all your projects and homework to date. You don't need to re-submit the PR, but ask other people for a review if you have any doubts. -* From now on, when doing reviews to other people, pay attention to the best practices presented :) -* From boredom, return to tasks on [Firecode.io](https://www.firecode.io) :) -* Review the headings from [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), and in your spare time read as much as you can :) +* Apply what you've learned in all your previous projects and homeworks. You don't need to re-submit PR, but ask other people for a review if you have any doubts. +* From now on, when doing reviews to other people, pay attention to the best practices presented 🙂 +* From boredom, return to tasks on [Firecode.io](https://www.firecode.io) 🙂 +* Review the headings from [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), and in your spare time read as much as you can 🙂 diff --git a/module1/05_homework.pl.md b/module1/05_homework.pl.md index 9bc986c..37e91f4 100644 --- a/module1/05_homework.pl.md +++ b/module1/05_homework.pl.md @@ -29,13 +29,13 @@ ___ * Przypomnij sobie jak zbudować projekt w trybie Debug * Obejrzyj [to wideo o debugowaniu](https://www.youtube.com/watch?v=gFCQ37jVN3g) * Upewnij się, że masz zainstalowany debugger `gdb` -* Pobaw się debuggerem gdb lub [onlinegdb.com](http://onlinegdb.com) +* Pobaw się debuggerem `gdb` lub [onlinegdb.com](http://onlinegdb.com) ___ ### Post-work * Zastosuj poznaną wiedzę we wszystkich dotychczasowych projektach i pracach domowych. Nie musisz zgłaszać ponownie PR, ale poproś inne osoby o review, jeśli masz jakieś wątpliwości. -* Od teraz robiąc review innym osobom zwracaj uwagę na przedstawione dobre praktyki :) -* Z nudów powróć do zadań na [Firecode.io](https://www.firecode.io) :) -* Przejrzyj nagłówki z [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), a w wolnych chwilach czytaj ile się da :) +* Od teraz robiąc review innym osobom zwracaj uwagę na przedstawione dobre praktyki 🙂 +* Z nudów powróć do zadań na [Firecode.io](https://www.firecode.io) 🙂 +* Przejrzyj nagłówki z [CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), a w wolnych chwilach czytaj ile się da 🙂 From 59ec97d39db25257a4d460a89d0b2533de8df0a0 Mon Sep 17 00:00:00 2001 From: MrMijagi Date: Sat, 29 Aug 2020 20:16:02 +0200 Subject: [PATCH 3/3] some fixes --- module1/01_teamwork.en.md | 6 +++--- module1/01_teamwork.pl.md | 2 +- module1/02_conventions.en.md | 4 ++-- module1/03_principles.en.md | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/module1/01_teamwork.en.md b/module1/01_teamwork.en.md index 3af676f..20c985b 100644 --- a/module1/01_teamwork.en.md +++ b/module1/01_teamwork.en.md @@ -70,9 +70,9 @@ ___ ### The course of the estimation * We discuss one selected task with the whole team to make sure that everyone understands it in the same way. -* When everyone is ready they _simultaneously_ draw the card with their estimate so nobody is influenced by others -* If the discrepancy is large, it means that team members have a different understanding of the task and still need to be discussed. It is worth asking people with the lowest and highest estimate why they give so much. -* If the discrepancies are small, you can average them or agree to some value (usually higher) +* When everyone is ready they simultaneously draw the card with their estimate so nobody is influenced by others +* If the divergence is large, it means that team members have a different understanding of the task and still need to be discussed. It is worth asking people with the lowest and highest estimate why they give so much. +* If the divergences are small, you can average them or agree to some value (usually higher) Look for online Scrum Poker tools and use them to estimate tasks in Planning. diff --git a/module1/01_teamwork.pl.md b/module1/01_teamwork.pl.md index d838758..e569a3a 100644 --- a/module1/01_teamwork.pl.md +++ b/module1/01_teamwork.pl.md @@ -70,7 +70,7 @@ ___ ### Przebieg estymacji * Całym zespołem omawiamy sobie jedno wybrane zadanie, aby mieć pewność, że wszyscy rozumieją je tak samo. -* Gdy wszyscy są gotowi _jednocześnie_ wyciągają kartę ze swoją estymatą, aby nie sugerować się innymi +* Gdy wszyscy są gotowi jednocześnie wyciągają kartę ze swoją estymatą, aby nie sugerować się innymi * Jeśli rozbieżności są duże, to znaczy, że członkowie zespołu mają różne zrozumienie zadania i trzeba jeszcze o nim podyskutować. Warto zapytać osoby z najmniejszą i największą estymatą dlaczego tyle dają. * Jeśli rozbieżności są małe to można je uśrednić lub wspólnie zgodzić się na którąś wartość (zazwyczaj wyższą) diff --git a/module1/02_conventions.en.md b/module1/02_conventions.en.md index 4499b65..d4b7abf 100644 --- a/module1/02_conventions.en.md +++ b/module1/02_conventions.en.md @@ -26,7 +26,7 @@ ___ ## Each block (scope) = indent -Any range that begins with parentheses `{` - even if it is not present, e.g. for one-line ones `if`, `for` - must have an additional level of indentation. +Any scope that begins with parentheses `{` - even if it is not present, e.g. for one-line ones `if`, `for` - must have an additional level of indentation. ```cpp int addEven(const std::vector& numbers) @@ -60,7 +60,7 @@ ___ ### Exceptions - `switch/case` -Often with instructions `switch/case` you will meet with that `case` is on the same level as `switch`. We do not consider this a mistake. +Often with instructions `switch/case` you will see that `case` is on the same level as `switch`. We do not consider this a mistake. ```cpp switch (value) { diff --git a/module1/03_principles.en.md b/module1/03_principles.en.md index bf4f3ca..92588ab 100644 --- a/module1/03_principles.en.md +++ b/module1/03_principles.en.md @@ -188,7 +188,7 @@ If, after reading the documentation, you still don't know what to do, then ask o ### Pros -* More experienced people often have a tight calendar, so they will be grateful if you find a solution on your own or briefly explain problem 😉 +* More experienced people often have a tight calendar, so they will be grateful if you find a solution on your own or shortly explain problem 😉 ___ @@ -243,7 +243,7 @@ The remaining 10% of the tasks will be completed in the remaining 90% of the tim Useful when assessing the progress of work. -At first the work goes quite easy (the general outline of the task), but then edge cases get discovered which were unthought of before, due to which the task will take longer time expected. +At first the work goes quite easy (the general outline of the task), but then edge cases get discovered which were unthought of before, due to which task will take longer time than expected. ___