Changes for page Functions

Summary

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

Details

Page properties

Content

...	...	@@ -1,35 +1,35 @@
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' states that 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.
	1	+#### Structure and Size
4	4
5		-#### Function Arguments
	3	+* **Functions should be small.** Maximum 20 lines. Blocks and indentation should also be short. Blocks inside if, else, or while statements should be one line. A function call should probably be included. Indentation depths should be no more than one or two levels.
	4	+* **One abstraction level per function.** The 'stepdown rule' states that code should be easy to read from top to bottom: Under a function, its subfunctions should go down one level of abstraction.
	5	+* S**eparate statement and query.** Functions should either provide information about an object or do something with an object, but not both.
	6	+* **Exceptions are better than error codes** (with if/else statements).
	7	+ * Error.java is a dependency magnet with its enumeration of error codes and should be replaced by exceptions and derivatives of the Exception class, which allows easy extensibility in accordance with the Open-Closed Principle.
	8	+ * Extract try/catch blocks. Error processing is a task. So it deserves its own function.
6	6
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 1) ask the argument a question or manipulate/convert it 2) 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.
9		-* Avoid flag arguments. It shows that the function performs two tasks, depending on whether the flag is true or false.
10		-* 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.
11		-* 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/data structure.
12		-* 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	+* **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.
	11	+* **Functions should do only one task.** 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.
	12	+* **Avoid side effects.** Functions should only do what their name implies. Avoid functions with output arguments, i.e., where objects are used as input, processed, and returned. Instead, use a method of the object to make clear that the object itself is being processed.
	13	+*
13	13
14		-#### **One Task Per Function**
	15	+#### Practices and Principle
15	15
16		-* 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.
17		-* Avoid side effects.
18		- * Functions should do only what their name says.
19		- * 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.
	17	+* **Don't repeat yourself (DRY).** Code duplication and reuse can usually be avoided by creating abstractions that incorporate the shared code.
	18	+* **Structured programming.** Functions may occasionally contain return, break and continue statements. 'goto' statements would only make sense in large statements, and since the latter should be avoided, so should the former.goto statements would only make sense in large statements, and since the latter should be avoided, the former should be too.
	19	+* How do you write good functions?
	20	+ 1. Writing down thoughts, restructuring, etc., without worrying too much about making it pretty, but about making it work.
	21	+ 1. Refactoring until one is satisfied and the function passes all tests.
	22	+ * The first version of new code is always dirty. Clean code isn't written out of the blue; it evolves from a dirty design through continuous refactoring. Also see Test-Driven Development.
20	20
21		-#### Material
	24	+#### Function Arguments
22	22
23		-* Separate statement and query
24		- * Functions should either provide information about the object or do something, but not both.
25		-* Exceptions are better than error codes (with if/else statements).
26		- * 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)
27		- * Extract try/catch blocks. Error processing is a task. So it deserves its own function.
28		-* DRY - Don't repeat yourself principle.
29		- * Duplications in the code and multiple uses can usually be avoided by creating abstractions.
30		-* Structured programming
31		- * Small functions may occasionally contain return, break, and continue statements. goto statements would only make sense with large statements and should therefore be avoided.
32		-* How do you write good functions? → Always the same principle:
33		- 1. Write down thoughts, restructure, etc.
34		- 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.
35		-* System are not programs to be written, but stories to be told. Everything must fit together.
	26	+* **The fewer arguments, the better.** Triads should be avoided. More than three arguments are not allowed. The fewer arguments a function takes, the easier it is to understand and the less error-prone it is.
	27	+* There are two common types of monadic functions:
	28	+ *
	29	+ 1. Monad that asks the argument a question or manipulates/converts it.
	30	+ *
	31	+ 1. Events = monads with no return value. The reader should recognize that it is an event by the functions context and name→ Otherwise, do not use monadic functions.
	32	+* **Avoid flag arguments.** It shows that the function performs two tasks, depending on whether the flag is true or false.
	33	+* **Dyads should be converted to monads if possible**, but cannot always be avoided. Sometimes they are useful, e.g. when passing 2D coordinates, because the arguments are connected by a cohesion.
	34	+* **Argument objects:** When many arguments are to be passed to a function, it often makes sense to combine them as a separate concept in a new class/data structure.
	35	+* **Verbs and keywords**: Function names can form a logical combination with the arguments, such as "write(name)", or you can include the arguments in the function name, e.g. to avoid confusion.