Nick Hodges

Delphi Development Pretty Good Practices #1

19 Apr

A while back someone (I can’t remember who, sadly, sorry to the person who made the suggestion…) suggested that someone do a series of articles about “the best practices on how to develop a Delphi application”.  That’s a good idea.  There are a lot of ways to do things, and clearly there are some good way and some bad ways, some okay ways and some really cool ways to develop with Delphi.

This series of articles will cover my personal ideas behind a good way to organize and build a Delphi application.  I’ll build a small application that does a few things.  I’ll organize the application in such a way that it illustrates some techniques that I believe are a good way to organize things.  I will explain my reasoning and in doing so I hope that you guys learn something.  This won’t be an exhaustive list or collection of ideas.

What I will not do is pretend that what I do and the way I do it is the only way to do things.  Heck, it may be that you end up thinking the way I do things is ridiculous.  I’ll let you all be the judge of that.   If you guys have different ideas, please feel free to express them.  If you like what you see, let me know.  I’ve been using Delphi for a long time, and so I think I’ve learned a thing or two along the way, but I’m not the world’s greatest Delphi developer and I certainly won’t claim to be the final arbiter of how things should be done.  I generally don’t like the term “Best Practices”, so I’ve titled this using “Pretty Good Practices”.

My goal here, really, is to be informative and stimulative and to evoke conversation and discussion.  I have developed a way of doing things over the years and I’ll be outlining them in this series of articles.  I don’t believe that this series will be all inclusive – that is, I won’t be covering every single aspect of every single development practice that I’ve ever thought of. Again, I hope merely to stimulate some discussion and do my humble part to  improve the way Delphi applications are developed.

The application I’ll use as an illustration is one that I use practically every day.  I call it “TextScrubber”, and it is a simple application that resides in the tray and let’s me “clean up text”, either by removing formatting, removing line breaks, or both.  I use it when I copy text from the web or from an MS Word document that contains formatting information that I in turn want to paste into another document when I don’t want the formatting to come along.  I copy the text, click on the icon in the tray, and the text is “scrubbed” and put back on the clipboard.  (It is basically a much simpler version of PureText – a product that I heartily recommend that you use if you want this kind of functionality.)  TextScrubber is actually a very simple application with not a lot of code, but I’ve laid it out in such a way that it illustrates many of the methods that I have developed over the years.  Thus, I hope it will suffice to illustrate the things I want to discuss.

To start, I’ll talk about a few general ideas that drive how I do things. These are the general ideas that drive what I do when I develop:

  • Any code of consequence at all should be managed under source control, even if I am the only one using and writing the code.  I use Subversion for this. I actually run the Subversion server on my local machine, but you don’t need to do that.  You can manage a Subversion repository merely as a set of local files, if you want.  But even if you develop all alone, I think using source control is a great idea.
  • I want everything I write to be easily expandable and scalable.  I try to organize and write code that can easily be extended and enhanced.  I try to write classes that have a sensible hierarchy and that can be easily inherited from.
  • I want my code to be testable.  I want to write it in such a way that it is conducive to writing unit tests.  I want it to be easy to isolate and easy to find problems if they crop up. 
  • To as large a degree as possible, I separate the logic of an application from the user interface.  I don’t go full bore into an MVC application usually – that almost requires a special framework, but I do try very hard to separate out functionality into separate, testable classes.
  • I want my code to be well modularized.  That is, I want each class and each unit to have a single purpose, and be linked to other units and classes as loosely as possible. 

What would you add to this list?  What are some of the general rules you try to follow when developing an application?

