Posts

Showing posts from January, 2021

If it is too complex, you are probably doing it wrong

If there is one thing experience has taught me, it is that too much complexity in some code usually means that design is wrong. That does not mean that everything must and can be as simple as 2 + 2, but complexity should sound some inner alarm and should make you reconsider your approach. If basic concept, without all convenience features is hard to follow then it is most certainly wrong. Adding convenience features can bring some additional layers of complexity and certainly plenty of code, but they don't usually pose a significant problem if basic concept is done right. There are many practices, patterns and advices going around that should help writing clean and maintainable code, but two stand before all else. Violate them and you will be in trouble, sooner or later (usually sooner or in the worst possible moment). KISS - Keep it simple stupid -  https://en.wikipedia.org/wiki/KISS_principle YAGNI - You aren't gonna need it -  https://en.wikipedia.org/wiki/You_aren't_gon...

Code examples from Delphi Event-based and Asynchronous Programming Book

Image
  A little birdie once told me that having code examples from my book in a friendlier form would be highly appreciated. Of course I heard the friendly chirp  So here it is! The full list of code examples from the book Delphi Event-based and Asynchronous Programming is available for you to download from my GitHub page: https://github.com/dalijap/code-delphi-async

Are const parameters dangerous?

Image
Marco Cantu's recent blog post The Case of Delphi Const String Parameters opened a can of worms. A very, very old can... The presented behavior is not something new, and it is certainly not a compiler bug. It is just the way reference counting works. A pure ARC problem—one instance of something is destroyed when the other one is created and assigned, because the const parameter did not trigger the reference counting mechanism—this is why const is used for speed optimization in the first place. The same thing that happens with strings happens with reference-counted objects, but it is easier to see what happens with objects in the same kind of code. You will need a form with a memo and a button to test the following code: type IFoo = interface function GetCount: Integer; function GetNumber: Integer; end; TFoo = class(TInterfacedObject, IFoo) private FNumber: Integer; public constructor Create(ANumber: Integer); destructor Destroy; override; f...