Changes for page Functions

Summary

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

Details

Page properties

Content

...	...	@@ -1,11 +1,10 @@
1	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		-* **Functions should do one task.** They should do it 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.
3	3	* **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.
4	4	* **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.
5	5
6	6	#### Function Arguments
7	7
8		-* 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.
	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.
9	9	* Common monadic functions:
10	10	* ask the argument a question or manipulate/convert it
11	11	* 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.
...	...	@@ -14,11 +14,15 @@
14	14	* 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.
15	15	* 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.
16	16
17		-#### Material
	16	+#### **One Task Per Function**
18	18
	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	19	* Avoid side effects.
20	20	* Functions should do only what their name says.
21	21	* 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.
	22	+
	23	+#### Material
	24	+
22	22	* Separate statement and query
23	23	* Functions should either provide information about the object or do something, but not both.
24	24	* Exceptions are better than error codes (with if/else statements).
...	...	@@ -25,7 +25,7 @@
25	25	* 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)
26	26	* Extract try/catch blocks. Error processing is a task. So it deserves its own function.
27	27	* DRY - Don't repeat yourself principle.
28		- * Duplications in the code and multiple uses can usually be avoided by abstractions.
	31	+ * Duplications in the code and multiple uses can usually be avoided by creating abstractions.
29	29	* Structured programming
30	30	* Small functions may occasionally contain return, break, and continue statements. goto statements would only make sense with large statements and should therefore be avoided.
31	31	* How do you write good functions? → Always the same principle: