P e r l    C o d i n g    C o n v e n t i o n s

1. Flow chart

   Before starting with implementation, a clear understanding of the project objectives is necessary, including being aware of that which the client did not or cannot express himself, because he is not aware of certain issues or intricacies or because unexpected needs appear as the product reaches maturity.
   However, clarity of objectives does not mean that detailed schemes must be produced at this stage, set in stone for all eternity, which would be fatal in most real world projects. The question is rather to avoid pitfalls of which correction may be so expensive that the whole project is jeopardized: Correction costs grow super-linearly along the project time line.

   There are different ways and tools to achieve this understanding.

   • In many projects the treatment flow is described using a "natural" language e.g. English, if it is the project language.
     Ideally, the editing tool will be a front end to a database that connects all kinds of requirements together e.g. user requirements, developer requirements, test specifications. It also may allow graphical descriptions.

   • In some projects a modelling language is used to describe the product. Some modelling tools are even able to automatically generate tests (specification), others the source code in programming languages like c, c++, Java.

   I believe that pure textual descriptions are insufficient: I need to visualize information. In examples below - which are simple in comparison to real world projects - I wrote flow charts with Libre Office.

   One issue - connected to the initial analysis step - to be briefly mentioned: The selection of an appropriate implementation language.
   In most projects in which I was involved, the decision had been made, before I joined the team. Did the decision always duly accounted for product characteristics? Obviously there are other constraints: technical ones (e.g. program environment, communication, hardware), soft ones (e.g. existing skills, developing tools). To elaborate of this topic would exceed by far my scope.

2. Form Follows Function (FFF)

   FFF is a term originally derived from design and architecture.
   Transposed into Software Development, it expresses the fact that , after client's wishes have been reviewed, coding should be nothing else than an accurate translation of the product specification into the selected language. As straightforward and simple as it can be.

   This principle can be realized in a drastic way, when the source code is automatically generated: In such cases, the decisive engineering step is to write a Model of the software product, using a Modelling language. The mathematical or logical nature of those models ensures in itself the necessary accuracy of formulation.
   

   If a programmer writes the code - which is the case I am interested in - , it should be as rigorously written as if using a modelling language, with the advantage that it is human readable (automatic generated codes do not care about readability).

   Extended Readability requires discipline, but it pays off, because most probably codes are reused, extended, modified, patched, transposed by third persons. (I heard of projects where C-codes are deliberately written in order to confuse readers as a "security measure", to prevent non initiates to use it, "if there were leaks". In my opinion, simply bad practice. )

   Fundamental premises of code readability are:

   1. Modularity
      Encapsulate each single meaningful unit.

      Each single meaningful treatment step should be encapsulated into a dedicated procedure (to be coded only once). Ideally a subroutine should not encompass more than 20-30 executable lines. Code decomposition stretches over several abstraction levels. Atomic treatments are unspecific and should be managed into general program libraries.

      Modularity also applies to data itself: Data that belongs together should be encapsulated accordingly. In examples below, I resort to following constructs:

      • Perl structures (for examples see also here)
        Perl struct is some kind of counterpart to C struct or C++ class (wherein a class is much more powerful feature).
        Perl struct is an extension activated, if package Class::Struc is linked - which takes place in following code line: use Class::Struct;

      • Perl references (for examples see also here)
        References are especially useful when passing data structures to procedures. Passing references saves time (no need to copy the structure into the procedure) and simplify the code (no need to return the modified values).

   2. Nomenclature
      Naming of variables, structures, functions should be easy to understand, unequivocal and consistent (the later aspect may be difficult to realize, if many programmers work together).

   3. Comments
      are more than the slavish repetition of what it already conveyed by the nomenclature itself. Comments are used to

      • Articulate the source text, enhance its structure
      • Deliver informations that cannot (easily) be extracted from the language syntax itself - so called meta-informations.

3. Non-Functional Informations

   Not uncommonly, clients neglect or at least underestimate non-functional aspects. When the product is up for release, it may in some unfavorable cases happen, that overlooked non-functional conditions become a bottle neck putting the project at stakes. Non-functional requirements describe how tasks are achieved - rather than which ones. Here a non exhaustive list:

   • Duration of tasks
   • Required amount of CPU memory to perform a task
   • Required amount of disk memory to store input/output information flows
   • Parallelization of tasks, if several CPU are available
   • Management of unspecified errors

   In most examples shown in the chapters below the duration of treatment is monitored - at least at an embryonic state.
   Processing times give a rough idea of where disruptions may occur or have occurred. Under circumstances, it may also provide an unspecific criteria to abort treatment - or part of it.

4. Pattern Matching

   Pattern Matching is rather a programing technique than a principle. However, it is intimately associated with the Perl language as one of its strongest feature - which definitely makes Perl first choice, when it comes to problems that can be expressed in those terms.

   Pattern matching allows complex data manipulations within a few lines of code without loss of flexibility: operations can be controlled by (search) options, pattern grouping and specific variables.

   It is no trivial task to recognize those situations when, by means of pattern matching statements, one simply needs to describe what one wants to get (declarative statements), instead of how to get it (imperative statements). In some cases it also becomes important to understand which steps the Perl compiler actually executes in the background.

5. History of updates
   Only the first and the last year of treatment are displayed.