Delphi - How can i improve

Question

Ok, so ive been programming in Delphi for 3-4 years now and consider myself an intermediate level application designer with a sound understanding of concepts. But how do i get better? Ive just been looking at the source of a couple of components i use quite often (virtualtreeview,asynccalls) and the code in there just stumps me. Yes i can understand parts of it, but other things just go right over my head.

So where are the best resources to improve my programming abililty? Books, blogs or other sources of information?

Answer 1

Programming skills are like muscles; the best way to improve them is by exercising them. If you want to learn to be a better coder, work on a harder project than you've worked on before. Come up with an idea for something you'd like to write, but don't really know how to do, and start writing. Once you run up against concepts that you don't understand, research them, and you'll end up adding new concepts and skills to your repertoire.

Answer 2

Understanding code that uses concepts you're not familiar with is hard. My advice:

• Pick one or two projects that you don't understand, and re-implement them. From your question, try writing your own tree (or list) component, and try writing a simple threading framework where you can dispatch jobs and get their work back at a certain point. These are simplified versions of the two projects you mentioned.

  As a programmer, you learn by doing. No amount of theory will make up for the experience of having tackled and solved a problem. [*]

  When you tackle both these problems, you'll encounter some of the same problems the authors of Virtual Treeview and AsyncCalls did. (If you have trouble, ask here on SO!) Not only will you learn the same things they've learned but you'll probably come back and re-read their code and understand some of the things they're doing.

  Don't be tempted by the fact you have working implementations of the concepts around (the original projects) and copy code - feel free to look at it for inspiration, but don't copy it. Write it yourself.

  Remember that both Mike Lischke and Andreas Hausladen are very smart people. Don't be disheartened if it's hard work. Many programmers go their entire careers just being competent (as it sounds you are) without pushing themselves to try or learn something harder (so if you don't mind me saying so, good for you for asking the question!)

A couple of other ideas:

• Learn another language. Delphi's great, but you 'think' in a language, and so if you learn another language well you will be exposed to other concepts or ways of thinking, or different ways of doing the same thing. This really opens your mind.

  For example, C++ is great for use of RAII, template metaprogramming (this is more powerful than what Delphi's templates allow), some quite amazing things in the various extra libraries such as boost, and shooting yourself in the foot :) A functional language will completely change how you think (and I have to admit to being a bit hypocritical here: I've been exposed to them but don't 'know' any myself. I want to.) Objective C might be good for a different take on what object-orientation means (it and C++ are both object-oriented C-based languages, but very different.) You get the idea.

• For looking at those specific projects: one answer on this page advised going through it line-by-line. I find to understand code I haven't used before this can be overwhelming. I once read on an Embarcadero staff member's blog some advice to use a profiler, because it will give you a good high-level view of (a) all the classes/methods/parts of a program and (b) which are the most commonly used, and probably most essential, parts, and how it all hooks together. I can't take credit for that suggestion but I think it's good advice. I recommend using AQTime.

  It's for this reason I find answers like 'find Foo, study the source' unhelpful: you're a coder, of course you'll look at the source! How to look at the source, that's a more interesting question.

• Finally, if you get to the point where you've been "looking at the source of a couple of [projects] and the code in there just stumps [you]" or if you do some of the above and don't understand something, ask here on SO!

[*] Footnote: I'm not advocating not knowing the underlying theory, just that there's a knowledge / confidence you get by doing something yourself that's essential.

Answer 3

You must read these articles from Steve Trefethen :

• Delphi IDE Wisdom
• Delphi RTL and Language Wisdom
• Delphi VCL Wisdom
• Delphi community wisdom

that provide a great summary of topics that a good developer in Delphi should handle

  

Answer 4

I think you would grow a lot in your delphi abilities if you:

1. Learn to Build Components. Read Ray Konopka's book on Custom delphi Components, or his EDN article.

2. Study the JEDI JVCL and JEDI JCL sources. The Jedi API libraries and the JWSCL are also valuable, as a source of information. The MSDN documentation (Microsoft) is invaluable also, as a source of platform documentation for the various Windows subsystems you will need to interact with.

3. Get a copy of Marco Cantu's giant Mastering Delphi book, or Texeira and Pacheco's Delphi Developer's Guide.

4. Learn about Test Driven Development, Unit Testing, Version Control (learn several systems, like Subversion, Git, Mercurial, etc), Continuous Integration, and other professional-grade techniques.

Answer 5

The best way (for me) to understand how code works that I can't follow from looking at the code alone is to get down and dirty and observe the code in question. Put a number of breakpoints down and start tracing through the code while it is running.

The more you do this, the more your ability to later follow code from just looking at it improves.

In addition, you haven't done so yet, I would strongly suggest a read through of the following book:

Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2)

Written in 1994 it is still as relevant today as it was back then (if not more).

The important thing about it is that it teaches you to recognize certain patterns in code and gives you a vocabulary to describe what whole sections of code do with just a single term.

In the model you build in your mind about what some complex piece of code does and how it interacts, you the no longer have to keep all the minute details, instead you can build a higher level abstraction in your mind where you describe the code to yourself as the interaction of functional blocks based on certain design patterns.

This naturally assumes that the code in question is well designed. Sometimes some code simply is a totally mess that can make spaghetti jealous and an inability on your part of following and understanding the code is not a failure of yours, but of the person who wrote the code.

Answer 6

If you want to figure out code that isn't yours, you have to start out and get down and dirty. Break out the parts of the code that you want to understand into a "minimal" program, and debug through it line by line. Most often, that will tell you what is going on at the low levels. Sometimes that alone will give you the understanding you need.

But then when you get stumped by how the code constructs work, then enter parts of the offending lines into Google for an answer. That will often lead you to blog posts or articles that are discussing similar code that explain the concepts and how the code works.

Sometimes I go to Google Code Search and select the Pascal/Delphi language to search through. I find the code here gives a different perspective and often has comments and other information that helps to understand the ideas.

If I can't figure it out other ways, I come to StackOverflow which is a fantastic resource for Delphi information from very knowledgeable and experience Delphi programmers. If it's something you, as an already intermediate programmer cannot figure out, then it will probably make a pretty good question here at SO, and you'll get some excellent answers back in short order that I'm sure will help your understanding and learning.

Answer 7

Programing is complex.

Typical RAD application has forms with code in event handlers, datamodules with queries and not a single class.

You can write hundreds of apps like that and learn nothing other than how to use various components and their properties and events.

This is the main problem with Delphi, it's easy and natural to do things the wrong way. RAD = BAD. Sadly, probably 90% of applications are written like that.

So what's wrong with this approach ? It's missing any architecture. Why is that bad ? It is not change resistant. When your requirements change you will have to make more changes than you would with a properly designed app.

It is by now well accepted that applications should be structured into layers.

Typical separation of layers is

• Business objects/rules
• Data mapping/persistence
• GUI

With cleanly separated Business layer you can have Win32 GUI, Web GUI, Mobile device GUI...

With cleanly separated Persistence layer you can have the same Business and GUI layers yet switch from say Interbase to Postgress.

It is also much easier to write tests.

Now let me warn you right now, this is a long and hard path to take. It will take take years to master and you will never be completely done.

When you make your app well designed and have these layers set up, and you get it to work, and you excitedly show it to your colleagues, they will give you a strange look and say: Well I just drop this query on the form, execute and it looks the same. But you will know better.

I don't agree with suggestions to learn another language. That is, IMHO, just bypassing the problem. The skill to properly organize and structure your application is language agnostic. Any true OO language is sufficient so no need to learn another one at this point.

I also don't think looking at the source of VirtualTreeView or similar controls will teach you much. You would learn about Winapi, but while useful, that is not going to help with application design.

So to summarize, google up resources about application design, business objects, architecture, OPFs, patterns and testing.

Answer 8

I'm not sure there is a simple answer to your question.

One way to constantly hone your grasp of fundamentals is through practice and repetition. One interesting way to accomplish this is the so called code kata, which gets it inspiration from martial arts.

The concept itself is language agnostic and there is heavy emphasis on TDD, which I like. Julian Bucknall seems to be a fan, too. Some people even record their katas. A quick Google search turns up lots of different references.

Answer 9

If you work as part of a team, participate in peer code review, utilizing a tool such as Code Collaborator or ReviewBoard. Not only will you learn from others and their comments on your code, but you'll develop a critical eye of your own work, and will quickly start coding better.

Answer 10

The code of virtualtreeview is terrible. Don't worry about that.

To get really good at object-oriented programming, you might want to try Smalltalk for a while. And for something completely different, add in the Seaside web framework.

[edit] There are several reasons why looking into Seaside is a good idea. It is a prime example of creating excellent abstractions over atrocities like html, css and javascript, making it thereby possible to do web development in a reasonable way. It shows how to create fluent interfaces and how to use them to be much more productive.

After 20 years of Turbo Pascal and Delphi, my coding style improved significantly with the use of Smalltalk. Should have found it earlier.

Virtualtreeview on the other hand consists of an enormous amount of badly structured code. No abstractions, way too long methods, bad data structures. The only advantage it has is that it is widely used, so you're unlikely to run into bugs if you keep to the well-used parts.

[edit2] And after you're comfortable with Smalltalk and Seaside, try running it on Gemstone, an object oriented database. That will show you how databases should be (invisible), and make you argue against relational databases ever after.