21 Responses to “Delphi Development Pretty Good Practices #1”

  1. 1
    Salvador Gomez Retamoza Says:

    Hi Nick! I think this article series is the "Pretty Good" idea of the year, really. This could cover a hole in the path to extract the best of Delphi as a really cool tool.

    I’ll like to add something to the list that, if not applicable EVERY time, it centainly could make the difference if we could do it. The obviuos first step is knowing as much as you can of what you are going to do, then this is my shocking proposal: do some desing before going to File -> New -> VCL Forms Application.

    Draw some UI, and some class diagrams whenever applicable. Some sketches with a pencil over paper will do the job for most of the cases, then save them, if you can scan them do it, or better: bang them in a model in Delphi from the begining.

    I know making the UI in Delphi is piece of cake, but there is still some pre-visualization work that could make the difference, besides, after you see your first UI work in the Delphi Designer, you will tend to be fixed with that idea. At least that is the way it works with me and my fellow developers I work with.

  2. 2
    Lachlan Gemmell Says:

    I’m guessing TextScrubber will be heavy on objects and light on database access. A follow up series for database applications would be worthwhile too.

  3. 3
    DelphiScalper High Probability Scalping System-Grab This Hot Time Indicator Plus Report FREE Just Now! Says:

    [...] Nick Hodges » Blog Archive » Delphi Development Pretty Good Practices #1 [...]

  4. 4
    runner Says:

    I think you forgot one of the most important principles.

    - DRY principle: Duplication is EVIL, pure EVIL I tell you :)

    About code control. You can also use GIT or Mercurial or any of other versioning systems that do not require a central repository.

  5. 5
    Mike Says:

    Something I’d like to add:

    * COMMENT your code - after a few weeks you’l be happy to have some comments.

  6. 6
    Stuart Clennett Says:

    I sense a very useful series here. Even if it re-inforces what I already know, it’s nice for those single-handed developers like us :o)

    Also want to echo Lachlan Gemmells statement about db apps. I’ve always wondered if my db connection sharing and data module usage is right…

    Thanks.

  7. 7
    Leonardo Says:

    Following the comment by runner, one way to enforce me to avoid code dupplication is trying to create small methods, with less than 20 or 30 lines of code that can be read without scrolling. This way, it is easy to point similarities between tho methods.

    About the "correct" way to create db, after years of fighting with DataModules plagued with TQueries/TTables, I started to find ways to avoid it’s usage, and ended up working with objects instead of TDataset/FieldByName and the like, then created an Object Relational Mapping framework to persist those objects in the database. The way the ORM is decoupled from the main app, allows me to easily change the database engine, for example.

  8. 8
    Daniel Says:

    Suggestion: don’t create these camtasia movies with lots of click-click and blahblah, please make a searchable wiki document with screenshots. Thank you

  9. 9
    Nick Hodges » Blog Archive » Delphi Development Pretty Good … | BLOG - @ - RENA Says:

    [...] post: Nick Hodges » Blog Archive » Delphi Development Pretty Good … best-practices, delphi, some-bad, [...]

  10. 10
    Frank Luke Says:

    Leonardo,

    Any chance of making that ORM available to others?

  11. 11
    Chris Says:

    I also vote for Database good practices as there are no official guides how to develop DB apps properly; and, I am not too found about Tquery/Ttable.

    @Leonardo.
    Any chance you can show ORM.

  12. 12
    efrain Says:

    Taking advantage of the requests, you could make examples of web applications with database management, I have a way of working with client / server applications and view other options would help me a lot

  13. 13
    Larry Hengen Says:

    Great idea for a series Nick. I agree with other commentors that a series on a database centric application would be nice.

    If anyone is looking for an ORM/OPF to provide proper layering of an application and testability, there is one available at http://sourceforge.net/projects/larryhengensopf/

  14. 14
    Steffen Says:

    A suggestion: Write some thoughts about how to organize a project in (sub)directories. What to do with a common library shared across projects. How to cope with third party libraries and components.
    I personally have always trouble with a lot of search paths to add to every (new) project. BTW: Global search paths are no options because the project cannot be built by a build server with another directory layout.

  15. 15
    Paweł Głowacki Says:

    Hi Nick,
    I love the idea of of this new serie of posts. So cool and needed. Delphi IS the best tool to write excellent code!

    I would add to your list:
    -> enumerated types are your friend in coding. I found code that heavily use enumerated values much more readable and less error prone. Enumerations are great for modeling the "business domain" of an application.
    -> using meaningful identifiers, even if they are getting a little bit long, especially that with code completion you typically do not need to type them in all the time. Another thing to identifiers is trying to embed type information into instance identifier. If I have a "Login" button, I prefer to call it "btnLogin" or even "ButtonLogin", as opposed to just "Login".
    -> think about "componentizing" your classes. The capability to set components properties at design-time can significantly simplify your code. You do not do it for every class, but sometimes it makes great sense.

  16. 16
    MarkusJoos Says:

    +1 for Steffen’s comment. Although I develop in Delphi for many years, I still struggle with the "best way" to organize a big project.

  17. 17
    Ralph Says:

    Do you plan a simultanious PRISM series?

  18. 18
    Anthony Frazier Says:

    I would like to second Daniel’s comment about having a wiki with screenshots instead of a Camtasia recorded movie thingy.

    I can read far, far faster than you could distinctly talk (unless you’re John Moschitta, Jr. in disguise).

  19. 19
    Craig Says:

    @Mike: Personally, I find adhering to the first principle of the SOLID principles does more for me than comments ever will. http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29

    Code never lies.

  20. 20
    PiotrL Says:

    Some of my tips:
    - implement methods with a single purpose in mind.
    - start method name with a verb, follow it’s pattern (get, set, isXXX, findXXX, indexOf, …) - part of coding standard
    - do not use "private" - it makes classes inaccessible. you never know where you will need to use it
    - do not think "nobody will use it that way, so I can assume…" - last time I thought this way I had to refactor my class next day (!)
    - follow usage patterns popular in your environment
    - read other developer’s source codes
    - limit non-OOP code as much as possible, use it only if required (calculation formulas, formatting procedures)
    - use assertions, exceptions

    "Text scrubbing" is also implemented in HLPlanet Taditor. Just copy text & paste it to editor window. Eventually save it somewhere. There is also function for XML/HTML scrubbing.

  21. 21
    runner Says:

    @PiotrL

    - do not use "private" - it makes classes inaccessible. you never know where you will need to use it
    - do not think "nobody will use it that way, so I can assume…" - last time I thought this way I had to refactor my class next day (!)

    These two items contradict each other. Private is there for a reason. If a fields is not meant to be accessed from outside the class that I even recomend using strict private to avoid missusing private inside the same unit.

© 2014 Nick Hodges | Entries (RSS) and Comments (RSS)

Your Index Web Directorywordpress logo
Close