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

[Mike Torrettinni 198]

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

[Dalija Prasnikar 1396]

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.

[Bill Meyer 337]

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.

[David Heffernan 2345]

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. 

[Stefan Glienke 2002]

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

Edited February 12, 2020 by Stefan Glienke

[Vincent Parrett 750]

I've been using Delphi for 25 years, I'm working on a 20 year old code base, I'll let you know when I'm done refactoring  

 

[Mike Torrettinni 198]

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.

[sakura 45]

@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 😉

[Fr0sT.Brutal 900]

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 February 13, 2020 by Fr0sT.Brutal

[Sherlock 663]

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

[dummzeuch 1505]

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.

[David Heffernan 2345]

1 minute ago, Sherlock said:

Good code needs no comments, it is self explanatory

I find this to be a very apt principle.

[Sherlock 663]

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.

[dummzeuch 1505]

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.

[sakura 45]

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.

[Sherlock 663]

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.

[Stefan Glienke 2002]

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.

[Sherlock 663]

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 😉

[Edwin Yip 154]

As a serious software developer you have to constantly refactor and improve your code.

[Alexander Elagin 143]

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

 

 

 

[microtronx 38]

It is a non stop optimizing and refactoring ... Never ending story 😉

[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;

[Lars Fosdal 1792]

Another challenge is knowing when NOT to refactor.

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

[Stefan Glienke 2002]

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?"

[Uwe Raabe 2057]

1 hour ago, Lars Fosdal said:

This code works

How can you be sure?