Changes for page Clean Code

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -14,8 +14,12 @@
14	14	*
15	15
16	16	Choose meaningful names.
17		- * Names should be chosen as carefully as the name of his firstborn child.
18		- * Implicity: It should be self-evident from reading the code how it works.
	17	+ *
	18	+
	19	+Names should be chosen as carefully as the name of his firstborn child.
	20	+ *
	21	+
	22	+Implicity: It should be self-evident from reading the code how it works.
19	19	*
20	20
21	21	Choose names that are descriptive of the purpose.
...	...	@@ -143,7 +143,11 @@
143	143
144	144	How do you write good functions? → Always the same principle:
145	145	1. Write down thoughts, restructure, etc.
146		- 1. Refactoring until one is satisfied and passes all tests.
	150	+ 1.
	151	+
	152	+Refactoring until one is satisfied and passes all tests.
	153	+
	154	+-> TODO: Usually you write dirty code first and then refactor until its clean. Nobody write clean code out of the blue.
147	147	* System are not programs to be written, but stories to be told. Everything must fit together.
148	148
149	149	## Comments
...	...	@@ -250,7 +250,10 @@
250	250	The method f should not call methods of objects returned by an allowed function. Speak to friends, not strangers.
251	251	* Don't use friend.getStranger().doStrangeStuff().
252	252	* Instead, the neighbor should provide a proper service: friend.callServiceInternallyUsingStranger()
253		-* Train catastrophe: train wrecks should be avoided and, if necessary, split by defining new variables as intermediate storage. E.g. don't use obj1.getObj2().getObj3().getObj4()
	261	+*
	262	+
	263	+Train catastrophe: train wrecks should be avoided and, if necessary, split by defining new variables as intermediate storage. E.g. don't use obj1.getObj2().getObj3().getObj4()
	264	+ * -> Maybe for clarification, trains are okay e.g. for functional programming, but not when you walk through a lot of objects/units of your code. Coupling would be high. -> stiffness
254	254	* Hybrids are present when classes contain public variables or public accessors/mutators for private variables and thus reveal them. This is also referred to as feature envy because these hybrids can be treated similarly to data structures. Avoid such structures. They have the disadvantages from both concepts because they make it difficult to add new features as well as new data structures.
255	255	* Hide structure: If you know too much about an object, e.g. because you use train wrecks, you should replace them with structures that do not reveal any information about the object.
256	256
...	...	@@ -339,7 +339,12 @@
339	339	*
340	340
341	341	Use code that doesn't exist yet.
342		- * If you haven't written the API yet, it makes sense to set up a desired interface for how the API should work. This will provide a clean separation. In the end, you can use an adapter to close the bridge between the desired interface and the API. -> TODO: To be explained in detail.
	353	+ *
	354	+
	355	+If you haven't written the API yet, it makes sense to set up a desired interface for how the API should work. This will provide a clean separation. In the end, you can use an adapter to close the bridge between the desired interface and the API.
	356	+ *
	357	+ * Explanation of the last sentence: Once the actual API is built, there may be differences between the initially designed interface and the final implementation. An adapter is a design pattern that can be used to reconcile these differences. It allows the existing interface to be used without modifying the actual API, essentially translating calls from the interface to the API and vice versa.
	358	+ * I am really not sure about that last sentence. Better re-read it.
343	343	*
344	344
345	345	Clean boundaries
...	...	@@ -353,8 +353,11 @@
353	353	### Introduction
354	354
355	355	* Every detail of the code should be meticulously checked for functionality. This means that results are checked for correctness and inner variables (even at runtime) are compared with expected values. The entire definition and value space should be tested.
356		-* Tests should work as well as explicitly fail for the tests to be considered passed. Positive results show that the function does what it is supposed to, negative results show that the function observes limits.
	372	+*
357	357
	374	+Tests should work as well as explicitly fail for the tests to be considered passed. Positive results show that the function does what it is supposed to, negative results show that the function observes limits.
	375	+ * own: I think it is important to handle negative results as well as the classes should handle them in a very specific manner which is part of its expected behavior as well.
	376	+
358	358	### Three laws of Test Driven Development (TDD)
359	359
360	360	1. You must not write production code until you have written a failing unit test.
...	...	@@ -918,8 +918,4 @@
918	918
919	919	* [Interesting article](https://research.swtch.com/deps) about dependencies. Solution: Create custom interface and thin wrapper between your application and the third party library.
920	920
921		-###
922	922
923		-### Material
924		-
925		-Talk to neighbors, not to strangers. -> Visualisierung wäre nice. Kein Method Chaining. Keine dependencies via Getter verfügbar machen. Besser ein Object mit einer Abstrakten Methode nutzen, die macht, was ich will. Problem ist halt das starke Coupling in der Chain, was refactoring erschwert.