Jump to content
Mike Torrettinni

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

Recommended Posts

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).

Share this post


Link to post
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 !

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
Guest

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

Edited by Guest

Share this post


Link to post

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

Share this post


Link to post
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.

  • Like 4

Share this post


Link to post
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 😞

  • Like 2

Share this post


Link to post

Soooo, I know I am not free of guilt either :classic_blush:, 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 :classic_biggrin:

Share this post


Link to post
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).

Share this post


Link to post

OK, I'll try to fork it then.

 

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

Share this post


Link to post

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

distracted.gif.d8ca7e6d4e55b06b9e88253639dce23d.gif

 

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

 

  • Like 3

Share this post


Link to post

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.

  • Like 5

Share this post


Link to post
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.

Share this post


Link to post

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.

  • Haha 1

Share this post


Link to post
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. 

  • Like 2

Share this post


Link to post
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?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×