Skip to Content

Changes for page Functions

Last modified by chrisby on 2024/01/13 18:39
From version 1.16
edited by chrisby
on 2023/12/06 09:29
Change comment: There is no comment for this version
To version 1.9
edited by chrisby
on 2023/11/18 23:20
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -3,8 +3,7 @@
3 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 4  * **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.
5 5  * **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.
6 -* **The flow of reading should follow the flow of control.** The flow of control is the chronological order in which code is executed. The order of the functions should be adjusted accordingly. [[Here|doc:.Function Ordering Example.WebHome]] is an example.
7 -* **Separate statement and query.** Functions should either provide information about an object or do something with an object, but not both.
6 +* S**eparate statement and query.** Functions should either provide information about an object or do something with an object, but not both.
8 8  * **Exceptions are better than error codes** (with if/else statements).
9 9   * 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.
10 10   * Extract try/catch blocks. Error processing is a task. So it deserves its own function.
... ... @@ -27,4 +27,4 @@
27 27  * **Avoid flag arguments.** It shows that the function performs two tasks, depending on whether the flag is true or false.
28 28  * **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.
29 29  * **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.
30 -* **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, such as `writeName(name)`, to make it more readable.
29 +* **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.