Changes for page Clean Code

Summary

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

Details

Page properties

Content

...	...	@@ -14,12 +14,8 @@
14	14	*
15	15
16	16	Choose meaningful names.
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.
	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.
23	23	*
24	24
25	25	Choose names that are descriptive of the purpose.
...	...	@@ -147,11 +147,7 @@
147	147
148	148	How do you write good functions? → Always the same principle:
149	149	1. Write down thoughts, restructure, etc.
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.
	146	+ 1. Refactoring until one is satisfied and passes all tests.
155	155	* System are not programs to be written, but stories to be told. Everything must fit together.
156	156
157	157	## Comments
...	...	@@ -258,10 +258,7 @@
258	258	The method f should not call methods of objects returned by an allowed function. Speak to friends, not strangers.
259	259	* Don't use friend.getStranger().doStrangeStuff().
260	260	* Instead, the neighbor should provide a proper service: friend.callServiceInternallyUsingStranger()
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
	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()
265	265	* 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.
266	266	* 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.
267	267
...	...	@@ -350,12 +350,7 @@
350	350	*
351	351
352	352	Use code that doesn't exist yet.
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.
	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.
359	359	*
360	360
361	361	Clean boundaries
...	...	@@ -369,11 +369,8 @@
369	369	### Introduction
370	370
371	371	* 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.
372		-*
	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.
373	373
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		-
377	377	### Three laws of Test Driven Development (TDD)
378	378
379	379	1. You must not write production code until you have written a failing unit test.
...	...	@@ -937,4 +937,8 @@
937	937
938	938	* [Interesting article](https://research.swtch.com/deps) about dependencies. Solution: Create custom interface and thin wrapper between your application and the third party library.
939	939
	921	+###
940	940
	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.