HaMster21 · August 29, 2015 14:03 · Jul 3, 2014 · Jul 3, 2014 · Jul 3, 2014 · Jul 3, 2014
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -24,5 +24,5 @@
 
 #####Best Practices
 * ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)) did you use unnecessary repetition?
-* ([KISS](https://en.wikipedia.org/wiki/KISS_principle)) can your written in a more obvious way? Are functions doing trivial things?
+* ([KISS](https://en.wikipedia.org/wiki/KISS_principle)) can your code be written in a more obvious way? Are functions doing trivial things?
 * ([SOLID](https://en.wikipedia.org/wiki/SOLID)) are you following SOLID principles?
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,5 +1,3 @@
-### Commit / Pull Request checklist
-
 #####General
 * Are all files added that are needed to build the code?
 * Does the change comply to project conventions (naming, repo structure, license, documentation, etc.)?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -27,4 +27,4 @@
 #####Best Practices
 * ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)) did you use unnecessary repetition?
 * ([KISS](https://en.wikipedia.org/wiki/KISS_principle)) can your written in a more obvious way? Are functions doing trivial things?
-* ([SOLID](https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) are you following SOLID principles?
+* ([SOLID](https://en.wikipedia.org/wiki/SOLID)) are you following SOLID principles?
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -27,4 +27,4 @@
 #####Best Practices
 * ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)) did you use unnecessary repetition?
 * ([KISS](https://en.wikipedia.org/wiki/KISS_principle)) can your written in a more obvious way? Are functions doing trivial things?
-* ([SOLID])(https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) are you following SOLID principles?
+* ([SOLID](https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) are you following SOLID principles?
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -25,4 +25,6 @@
 * Can the livetime and and scope of the ressource be further restricted?
 
 #####Best Practices
-* ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)) did you use unnecessary repetition?
+* ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)) did you use unnecessary repetition?
+* ([KISS](https://en.wikipedia.org/wiki/KISS_principle)) can your written in a more obvious way? Are functions doing trivial things?
+* ([SOLID])(https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) are you following SOLID principles?
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -24,3 +24,5 @@
 * Can the ressource be allocated on the stack?
 * Can the livetime and and scope of the ressource be further restricted?
 
+#####Best Practices
+* ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)) did you use unnecessary repetition?
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -24,5 +24,3 @@
 * Can the ressource be allocated on the stack?
 * Can the livetime and and scope of the ressource be further restricted?
 
-- [ ] __Conventions Consistency__ Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
-- [ ] __Security__: There is a whole threat and mitigation review process that falls under this bucket. 
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,20 +1,28 @@
 ### Commit / Pull Request checklist
 
+#####General
+* Are all files added that are needed to build the code?
+* Does the change comply to project conventions (naming, repo structure, license, documentation, etc.)?
+
 #####Tests
 * Is the code tested?
 * Are the tests showing the intention how to use the code?
 * Is the expected behavior clear?
 * Are there gaps that also need testing?
 
 #####Functions and Methods
-  * Is the name reflecting the behavior / expected result?
-  * Are parameters validated, if any?
-  * Do parameters make sense? Or is there a way to get rid of them?
-  * Does the return value make sense?
-  * Is global state changed? Are pure/safe/trusted functions declared as such?
-  * Can the function / method take the parameter by reference? Is the parameter mutated?
+* Is the name reflecting the behavior / expected result?
+* Are parameters validated, if any?
+* Do parameters make sense? Or is there a way to get rid of them?
+* Does the return value make sense?
+* Is global state changed? Are pure/safe/trusted functions declared as such?
+* Can the function / method take the parameter by reference? Is the parameter mutated?
+
+#####Objects
+* Are referenced ressources cleaned up?
+* Where and when are `null` references possible? Are those circumstances evaluated and / or tested?
+* Can the ressource be allocated on the stack?
+* Can the livetime and and scope of the ressource be further restricted?
 
-- [ ] __Null References__ (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
 - [ ] __Conventions Consistency__ Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
-- [ ] __Disposables__ Make sure disposable things are disposed. Look for usages of resources that should be disposed but are not.
 - [ ] __Security__: There is a whole threat and mitigation review process that falls under this bucket. 
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,12 +1,12 @@
 ### Commit / Pull Request checklist
 
 #####Tests
-  * Is the code tested?
-  * Are the tests showing the intention how to use the code?
-  * Is the expected behavior clear?
-  * Are there gaps that also need testing?
+* Is the code tested?
+* Are the tests showing the intention how to use the code?
+* Is the expected behavior clear?
+* Are there gaps that also need testing?
 
-######Functions and Methods
+#####Functions and Methods
   * Is the name reflecting the behavior / expected result?
   * Are parameters validated, if any?
   * Do parameters make sense? Or is there a way to get rid of them?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,12 +1,12 @@
 ### Commit / Pull Request checklist
 
-####Tests
+#####Tests
   * Is the code tested?
   * Are the tests showing the intention how to use the code?
   * Is the expected behavior clear?
   * Are there gaps that also need testing?
 
-####Functions and Methods
+######Functions and Methods
   * Is the name reflecting the behavior / expected result?
   * Are parameters validated, if any?
   * Do parameters make sense? Or is there a way to get rid of them?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,4 +1,4 @@
-## General
+### Commit / Pull Request checklist
 
 ####Tests
   * Is the code tested?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,12 +1,12 @@
 ## General
 
-###Tests
+####Tests
   * Is the code tested?
   * Are the tests showing the intention how to use the code?
   * Is the expected behavior clear?
   * Are there gaps that also need testing?
 
-###Functions and Methods
+####Functions and Methods
   * Is the name reflecting the behavior / expected result?
   * Are parameters validated, if any?
   * Do parameters make sense? Or is there a way to get rid of them?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,12 +1,12 @@
 ## General
 
-- Tests
+###Tests
   * Is the code tested?
   * Are the tests showing the intention how to use the code?
   * Is the expected behavior clear?
   * Are there gaps that also need testing?
 
-- Functions and Methods
+###Functions and Methods
   * Is the name reflecting the behavior / expected result?
   * Are parameters validated, if any?
   * Do parameters make sense? Or is there a way to get rid of them?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,12 +1,12 @@
 ## General
 
-- __tests__
+- Tests
   * Is the code tested?
   * Are the tests showing the intention how to use the code?
   * Is the expected behavior clear?
   * Are there gaps that also need testing?
 
-- __functions and methods__
+- Functions and Methods
   * Is the name reflecting the behavior / expected result?
   * Are parameters validated, if any?
   * Do parameters make sense? Or is there a way to get rid of them?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,18 +1,18 @@
 ## General
 
-- [ ] __tests__
+- __tests__
   * Is the code tested?
   * Are the tests showing the intention how to use the code?
   * Is the expected behavior clear?
   * Are there gaps that also need testing?
 
-- [ ] __functions and methods__
-  - Is the name reflecting the behavior / expected result?
-  - Are parameters validated, if any?
-  - Do parameters make sense? Or is there a way to get rid of them?
-  - Does the return value make sense?
-  - Are pure/safe/trusted functions declared as such? Is global state changed?
-  - Can the function / method take the parameter by reference? Is the parameter mutated?
+- __functions and methods__
+  * Is the name reflecting the behavior / expected result?
+  * Are parameters validated, if any?
+  * Do parameters make sense? Or is there a way to get rid of them?
+  * Does the return value make sense?
+  * Is global state changed? Are pure/safe/trusted functions declared as such?
+  * Can the function / method take the parameter by reference? Is the parameter mutated?
 
 - [ ] __Null References__ (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
 - [ ] __Conventions Consistency__ Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,10 +1,10 @@
 ## General
 
 - [ ] __tests__
-  - Is the code tested?
-  - Are the tests showing the intention how to use the code?
-  - Is the expected behavior clear?
-  - Are there gaps that also need testing?
+  * Is the code tested?
+  * Are the tests showing the intention how to use the code?
+  * Is the expected behavior clear?
+  * Are there gaps that also need testing?
 
 - [ ] __functions and methods__
   - Is the name reflecting the behavior / expected result?

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,13 +1,19 @@
 ## General
 
-- [ ] __Unit tests__
+- [ ] __tests__
   - Is the code tested?
   - Are the tests showing the intention how to use the code?
   - Is the expected behavior clear?
   - Are there gaps that also need testing?
 
-- [ ] __Method arguments__
-Make sure arguments to methods make sense and are validated.
+- [ ] __functions and methods__
+  - Is the name reflecting the behavior / expected result?
+  - Are parameters validated, if any?
+  - Do parameters make sense? Or is there a way to get rid of them?
+  - Does the return value make sense?
+  - Are pure/safe/trusted functions declared as such? Is global state changed?
+  - Can the function / method take the parameter by reference? Is the parameter mutated?
+
 - [ ] __Null References__ (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
 - [ ] __Conventions Consistency__ Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
 - [ ] __Disposables__ Make sure disposable things are disposed. Look for usages of resources that should be disposed but are not.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,8 +1,10 @@
 ## General
 
 - [ ] __Unit tests__
-
-Is the code tested? Are the tests showing the intention how to use the code? Are there gaps that also need testing? Is the expected behavior clear?
+  - Is the code tested?
+  - Are the tests showing the intention how to use the code?
+  - Is the expected behavior clear?
+  - Are there gaps that also need testing?
 
 - [ ] __Method arguments__
 Make sure arguments to methods make sense and are validated.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,7 +1,9 @@
 ## General
 
 - [ ] __Unit tests__
+
 Is the code tested? Are the tests showing the intention how to use the code? Are there gaps that also need testing? Is the expected behavior clear?
+
 - [ ] __Method arguments__
 Make sure arguments to methods make sense and are validated.
 - [ ] __Null References__ (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,8 +1,10 @@
 ## General
 
-- [ ] __Unit tests__: Is the code tested? Are the tests showing the intention how to use the code? Are there gaps that also need testing? Is the expected behavior clear?
-- [ ] __Method arguments__" Make sure arguments to methods make sense and are validated.
-- [ ] __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
-- [ ] __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
-- [ ] __Disposables__: Make sure disposable things are disposed. Look for usages of resources that should be disposed but are not.
+- [ ] __Unit tests__
+Is the code tested? Are the tests showing the intention how to use the code? Are there gaps that also need testing? Is the expected behavior clear?
+- [ ] __Method arguments__
+Make sure arguments to methods make sense and are validated.
+- [ ] __Null References__ (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
+- [ ] __Conventions Consistency__ Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
+- [ ] __Disposables__ Make sure disposable things are disposed. Look for usages of resources that should be disposed but are not.
 - [ ] __Security__: There is a whole threat and mitigation review process that falls under this bucket. 
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,6 +1,6 @@
 ## General
 
-- [ ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
+- [ ] __Unit tests__: Is the code tested? Are the tests showing the intention how to use the code? Are there gaps that also need testing? Is the expected behavior clear?
 - [ ] __Method arguments__" Make sure arguments to methods make sense and are validated.
 - [ ] __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
 - [ ] __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,15 +1,8 @@
 ## General
 
-[   ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
-2. __Method arguments__" Make sure arguments to methods make sense and are validated.
-3. __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
-4. __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
-5. __Disposables__: Make sure disposable things are disposed. Look for usages of resources that should be disposed but are not.
-6. __Security__: There is a whole threat and mitigation review process that falls under this bucket. 
-
-## WPF + ReactiveUI
-
-1. __Updating UI__: Make sure view model properties are updated on the main scheduler (UI thread). This is because we bind the UI to these properties and the UI can only be updated on the UI thread.
-2. __ObserveOn__: When kicking off truly async operations, make sure we `ObserveOn(RxApp.DeferredScheduler)` soon after (related to previous).
-3. __Over subscriptions__: Make sure we're not over subscribing to deferred observables etc that could lead to multiple operations.
-4. ???
+- [ ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
+- [ ] __Method arguments__" Make sure arguments to methods make sense and are validated.
+- [ ] __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
+- [ ] __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
+- [ ] __Disposables__: Make sure disposable things are disposed. Look for usages of resources that should be disposed but are not.
+- [ ] __Security__: There is a whole threat and mitigation review process that falls under this bucket. 
diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,6 +1,6 @@
 ## General
 
-[  ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
+[   ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
 2. __Method arguments__" Make sure arguments to methods make sense and are validated.
 3. __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
 4. __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,6 +1,6 @@
 ## General
 
-[ ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
+[  ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
 2. __Method arguments__" Make sure arguments to methods make sense and are validated.
 3. __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
 4. __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -1,6 +1,6 @@
 ## General
 
-1. __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
+[ ] __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
 2. __Method arguments__" Make sure arguments to methods make sense and are validated.
 3. __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
 4. __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.

diff --git a/code-review-checklist.md b/code-review-checklist.md
@@ -0,0 +1,15 @@
+## General
+
+1. __Unit tests__: Review unit tests first. Unit tests are a fantastic way to grasp how code is meant to be used by others and to learn what the expected behavior is. Are there any test gaps that should be there?
+2. __Method arguments__" Make sure arguments to methods make sense and are validated.
+3. __Null References__" (Yah yah, we know. Use F# and this goes away. We get it already.) Null references are a bitch and it’s worth looking out for them specifically.
+4. __Conventions Consistency__" Make sure naming, formatting, etc. follow our conventions and are consistent. I like a codebase that’s fairly consistent so you know what to expect.
+5. __Disposables__: Make sure disposable things are disposed. Look for usages of resources that should be disposed but are not.
+6. __Security__: There is a whole threat and mitigation review process that falls under this bucket. 
+
+## WPF + ReactiveUI
+
+1. __Updating UI__: Make sure view model properties are updated on the main scheduler (UI thread). This is because we bind the UI to these properties and the UI can only be updated on the UI thread.
+2. __ObserveOn__: When kicking off truly async operations, make sure we `ObserveOn(RxApp.DeferredScheduler)` soon after (related to previous).
+3. __Over subscriptions__: Make sure we're not over subscribing to deferred observables etc that could lead to multiple operations.
+4. ???
No results found