Interesting article

Started by axel.hennig, March 18, 2022, 01:51:49 PM

Previous topic - Next topic

Mario

#1
I own two books of this author  :D
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

mopperle

Well, remembers me of some customers I had, where the applications on their mainframe were written in Assembler. The apps were fu..ng fast but simply not maintainable, so indeed sometimes code had to be re-written. This went for years until they had to decide to rewrite certain applications to be future proof.

Mario

I rewrite when I come up with a better algorithm. Or when I adapt existing code to new tech, like multiple processors.
And, of course, when I switch programming languages.

But I never change existing code just for "refactoring" or to make it "more readable". I've always wrote readable code, with proper comments, speaking variable names, good structure etc.
This allows me to understand code I've written 10 or 15 years ago - although I've already forgotten about it.

And since I switch between C++, C#, Python, Java and PHP often, depending on the project and task, I apply the same measures to all languages and environments. Has worked very well for me.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

Jingo

Writing "good code" and commenting well within are essentials.. .but refactoring/recoding is often needed.  This is especially true when working in a team environment like I do.  We have on average a team of 12 working on the same product - often tweaking the same code members even.  SVN and GIT handle this (though that in itself is a complex world).  Although we enforce tight coding standards... one person's coding solution can differ greatly from another programmers coding solution... and upon review, recoding may be needed.  And.. you have the folks that quit.. leaving behind a partially coded project... so - someone else needs to jump in... and recode.  And.. then there are the "stagnant" projects that were 50% written 9 months ago but now doesn't fit the design/direction of the product any longer...   Other complexities we run into... new release versions (like Angular 10->13) that require refactoring code to work with the core component changes.  Of course - the company also decides to toss out projects completely... even after spending millions in development manpower $$$... but that is another topic altogether.   8)