Changes for page Functions

Summary

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

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Functions
	1	+Functions (todo)

Content

...	...	@@ -1,75 +1,37 @@
1		-## Functions
	1	+* **Functions should be small.** Maximum 20 lines. Blocks and indentations should also be short. Blocks within if, else, or while statements should be one line long. Presumably, a function call should be included. Indentation depths should not be greater than one or two levels.
	2	+* **One abstraction level per function.** The Stepdown Rule: Code should be easy to read top-down: Below a function should be its sub-functions going down one level of abstraction.
	3	+* **Switch statements.** They are unfortunately large. Rule of thumb: they can be tolerated if they appear only once, are used to create polymorphic objects, and are used behind an inheritance relationship so that they are invisible to the rest of the system.
2	2
3		-*
	5	+#### Function Arguments
4	4
5		-Small!
6		- * Maximum 20 lines.
7		- * Blocks and indentations should also be short. Blocks within if, else, or while statements should be one line long. Presumably, a function call should be included.
8		- * Indentation depths should not be greater than one or two levels.
9		-*
	7	+* The fewer arguments the better. Triads should be avoided. More than three arguments are forbidden. The fewer arguments a function takes, the easier it is to understand and the less error-prone it is.
	8	+* Common monadic functions:
	9	+ * ask the argument a question or manipulate/convert it
	10	+ * events: one input, no output, reader should recognize that it is about an event by the functions context and name→ Otherwise, rather not use monadic functions.
	11	+* Avoid flag arguments. It shows that the function performs two tasks, depending on whether the flag is true or false.
	12	+* Dyads should be converted to monads if possible, but cannot always be avoided. Sometimes they are also useful, e.g. when passing 2D coordinates, because the arguments are connected by a cohesion.
	13	+* Argument objects: If many arguments are to be passed to a function, it often makes sense to combine them as a separate concept in a new class.
	14	+* Verbs and keywords: Function names can form a logical combination with the arguments, such as "write(name)", or you can integrate the arguments into the function name, e.g. to avoid interchanges.
10	10
11		-Functions should do one task.
12		- * They should do it well. They should do only that task.
13		- * All instructions within the function should be on the same abstraction level. Sub-functions perform tasks which are one abstraction-level deeper.
14		- * Sections within a function are symptoms that it performs more than one task. These function should be decomposed.
15		-*
	16	+#### **One Task Per Function**
16	16
17		-One abstraction level per function
18		- * The Stepdown Rule: Code should be easy to read top-down: Below a function should be its sub-functions going down one level of abstraction.
19		-*
20		-
21		-Switch statements
22		- * They are unfortunately large. Rule of thumb: they can be tolerated if they appear only once, are used to create polymorphic objects, and are used behind an inheritance relationship so that they are invisible to the rest of the system.
23		-* Use descriptive names.
24		-*
25		-
26		-Function arguments
27		- * The fewer the better. Triads should be avoided. More than three arguments are forbidden. The fewer arguments a function takes, the easier it is to understand and the less error-prone it is.
28		- *
29		-
30		-Common monadic functions:
31		- *
32		- * ask the argument a question or manipulate/convert it
33		- *
34		-
35		-events: one input, no output, reader should recognize that it is about an event by the functions context and name
36		-
37		-→ Otherwise, rather not use monadic functions.
38		- * Avoid flag arguments. It shows that the function performs two tasks, depending on whether the flag is true or false.
39		- * Dyads should be converted to monads if possible, but cannot always be avoided. Sometimes they are also useful, e.g. when passing 2D coordinates, because the arguments are connected by a cohesion.
40		- * Argument objects: If many arguments are to be passed to a function, it often makes sense to combine them as a separate concept in a new class.
41		- * Verbs and keywords: Function names can form a logical combination with the arguments, such as "write(name)", or you can integrate the arguments into the function name, e.g. to avoid interchanges.
42		-*
43		-
44		-Avoid side effects.
	18	+* They should do its task well. They should do only that task. All instructions within the function should be on the same abstraction level. Sub-functions perform tasks which are one abstraction-level deeper. Sections within a function are symptoms that it performs more than one task. These function should be decomposed.
	19	+* Avoid side effects.
45	45	* Functions should do only what their name says.
46	46	* Functions with output arguments, i.e. objects that are used as input and processed, should not be used. Instead, with a method of the object should be used to make it clear that the object itself is being processed.
47		-*
48	48
49		-Separate statement and query
50		- * Functions should either provide information about the object or do something, but not both.
51		-*
	23	+#### Material
52	52
53		-Exceptions are better than error codes (with if/else statements).
	25	+* Separate statement and query
	26	+ * Functions should either provide information about the object or do something, but not both.
	27	+* Exceptions are better than error codes (with if/else statements).
54	54	* Error.java is a dependency magnet with its enumeration of error codes and should be replaced with exceptions and derivations of the Exception class. → Easy extensibility (OCP)
55	55	* Extract try/catch blocks. Error processing is a task. So it deserves its own function.
56		-*
57		-
58		-DRY - Don't repeat yourself principle.
59		- * Duplications in the code and multiple uses can usually be avoided by abstractions.
60		-*
61		-
62		-Structured programming
	30	+* DRY - Don't repeat yourself principle.
	31	+ * Duplications in the code and multiple uses can usually be avoided by creating abstractions.
	32	+* Structured programming
63	63	* Small functions may occasionally contain return, break, and continue statements. goto statements would only make sense with large statements and should therefore be avoided.
64		-*
65		-
66		-How do you write good functions? → Always the same principle:
	34	+* How do you write good functions? → Always the same principle:
67	67	1. Write down thoughts, restructure, etc.
68		- 1.
69		-
70		-Refactoring until one is satisfied and passes all tests.
71		-
72		--> TODO: Usually you write dirty code first and then refactor until its clean. Nobody write clean code out of the blue.
	36	+ 1. Refactoring until one is satisfied and passes all tests.-> TODO: Usually you write dirty code first and then refactor until its clean. Nobody write clean code out of the blue.
73	73	* System are not programs to be written, but stories to be told. Everything must fit together.
74		-
75		-