Jump to content
Mike Torrettinni

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

Recommended Posts

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?

 

In last few years I've been refactoring my code, getting rid of global variables, started using classes, organizing units with methods by common purpose, trying to split logic and UI, optimized for performance, and so on. Often I think about if I would learn this from the beginning, would I ever need to do any refactoring at all?

 

I would like to understand examples of how Delphi experts improve their code, what else can you do or learn that is beyond 'the right way to program'.

Share this post


Link to post

Code is never perfect.

 

You just revisit code months later and some things will inevitably draw attention. Sometimes, improvements are just minor tweaks, sometimes you are like "what was I thinking, this whole thing has to go". Sometimes, you just leave all the horror untouched because you don't have time.

 

It is a never ending story.

  • Like 3
  • Thanks 2
  • Haha 2

Share this post


Link to post

I think we all recognize that our skills evolve. And so does our thinking. Moreover, today's "best practices" will someday probably be superseded. 

Any non-trivial code can be improved.

  • Like 2
  • Thanks 1

Share this post


Link to post

Much of the development I do is refactoring. Not for its own sake, but to enable a new development. Typically this means refactoring existing code, relying heavily on the testing of that code, so that the new development can be added easily. Often the bulk of the time is spent refactoring and then the new development is trivial. 

 

In other words, even when code is well factored, it often needs to be refactored. 

 

Also, its not at all the case that replacing standalone functions with classes always makes your code better. Don't be afraid to have standalone functions if that is the right design. 

  • Like 3
  • Thanks 2

Share this post


Link to post

Even Chuck Norris refactors his code (with a roundhouse kick though but still...)

Edited by Stefan Glienke
  • Like 2
  • Haha 8

Share this post


Link to post

Thanks, good to know and makes sense! I just thought how boring it will be when I become 'expert, so maybe I shouldn't 😉

 

Well, good to know it never gets boring and always some challenging stuff to do.

Share this post


Link to post

@Vincent Parrett Done yet? 😄

 

Honestly, refactoring does not only mean fixing and improving code itself, though, as stated above, as learning and evolving creature, there is always a chance for that, no matter how expertly you done it, but requirements change, features need to be implemented, and so on. Existing code may anticipate a lot of upcoming changes, but ever everything? So yes, there will always be a need for refactoring.

 

Now, let's go back to my last paragraph and do that 😉

  • Like 1

Share this post


Link to post
11 hours ago, Dalija Prasnikar said:

sometimes you are like "what was I thinking, this whole thing has to go"

There was several cases when I looked and thought "what I was thinking, this stuff is ugly and non-optimal, I'll fix it in a minute", but after N hours of redesigning the code I realized "Aaaaahhh I meant THAT thing!" and reverted old code but now prepending it with extensive comments entitled with "There be dragons" magic phrase  xD

Edited by Fr0sT.Brutal
  • Like 2

Share this post


Link to post
17 minutes ago, Fr0sT.Brutal said:

There was several cases when I looked and thought "what I was thinking, this stuff is ugly and non-optimal, I'll fix it in a minute", but after N hours of redesigning the code I realized "Aaaaahhh I meant THAT thing!" and reverted old code but now prepending it with extensive comments entitled with "There be dragons" magic phrase  xD

That's what comments are for. I don't see wisdom or a particularly high level of expertise in the words "Good code needs no comments, it is self explanatory".

  • Like 3

Share this post


Link to post

I certainly am not a Delphi expert in the sense that I don't make mistakes and always produce perfect code. (And as I just yesterday noticed (again) some of my "knowledge" about Delphi is outdated or even has been wrong in the first place).

 

So, I don't really qualify for answering this question even though I have been working with Delphi for nearly my whole professional life.

 

But here goes anyway: I'm never done improving or fixing even my own code base. And don't get me started on the code base of the company I work for. We still have code that is at least 15 years old and has never been refactored even though it is in dire need for that. It's improving slowly but I doubt that it will ever be up to even my standards.

  • Thanks 1

Share this post


Link to post
Just now, David Heffernan said:

I find this to be a very apt principle.

Well, clearly I'm not there yet, and neither is any of the folks whose code I've had the chance to read.

Share this post


Link to post
9 minutes ago, Sherlock said:

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

It all depends on the definition of "good code". Of course my code is good code. 😉

 

The advantage of code without comments is that you don't have to worry about the comments being wrong or outdated because the code was changed (fixed) and nobody bothered with the comments because the code compiles anyway.

 

And of course there are those absolutely unnecessary comments like:

 

// for all 50 entries
for i := 1 to 50 do begin
  // process the entry
  process(entry[i]);
end;
// we are done processing all entries

 

But some programmers (and managers) still insist that these kinds of comments are necessary and a sign of a well documented code base. I definitely disagree here. But I think we degress.

  • Like 1

Share this post


Link to post
7 minutes ago, Sherlock said:

Well, clearly I'm not there yet, and neither is any of the folks whose code I've had the chance to read.

Don't worry, I've never seen larger projects, where the code could explain all the thinking behind the tinkering, especially the larger picture. 

 

I think we all can agree, that good code explains what it is doing quite well, however, rarely, if ever why and never the reason behind he full logic of a multi-year-project.

  • Like 1
  • Thanks 1

Share this post


Link to post

Of course comments explaining every line of code are all in all useless. I'm talking about comments informing the uninformed reader what the heck is going on, and why a problem is solved this way and not another (hence preventing aforementioned refactoring odysseys). Most times those comments form the core of my technical file and only need a little fleshing out and graphs to be acceptable for auditors.

  • Like 1
  • Thanks 1

Share this post


Link to post

Good comments are not about *what* the code does but *why* because that is typically the question a future reader will have when they read the code.

And experience teaches you to anticipate such questions and put comments where appropriate.

  • Like 5
  • Thanks 1

Share this post


Link to post

I believe Stefans words to be a fitting final statement on the subject of comments and suggest veering back to the subject at hand...namely refactoring 😉

  • Like 1

Share this post


Link to post

I always remember the Peter Gottschling's description of a program comment from his book "Discovering modern C++":
 

Quote

 

The primary purpose of a comment is evidently to describe in plain language what is not obvious for everybody in the program sources, like this:


// Transmogrification of the anti-binoxe in O(n log n)
while(cryptographic(trans_thingy) < end_of(whatever)) { ....


 

 

 

  • Like 1
  • Haha 2

Share this post


Link to post
Guest
4 hours ago, Sherlock said:

I believe Stefans words to be a fitting final statement on the subject of comments and suggest veering back to the subject at hand...namely refactoring 😉

I often find refactored code with comments about *why* something was done in a certain way... But it's not anymore. It was refactored. Artifactual comments will increase as more refactoring tools become available. So the need of comment refactoring tools will arise.

 

// The LNotSoGoodAName variable is... bla bla because bla...

Var LStringentName: integer;

Var LThisIsThat: string;

Share this post


Link to post

Another challenge is knowing when NOT to refactor.

"This code works, but it looks awful... should I refactor?"

  • Like 1

Share this post


Link to post
48 minutes ago, Lars Fosdal said:

Another challenge is knowing when NOT to refactor.

"This code works, but it looks awful... should I refactor?"

"Do you have tests for it?"

  • Like 2

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

×