I recently opened up an interesting piece of software from a github repository. I will leave it unnamed, as it serves as the trigger for this article, and demonstrates some poor practices I have often seen in legacy projects.
You might think that the assignment of types to variables and parameters would be a simple matter. You may find better, more obvious choices. When you simplify, you increase reliability and readability. I suggest that unless there is a seam with some external program, you will do well to use the types which are the most ordinary: integers, doubles, and strings.
There are certainly reasons to use more specialized types from the collection Delphi offers, but usually because of interface to other programs. For example, to replicate a C struct in a Delphi record, you will need specialized types. You must use ShortInt, Byte, or Int8 for char, and SmallInt for short int. And you will must declare your record as packed.
Staying Focused
But that is not my focus today. Most of us have done such things often enough to know the ins and outs of them. Rather, I want to address the unnecessary declaration of uncommon types. The open source project I mentioned does just that.
Inside most applications we write, we may never need to use an AnsiString rather than string. Or a UInt16 rather than an Integer. Yet in many legacy modules we find such things when there is no compelling need. These choices may not cause performance issues, but they needlessly reduce clarity and simplicity. You will add casts to quiet the proliferation of hints and warnings, especially in the newer compilers.
I see in the current project that the input is a text file you will parse. The output is a table of information in the UI. There is no rational reason to introduce any specialized variable types. They simply make the reader ask why was that done? So the reader goes off on a search for the reason. You may find, as in this case, no reason at all. Imagine a large legacy project filled with such mysteries. You have hundreds of thousands of lines of code littered with someone’s poor choices.
You will spend time you may need for other work. Though it is always good to clean up old code, you may have higher priorities. I do favor cleanup, but usually incremental work.
When you simplify code, you make it more maintainable. You will also find and eliminate existing defects. Please, let us try to make our code communicate clearly to those who must follow us.