Skip to Content

Changes for page Functions

Last modified by chrisby on 2024/01/13 18:39
From version 1.4
edited by chrisby
on 2023/11/18 17:59
Change comment: There is no comment for this version
To version 1.5
edited by chrisby
on 2023/11/18 22:33
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,13 +1,11 @@
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 -* **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.
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 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.
4 4  
5 5  #### Function Arguments
6 6  
7 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.
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.
11 11  * Avoid flag arguments. It shows that the function performs two tasks, depending on whether the flag is true or false.
12 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 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/data structure.