Learn more about Java functions and much more.
Join the DZone community and get the full member experience.
Writing clean, understandable, easy-to-support, and maintain code is hard and requires many years of experience. At least we’re used to thinking this way. What if there is a way to write such a code consciously and without spending years and years developing these skills?
If we look into modern code, we’ll see methods and functions. A lot of them. They are the bread and butter of modern software, the basic building block. The quality of our functions almost completely defines the quality of our software. The problem is that nobody tells us how to write functions and methods. Of course, we can see tons and tons of articles and books, which tell us “do that”, and “don’t do this” while writing functions. But how exactly we should do that and don’t do this? Why we should or should not do this and that? There were no answers to those questions. (Note that the discussion below uses the terms “function” and “method” interchangeably because, for the discussion, the difference between methods and functions is irrelevant).
Writing code consciously means that we clearly understand how to write it and, more importantly, why it should be written in a specific way. Doing something consciously is possible only if we clearly understand the internals. With our current coding practices, functions are considered a black box, an atomic, indivisible element, and the question “what is inside the function” is carefully ignored. Let’s break this tradition and define that function has a specific structure. Quite interesting is that the idea of defining the function structure is not new, it just was not applied to regular code. Instead, writing tests using the “Given/When/Then” template is quite standard.
Before providing a more formal definition, I’d like to walk through quite typical Traditional Imperative Java code shown below:
The part of the function between lines 2 and 12 performs routine parameter checks typical for the methods/functions that are dealing with raw/unchecked input. Then, the part of the function at line 14 prepares intermediate data. Finally, the part of the function at line 16 performs the essential actions, i.e. do things that are declared by the method/function name. There is another, less obvious, but no less essential part spread across the whole function body: lines 3, 7, 11, and 18, which return error or actual calculated value.
Let’s call these parts “phases” and give them names according to what they implement inside this function (this is a crucial moment, I’ll return to it shortly). In total, we have 3+ phases:
With these names in mind, we are almost ready to write a more formal definition of the function structure. The last necessary element is the understanding that not every function contains all phases.
