As a Delphi expert, do you ever need to refactor or improve your code?

[dummzeuch 1505]

6 minutes ago, Uwe Raabe said:

1 hour ago, Lars Fosdal said:

This code works

How can you be sure? 

As always: Nobody has found and reported a bug (yet).

[Guest]

1 hour ago, dummzeuch said:

1 hour ago, Uwe Raabe said:

2 hours ago, Lars Fosdal said:

This code works

How can you be sure? 

As always: Nobody has found and reported a bug (yet).

This should go into de facto coding rules !

[Lars Fosdal 1792]

1 hour ago, Uwe Raabe said:

How can you be sure? 

Empirically proven to work.

 

"Awful" can be

  - slow code, albeit in a context where performance is not required
 - cryptic code

 - code that could be simplified with modern RTL code

Anyways - Refactor when you need to, and not just because you'd like to - unless unlike most devs, you have time to spare.

Oh - as @Stefan Glienkesuggests: Make sure you have the tests to validate your refactoring.

[Guest]

ATM i'm, refactoring my todo-lists. This process does not involve Delphi/Emba or any such (so OT), but rather papers and pens (colourised).

@Clément a lot of them to get rid of. But then again... in every instance... is it really needed?

[Guest]

IMHO Readability is key (1) performance is a boon (2). In that order.

Edited February 14, 2020 by Guest

[Lars Fosdal 1792]

Less readable code can be greatly alleviated with decent commentary.
Document general intent and method rather than say what each line does.

[David Schwartz 426]

On 2/13/2020 at 1:07 AM, Sherlock said:

"Good code needs no comments, it is self explanatory".

I don't agree with that.

 

A good coder can express something in 5 lines what a poor coder takes 25 lines to say. And the poor coder might not be able to make heads or tails of the 5-line version. And six months after writing the 5-line version, the author might not even recognize it!

 

Code you write "now" is ALWAYS "self-explanatory". That's not why one writes comments -- you don't need them in 5 minutes ... you damn well might need them in 5 months, however!

 

I'm going through a bunch of code right now for the first time, and even though the names of things are quite long and the code is well-organized, there are no comments anywhere, and it's really challenging trying to figure out what's going on. Actually, I take that back ... there are some /// comments above some classes and methods in the interface section intended to be used to create some rough documentation.

 

What's missing is any sort of "big picture" explanation other than one method near the bottom that calls 15 different things declared above it, and none of them pass any parameters, yet they seem to be working on several "global" vars (in the class) that are then revised and refined and used among the methods. Well ... some are, some aren't. 

 

Being an "expert" sometimes means knowing that "if it ain't broke, don't fix it" applies. Refactoring increases the risk of breaking things that have invisible side-effects. If there are no unit tests, then it's a crap-shoot.

 

I like to put "big picture" comments at the top of units, but I'm frequently criticized for it. They're as much for my benefit as others.

 

I worked at a place once where a colleague would put needless comments like "getter" and "setter" next to the read and write parts of property statements (on 3 lines) and delete comments where I was explaining parameters on procedure and functions. Makes you scratch your head sometimes.

[Fr0sT.Brutal 900]

On 2/15/2020 at 2:50 AM, David Schwartz said:

I like to put "big picture" comments at the top of units

This kind of descriptions are priceless for any unit that is something more than a set of various utilities. The same for quick overview of some classes. Sadly those who write such descriptions are very rare 😞

[Sherlock 663]

Soooo, I know I am not free of guilt either , but nevertheless, how about a nice swerve back to the topic please? And as a reminder, the topic is "As a Delphi expert, do you ever need to refactor or improve your code?"

If there is an interest to further the discussion on dictionaries, I am happy to break the forum by trying to fork that discussion

[Attila Kovacs 629]

7 minutes ago, Sherlock said:

BTT, please!

It's an interesting topic since ages. Please don't kill it. The original question was also very broad (or strictly just a yes/no question).

[Sherlock 663]

OK, I'll try to fork it then.

 

Lemme see now, where did I put my magic wand?

[Sherlock 663]

