Over the two decades I’ve come across a lot of Delphi projects.
All of them have one thing in common: even for functionality available in the Delphi libraries, much of that code was self-written.
You even see this in big libraries that have shipped with Delphi bit not originate from the Delphi team. Take Indy: lots of “roll your own” in it.
I’ve made some thoughts about that, and see these main causes with the points below.
What’s your thought on this?
Naming in the Delphi libraries is very confusing; there seem to be no (enforced or publicly available) naming guidelines within the Delphi R&D team (even though Charlie Calvert published one a long time ago), which makes it harder with the growth of the team:
No clear rule on when to (not) use abbreviations. We’ve had code completion for almost two decades, so why abbreviate?
Just take a look at SysUtils:
Int or Integer
Str or String (like DateTimeToStr vs DateTimeToString and many others),
Rec or Record (like Int64Rec vs TExceptionRecord).
Curr or DateTime (Curr is *not* the current DateTime!)
F or Fmt or Format (note sometimes F means float!)
M isn’t mega (what happened to metric prefixes?)
Meaning of names is unclear for seemingly related functionality
LoadStr versus NewStr. They return different data types (string versus PString) and perform very different tasks.
Functionality in the Delphi libraries is either doubled, or only half done. For instance,
there is a StartsWith, but no EndsWith,
the implementations of StartsStr and EndsStr are not symmetric (see unit tests below) nor the documentation points to each other, their parameter order is the opposite of what you expect and use abbreviations.
Functionality has been broken or limited in use for a very long time. For instance,
the SOAP implementation still relies on WinINet, even though that has been deprecated for non-interactive applications and communications to servers (like for SOAP and REST). It should have been replaced by WinHTTP support, and a QC report has been in place since 2007.
Documentation on expected functionality is limited. There is the Delphi Unit Test project to show and set expectations, but that seems to have silently become dormant on BitBucket.
Lots of library functionality has taken more than one Delphi version to become stable or (even longer, if at all): mature. Companies don’t have enough time to wait for that, and roll the things they do need on their own.
ClientDataSets, DBX, SOAP, JSON and FMX are key examples of this. They have taken a long long time to mature. Even worse: some of these are now even deprecated or replaced.
A quick example on the issues with StartsWith, StartsStr and EndsStr:
It helps a lot when you write your own unit tests to set (and verify) expectations on even simple RTL functionality.
But writing these is time consuming, and should be the responsibility of the library vendor.
Notes:
I stopped reporting issues like these in QC (quality central) more than a year (the web interface is a dork, and the SOAP API is has a huge security issue: it is http-only, passing EDN credentials – giving access to all your Embarcadero information – over the line in plain text, and there have been no signs of improvement since I reported the security risks in April 2014).
I won’t publish bugs in JIRA quality as long as it is not publicly indexed by Google (like QC is/was).
Many other languages and libraries have good naming guidelines available.
Except for the naming conventions (which are dreadful!) I’ve limited the examples as they are all over the RTL, VCL and FMX frameworks in all Delphi versions. Hence the examples from the Delphi 2007 documentation: more modern Delphi versions have improved, but not far enough, and Delphi 2007 is still in use by lots of Delphi projects.
–jeroenFiled under: Delphi, Delphi 10 Seattle, Delphi 2007, Delphi 2009, Delphi 2010, Delphi XE, Delphi XE2, Delphi XE3, Delphi XE4, Delphi XE5, Delphi XE6, Delphi XE7, Delphi XE8, Development, Software Development
