Marco Tech Blog

October 14, 2010

Delphi's Spaghetti Code

In a LinkedIn Delphi group a provocative question "Is the vast majority of Delphi code in most organizations spaghetti?" has generated a rather interesting thread.

In a LinkedIn Delphi group a provocative question "Is the vast majority of Delphi code in most organizations spaghetti?" has generated a rather interesting thread.

The original question (by James) was: "Being a newbie, it seems as if Object-Oriented constructs didn't exist until very late in the maturity of Delphi. Does this make Delphi code harder to maintain for "new" developers than other languages?"

One of the first few answers (by Kirk) was up to the point: "Delphi was always object oriented. Any component architecture is, by definition, OO. This doesn't make it impossible to write bad code, and spaghetti is only one flavor of many possible bad code, but TObject was always the single ancestor object and interfaces, introduced in version 3 were added specifically to avoid multiple inheritance and all the problems which that entails. "

My two comment follow:

Marco Cantu' • "Delphi let's you use a pure OOP coding style or a visual/RAD coding style. The latter can certainly drive towards spaghetti code. But you have options. The best option is to merge the two, use RAD for what it is worth, but without breaking OOP rules, write custom components (OOP), organize your class structures, add business and persistence layers, and much more. Used badly, it is not a good tool!"

Marco Cantu' • As for the original question, many organizations have Delphi code
without a good architecture, but all of the larger projects generally are quite good.
I'd say 30% might need a rather complete rewrite!

posted by marcocantu @ 10:18PM | 4 Comments [0 Pending]

4 Comments

Delphis Spaghetti Code

The problem isn't the tool, to some extent.

What I believe being true, however, is that many
developers fail in getting the detail bits right and
that can, on larger projects, be a real stomach blow.

How many times have we seen code such as a MessageDlg
call in datamodules or class bodies instead of an
event handler in a form?

That is, put in perspective, the real problem imho :-)

Andrew

Comment by Andrea Raimondi on October 15, 06:48

Delphi's Spaghetti Code

I would have to say that this is problem is larger
than Delphi. It seems like the more shallow a
language's learning curve, the more examples of poorly
written code you will find. I think the problem stems
from novice developers churning out programs with
little regard for maintainability.

Let's face it. It's mind-numbingly simple to sit down
in front of a RAD IDE, drop a few controls on a form,
double-click them and start typing away. A business
expert with no development experience at all can do
that. Unfortunately the fastest way to write a program
is rarely the best.

And even so called "experienced" developers are guilty
of this. Tenure is no substitute for thoughtful
deliberate design. I've had the misfortune of working
with "veteran" developers who stopped trying to
improve their development skills the day they landed
their first job twenty years ago and have been
shoveling heaping piles of cow dung onto end users
ever since.

Comment by codeelegance [http://codeelegance.blogspot.com] on October 15, 18:47

Delphis Spaghetti Code

I think the real problem lies more on not having a 
strong architecture for the application. If the 
architecture is stong and developers tend to follow 
it there are lesser chances of ending up with the 
spaghetti code. For this I can share one real life 
example that happened to me when I was working on a 
project in my previous organization - we were 
required to get a new feature implemented as 
configurable and stored in windows registry for which 
we were ofcourse not aware that something in the 
architecture already exists so we wrote a whole lot 
of code to do that but when it went for the review 
phase it got caught as we clearly didn't followed the 
architecture and were reverted with a suggestion of 
changing certain set of variables and the thing would 
be done.

Therefore if newcomers would be having a good 
understanding of the strong application architecture 
the problem will get resolved to a large extent. 
Another problem could be the frequently changing 
requirements from customers which many times make 
developers follow their own set of rules to get 
things done ontime leading to a very bad code.

One more thing though I find in many discussions and 
clearly doubt is - 'Don't touch if it works' scenario 
with a project which makes refactoring the code hard 
to implement when required at many places. Ofcourse 
certain things have been written many years ago but 
the requirements have changed a lot today for the 
same application and though the code written years 
back still works fine but to make things cleaned up 
today sometimes we need to touch the existing working 
code so that the code is still maintainable and we 
can keep the spaghetti away. So, I really dont think 
that all these scenario's are very much specific to 
Delphi as these can occur at anytime with any other 
language.

Comment by Abhinav [http://neo-delphi.blogspot.com/] on October 23, 13:21

Delphi and Spaghetti Code

In rereading my original comment, I realized that I 
didn't finish my train of thought.  I wrote:

"My first project was porting a VB app due to poor 
performance (being an interpreted language) to Delphi 
2. On another app, I wanted to drop down a certain 
combo box, and the .dropped property didn't yet exist, 
so I researched the message generated when the user 
clicked on the down arrow and sent it to that control 
by using the handle property, which worked as 
intended."

Simply sending this message in the event handler is 
RAD.  If I wanted to make it OO, I would have created 
a new property, DroppedDown, and used the setter code 
to send the message, then back in the original event 
handler set that property to true.  It would have 
lacked the getter method but this would have sufficed 
for that project.

Comment by Kirk Halgren on October 24, 11:09

Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.