So, if anyone would like to contribute something to this topic, stay here, you're good. If you have something to say about umm... Hashing Dictionaries and such, this is not the place to be

 

While you weren't looking it got split to here:

 

[Lars Fosdal 1792]

/blush

[David Schwartz 426]

I was recently asked what it might take to move off of a solid, stable Delphi-based platform and replace it with something written in, say, C# and all of the latest wiz-bang frameworks that Microsoft supports. I've seen plenty of such efforts in the past 20+ years, and not a single one of them came in anywhere near time or budget! Yet management remained committed to pouring in exorbitant amounts just to ditch a well-functioning platform written in Delphi.

 

I don't get this. My experience over the past 15 years is that upper management loathes allowing devs to refactor code. "Cleaning up code" is what it's frequently called, and they see it as incredibly risky. While I'd tend to agree if there aren't any unit tests in place, the alternative of totally rewriting the whole thing in another language and platform with a different architecture and set of frameworks isn't my idea of "less risky".

 

Is it just Delphi that people see as somehow incapable of continuing to work? I don't get this bias so many upper managers have against a platform that has been working reliably and relatively bug-free for YEARS.

[Guest]

Whenever i am tootally stressed, i refactor all my to-do-lists. A process including a ball-point pen and some leaflets. No IDE's.

I'm not sure it helps, but it makes me a bit less stressed.

[Lars Fosdal 1792]

I have to admit that there are parts of our Delphi code that I want to move to .NET Core and C# - mostly because that makes it far easier to integrate it with other solutions we have on the MS platforms.  

That said - doing end-user applications for Windows in C# is nearly unthinkable.

[Andrea Raimondi 13]

On 2/12/2020 at 8:15 PM, Mike Torrettinni said:

I've been thinking about this a lot lately: when you achieve 'expert' level and all your code is using classes, UI and logic is split, utility units are nice and organized, no or very little global variables... so, a 'perfect' code, when do you have a need to refactor your code?

I don't know if I qualify as an "expert", but I find that as my knowledge grows I also come up with new solutions that work much better for the intended (and sometimes changing!) goals. 

For example, recently, I have come up with a solution to reuse as much UI code as possible between FMX and VCL.

While it still requires you to use different components (for the two libraries are much too different) there is still a lot you can do to minimise impact.

 

Thus, I would say that as I gain experience, I find new ways to address new or existing problems which work much better for the goals at hand. 

This also means I find myself refactoring a lot more than I otherwise would. 

[Guest]

Quote

As a Delphi expert, do you ever need to refactor or improve your code?

 

Absolutely not! How dare you ask such a question young man! A Delphi experts never write a bad code, never need to use commentary, always write short and concise code, that only them and God understands. Delphi experts are above all the ordinary programmers using silly toys like Python or C# or Swift. They use Delphi, it is Delphi, the purest in nature, the simplest of all, the big creation of Almighty. One touch of a keyboard and class is made, two touches of a keyboard and the code is there! 

 

 Jokes aside... the shot answer is yes, always refactor your code.

 

On 2/18/2020 at 6:13 PM, David Schwartz said:

I was recently asked what it might take to move off of a solid, stable Delphi-based platform and replace it with something written in, say, C# and all of the latest wiz-bang frameworks that Microsoft supports. I've seen plenty of such efforts in the past 20+ years, and not a single one of them came in anywhere near time or budget! Yet management remained committed to pouring in exorbitant amounts just to ditch a well-functioning platform written in Delphi.

 

I don't get this. My experience over the past 15 years is that upper management loathes allowing devs to refactor code. "Cleaning up code" is what it's frequently called, and they see it as incredibly risky. While I'd tend to agree if there aren't any unit tests in place, the alternative of totally rewriting the whole thing in another language and platform with a different architecture and set of frameworks isn't my idea of "less risky".

 

Is it just Delphi that people see as somehow incapable of continuing to work? I don't get this bias so many upper managers have against a platform that has been working reliably and relatively bug-free for YEARS.

 

The reason is that, usually, there are no Delphi developers on the market. That would be the bottom line, regardless of rest of the possible reasons. Like it or not, for people running business that makes sense, why keeping such tech. if no one can/want to handle it?