Skip to content

Commit 9638059

Browse files
dawidbildawidbil
authored
Normalizacja i ujednolicanie (coders-school#1)
* normalizacja i ujednolicanie * updated README.md
1 parent c88289c commit 9638059

File tree

15 files changed

+302
-74
lines changed

15 files changed

+302
-74
lines changed

‎.gitignore‎

Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
.idea/
2+
*.iml
3+
*.iws
4+
*.eml
5+
out/
6+
.DS_Store
7+
.svn
8+
log/*.log
9+
tmp/**
10+
node_modules/
11+
.sass-cache
12+
css/reveal.min.css
13+
js/reveal.min.js
14+
15+
# Prerequisites
16+
*.d
17+
18+
# Builds, test, IDE
19+
build/
20+
.vscode/
21+
googletest/
22+
23+
# Compiled Object files
24+
*.slo
25+
*.lo
26+
*.o
27+
*.obj
28+
29+
# Precompiled Headers
30+
*.gch
31+
*.pch
32+
33+
# Compiled Dynamic libraries
34+
*.so
35+
*.dylib
36+
*.dll
37+
38+
# Fortran module files
39+
*.mod
40+
*.smod
41+
42+
# Compiled Static libraries
43+
*.lai
44+
*.la
45+
*.a
46+
*.lib
47+
48+
# Executables
49+
*.exe
50+
*.out
51+
*.app

‎README.md‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
# Q&A sessions
2+
3+
<a href="https://coders.school">
4+
<img width="500" data-src="coders_school_logo.png" src="coders_school_logo.png" alt="Coders School" class="plain">
5+
</a>
6+
7+
## [Moduł 1](module1/)
8+
9+
### [Współpraca grupowa - Scrum](module1/scrum.md)
10+
11+
### [Konkurs STL](module1/konkurs.md)
12+
13+
### [Przykłady z Code Review](module1/code-review.md)
14+
15+
### [Pytania z kanału #powtórka](module1/repetition.md)

‎coders_school_logo.png‎

39 KB
Loading

‎logo.png‎

21.8 KB
Loading

session2/ScrumFramework.pdf renamed to module1/ScrumFramework.pdf

File renamed without changes.

session2/code-review.md renamed to module1/code-review.md

Lines changed: 54 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,9 @@
1-
# Powtórka #2
1+
<!-- .slide: data-background="#111111" -->
22

3-
## Przykłady z Code Review
3+
# Przykłady z Code Review
44

5-
---
5+
___
6+
<!-- .slide: style="font-size: 0.9em" -->
67

78
Example:
89

@@ -16,14 +17,17 @@ bool doesPasswordsMatch(const std::string& password, const std::string& repeated
1617
```
1718
1819
Better:
20+
<!-- .element: class="fragment fade-in" -->
1921
2022
```cpp
2123
bool doesPasswordsMatch(const std::string& password, const std::string& repeatedPassword) {
2224
return password == repeatedPassword;
2325
}
2426
```
27+
<!-- .element: class="fragment fade-in" -->
2528

26-
---
29+
___
30+
<!-- .slide: style="font-size: 0.9em" -->
2731

2832
Example:
2933

@@ -57,6 +61,8 @@ std::string getErrorMessage(ErrorCode Error) {
5761
// We usually don't indent case and code inside namespace
5862
```
5963
64+
___
65+
6066
Better?:
6167
6268
```cpp
@@ -78,7 +84,7 @@ std::string getErrorMessage(ErrorCode error) {
7884
}
7985
```
8086

81-
---
87+
___
8288

8389
Example:
8490

@@ -91,16 +97,17 @@ if(doesPasswordsMatch(first_pass, second_pass)) {
9197
```
9298

9399
Better:
100+
<!-- .element: class="fragment fade-in" -->
94101

95102
```cpp
96103
if(doesPasswordsMatch(first_pass, second_pass)) {
97104
return checkPasswordRules(first_pass);
98105
}
99106
return ErrorCode::PasswordsDoesNotMatch;
100107
```
108+
<!-- .element: class="fragment fade-in" -->
101109

102-
103-
---
110+
___
104111

105112
```cpp
106113
enum class ErrorCode {
@@ -112,7 +119,8 @@ enum class ErrorCode {
112119
113120
> I do not know really, it's maybe my habit taken from python, to have commas also in the last element of enum/collection, because if I add new element in the future, i didn't have to worry about some errors in regards to missing comma :)
114121
115-
---
122+
___
123+
<!-- .slide: style="font-size: 0.75em" -->
116124
117125
> A: You can specify a size of vector in constructor :)
118126
@@ -121,6 +129,7 @@ std::vector<std::shared_ptr<int>> resultVector(count);
121129
```
122130

123131
> B: Yes, but what about situation, when count is negative value? I do not think such value should be used in the vector constructor, that's why I do such check first.
132+
<!-- .element: class="fragment fade-in" -->
124133
125134
```cpp
126135
std::vector<std::shared_ptr<int>> resultVector{};
@@ -129,18 +138,24 @@ if (count < 0) {
129138
}
130139
resultVector.reserve(count);
131140
```
141+
<!-- .element: class="fragment fade-in" -->
132142
133143
> A: you are right :) , my fault :)
144+
<!-- .element: class="fragment fade-in" -->
134145
135146
> B: No problem, thanks for review :)
147+
<!-- .element: class="fragment fade-in" -->
136148
137149
https://github.com/coders-school/kurs_cpp_podstawowy/pull/254/files
150+
<!-- .element: class="fragment fade-in" -->
138151
139-
---
152+
___
153+
<!-- .slide: style="font-size: 0.85em" -->
140154
141155
Max długość linii - 120. Jak formatować?
142156
143157
Zazwyczaj linie są długie gdy funkcja przyjmuje wiele parametrów:
158+
<!-- .element: class="fragment fade-in" -->
144159
145160
```cpp
146161
int superFunction(std::vector<std::shared_ptr<int>> vectorOfSharedPointers, std::map<std::string, int> miniMap, std::unordered_set<int> hashes, std::function<void(int, int)> compareFunction) {
@@ -150,8 +165,10 @@ int superFunction(std::vector<std::shared_ptr<int>> vectorOfSharedPointers, std:
150165
// usage
151166
auto result = superFunction(mySuperVector, myMiniMap, myGreatHashTable, [](const auto & lhs, const auto & rhs) { return lhs >= rhs;})
152167
```
168+
<!-- .element: class="fragment fade-in" -->
153169
154170
Better formatting:
171+
<!-- .element: class="fragment fade-in" -->
155172
156173
```cpp
157174
int superFunction(std::vector<std::shared_ptr<int>> vectorOfSharedPointers,
@@ -167,6 +184,9 @@ auto result = superFunction(mySuperVector,
167184
myGreatHashTable,
168185
[](const auto & lhs, const auto & rhs) { return lhs >= rhs;});
169186
```
187+
<!-- .element: class="fragment fade-in" -->
188+
189+
___
170190
171191
Or for longer lambdas / too long first parameter which exceeds line limit:
172192
@@ -176,7 +196,8 @@ int superFunction(
176196
std::map<std::string, int> miniMap,
177197
std::unordered_set<int> hashes,
178198
std::function<void(int, int)> compareFunction) {
179-
// two levels of indentation above to avoid confusion. The function body below will be indented with one level
199+
// two levels of indentation above to avoid confusion.
200+
// The function body below will be indented with one level
180201
// do sth
181202
}
182203
@@ -188,24 +209,29 @@ auto result = superFunction(mySuperVector,
188209
return lhs >= rhs;
189210
});
190211
```
191-
192-
---
193-
194-
* [Nice usage of std::map instead of ifs' ladder](https://github.com/coders-school/kurs_cpp_podstawowy/pull/252/files)
195-
* Zwracajcie uwagę na znaki końca linii na końcu dokumentu.
196-
* `enum` lub `enum class` są pod spodem wartościami całkowitymi (jakiś rodzaj inta). Nie warto przekazywać ich przez const& w celu optymalizacji.
197-
* Max 2 puste linie. Zazwyczaj wystarcza jedna. 2 puste linie nie mogą wystąpić wewnątrz żadnych bloków (zakresów), jak funkcje, klasy, enumy.
198-
* Dobra praktyka - alokowanie pojemności wektora, gdy jest z góry znana.
199-
* Kiedy stosujemy konwencje?
200-
* Współpraca grupowa - obowiązkowo. Nie ma nic gorszego niż niejednolite formatowanie w projekcie. Narzucamy wam styl zmodyfikowany styl Chromium, aby nie było przepychanek. Możecie go egzekwować do woli, w szczególności w Internal Code Review (czyli wewnątrz grupy, zanim zgłosicie nam Pull Request do sprawdzenia)
201-
* Praca indywidualna - można stosować własne upodobania, ważne żeby było jednolicie.
202-
* Nie bądźcie "code style nazi" i nie wymuszajcie na innych osobach waszego stylu formatowania, jeśli komentujecie indywidualne PR. Oczywiście fajnie gdyby wszystko było tak samo wszędzie, ale tak naprawdę co firma/projekt to spotkacie się z innym formatowaniem. Warto przywyknąć, że nie zawsze wam pasuje to co sprawdzacie. Głównie odnosi się to do nowych linii i nawiasów {}.
203-
* `#include` - ja (Łukasz) nie jestem zbyt nazistowski z komentowaniem wam że:
204-
* jest nieposortowane
205-
* nie ma nowej linii
206-
* żeby to przenosić do cpp zamiast trzymać w hpp
207-
* usunąć, bo nieużywane.
212+
<!-- .element: class="fragment fade-in" -->
213+
214+
___
215+
216+
* <!-- .element: class="fragment fade-in" --> <a href="https://github.com/coders-school/kurs_cpp_podstawowy/pull/252/files">Nice usage of std::map instead of ifs' ladder</a>
217+
* <!-- .element: class="fragment fade-in" --> Zwracajcie uwagę na znaki końca linii na końcu dokumentu.
218+
* <!-- .element: class="fragment fade-in" --> <code>enum</code> lub <code>enum class</code> są pod spodem wartościami całkowitymi (jakiś rodzaj inta). Nie warto przekazywać ich przez const& w celu optymalizacji.
219+
* <!-- .element: class="fragment fade-in" --> Max 2 puste linie. Zazwyczaj wystarcza jedna. 2 puste linie nie mogą wystąpić wewnątrz żadnych bloków (zakresów), jak funkcje, klasy, enumy.
220+
* <!-- .element: class="fragment fade-in" --> Dobra praktyka - alokowanie pojemności wektora, gdy jest z góry znana.
221+
* <!-- .element: class="fragment fade-in" --> Kiedy stosujemy konwencje?
222+
* <!-- .element: class="fragment fade-in" --> Współpraca grupowa - obowiązkowo. Nie ma nic gorszego niż niejednolite formatowanie w projekcie. Narzucamy wam styl zmodyfikowany styl Chromium, aby nie było przepychanek. Możecie go egzekwować do woli, w szczególności w Internal Code Review (czyli wewnątrz grupy, zanim zgłosicie nam Pull Request do sprawdzenia)
223+
* <!-- .element: class="fragment fade-in" --> Praca indywidualna - można stosować własne upodobania, ważne żeby było jednolicie.
224+
* <!-- .element: class="fragment fade-in" --> Nie bądźcie "code style nazi" i nie wymuszajcie na innych osobach waszego stylu formatowania, jeśli komentujecie indywidualne PR. Oczywiście fajnie gdyby wszystko było tak samo wszędzie, ale tak naprawdę co firma/projekt to spotkacie się z innym formatowaniem. Warto przywyknąć, że nie zawsze wam pasuje to co sprawdzacie. Głównie odnosi się to do nowych linii i nawiasów {}.
225+
226+
___
227+
228+
* <!-- .element: class="fragment fade-in" --> <code>#include</code> - ja (Łukasz) nie jestem zbyt nazistowski z komentowaniem wam że:
229+
* <!-- .element: class="fragment fade-in" --> jest nieposortowane
230+
* <!-- .element: class="fragment fade-in" --> nie ma nowej linii
231+
* <!-- .element: class="fragment fade-in" --> żeby to przenosić do cpp zamiast trzymać w hpp
232+
* <!-- .element: class="fragment fade-in" --> usunąć, bo nieużywane.
208233

209234
Tylko jak mi się rzuci w oczy to daję taki komentarz. Ale wiedzcie, że to są dobre praktyki i warto je stosować.
235+
<!-- .element: class="fragment fade-in" -->
210236

211-
* Też nie bądźcie nazistami i nie róbcie całego code review tylko po to, żeby komuś wytknąć nieposortowane headery lub brakujące {} w jednym miejscu. Podczas projektów grupowych takie rzeczy sobie nawytykacie wewnątrz grup i tak się najszybciej nauczycie :) Na zewnątrz do sprawdzenia ma wychodzić kod przejrzany przez pozostałe osoby z grupy. Nie ma zwalania winy, że to pisał X i on nie dopilnował. Cała grupa obrywa równo ;)
237+
* <!-- .element: class="fragment fade-in" --> Też nie bądźcie nazistami i nie róbcie całego code review tylko po to, żeby komuś wytknąć nieposortowane headery lub brakujące {} w jednym miejscu. Podczas projektów grupowych takie rzeczy sobie nawytykacie wewnątrz grup i tak się najszybciej nauczycie :) Na zewnątrz do sprawdzenia ma wychodzić kod przejrzany przez pozostałe osoby z grupy. Nie ma zwalania winy, że to pisał X i on nie dopilnował. Cała grupa obrywa równo ;)

session2/dangling.cpp renamed to module1/dangling.cpp

File renamed without changes.

screenshot.png renamed to module1/img/screenshot.png

File renamed without changes.

‎module1/index.html‎

Lines changed: 114 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,114 @@
1+
<!doctype html>
2+
<html>
3+
<head>
4+
<meta charset="utf-8">
5+
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
6+
7+
<title>Q&A sessions - Coders School</title>
8+
9+
<meta name="description" content="Testing">
10+
<meta name="author" content="Łukasz Ziobroń">
11+
12+
<link rel="stylesheet" href="../../css/reset.css">
13+
<link rel="stylesheet" href="../../css/reveal.css">
14+
<link rel="stylesheet" href="../../css/theme/coders.css" id="theme">
15+
16+
<!-- Theme used for syntax highlighting of code -->
17+
<link rel="stylesheet" href="../../lib/css/monokai.css">
18+
19+
<!-- Printing and PDF exports -->
20+
<script>
21+
var link = document.createElement( 'link' );
22+
link.rel = 'stylesheet';
23+
link.type = 'text/css';
24+
link.href = window.location.search.match( /print-pdf/gi ) ? '../../css/print/pdf.css' : '../../css/print/paper.css';
25+
document.getElementsByTagName( 'head' )[0].appendChild( link );
26+
</script>
27+
</head>
28+
<body>
29+
<div class="reveal">
30+
<div class="slides">
31+
<section>
32+
<section data-background="#111111">
33+
34+
<h1>Q&A sessions</h1>
35+
36+
<a href="https://coders.school">
37+
<img width="500" data-src="../coders_school_logo.png" alt="Coders School" class="plain">
38+
</a>
39+
40+
<h3>Łukasz Ziobroń</h3>
41+
42+
</section>
43+
<section data-markdown>
44+
<textarea data-template>
45+
46+
## Agenda
47+
48+
1. <!-- .element: class="fragment fade-in" --> Scrum
49+
2. <!-- .element: class="fragment fade-in" --> Konkurs
50+
3. <!-- .element: class="fragment fade-in" --> Code review - przykłady
51+
4. <!-- .element: class="fragment fade-in" --> Pytania z kanału #Powtórka
52+
53+
</textarea>
54+
</section>
55+
</section>
56+
<!--
57+
Note that Windows uses `\r\n` instead of `\n` as its linefeed character.
58+
For a regex that supports all operating systems, use `\r?\n` instead of `\n`.
59+
Usage:
60+
Install dependencies
61+
$ npm install
62+
Serve the presentation and monitor source files for changes
63+
$ npm start
64+
Open http://localhost:8000 to view your presentation
65+
You can change the port by using npm start -- --port=8001.
66+
-->
67+
<section data-markdown="scrum.md"
68+
data-separator-vertical="^___"
69+
data-separator-notes="^Note:">
70+
</section>
71+
<section data-markdown="konkurs.md"
72+
data-separator-vertical="^___"
73+
data-separator-notes="^Note:">
74+
</section>
75+
<section data-markdown="code-review.md"
76+
data-separator-vertical="^___"
77+
data-separator-notes="^Note:">
78+
</section>
79+
<section data-markdown="repetition.md"
80+
data-separator-vertical="^___"
81+
data-separator-notes="^Note:">
82+
</section>
83+
<section data-background="#111111">
84+
85+
<h1>Coders School</h1>
86+
<img width="400" data-src="../logo.png" alt="Coders School" class="plain">
87+
88+
</section>
89+
</div>
90+
</div>
91+
92+
<script src="../../js/reveal.js"></script>
93+
94+
<script>
95+
// More info about config & dependencies:
96+
// - https://github.com/hakimel/reveal.js#configuration
97+
// - https://github.com/hakimel/reveal.js#dependencies
98+
Reveal.initialize({
99+
width: 1200,
100+
height: 750,
101+
slideNumber: true,
102+
hash: true,
103+
pdfSeparateFragments: false,
104+
dependencies: [
105+
{ src: '../../plugin/externalcode/externalcode.js', condition: function() { return !!document.querySelector( '[data-code]' ); } },
106+
{ src: '../../plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
107+
{ src: '../../plugin/markdown/marked.js' },
108+
{ src: '../../plugin/markdown/markdown.js' },
109+
{ src: '../../plugin/notes/notes.js', async: true }
110+
]
111+
});
112+
</script>
113+
</body>
114+
</html>

0 commit comments

Comments
 (0)