Release RMC-06.02
(2024-04-29)
|
Contents
Description
Description
This section describes some basic development aspects of GBS.
Choice of Language
GBS is written in Perl.
I needed a language that will execute exactly the same on various computers (at that time Windows and
UNIX), without being depended on installed libraries.
When I started developing GBS in 2001 the best choice was Perl.
Should I start developing now I would probably chose Python.
Quality Assurance
perlcritic
Running perlcritic yields the following results for this version:
----
335 files.
5,603 subroutines/methods.
80,795 statements.
139,611 lines, consisting of:
15,423 blank lines.
36,049 comment lines.
68 data lines.
85,725 lines of Perl code.
2,346 lines of POD.
Average McCabe score of subroutines was 3.25.
0 violations.
Violations per file was 0.000.
Violations per statement was 0.000.
Violations per line of code was 0.000.
----
I do use function prototypes, but only with $ and @. Never with \.
Checks
Some proprietary programs (perlxref and perlcheck) are used to detect:
- Unused 'use' statements
- Missing 'use' statements
- Unused functions
- Missing functions
- Unused global variables
- Active (Uncommented) trace/debug statements
Help
Command help (--help) and
Help File All Commands are created directly from the code so there is
no mismatch.
Design Considerations
- It must be fast.
Hence command-line interface and no frills.
Some standard packages duplicated and reduced to cater only for Windows and Linux.
The Perl code is 'compiled' replacing comment-lines by blank lines and removing leading
white-space. This makes the files smaller and that reduces disk I/O and parsing.
- Only dependent on plain Perl with standard packages.
No extra CPAN installs. No separately installs of any utilities (except of course your
compiler-suite).
- Must run exactly the same on Windows and Linux.
- Straight forward. No exceptions.
- Keep it simple.
- TBS
|