#legacy code

If the below code blocks do not show up properly due to a recent Tumblr change. View them directly at https://obscurejavascript.tumblr.com/

Sometimes functions in classes are useful beyond just a class. Even if they do not determine their results compeletly based on the arguments passed in, they usually can be extracted. Though sometimes this functionality is too complex and modifying it is too risky, especially in legacy code. Here is a simple example, in a real work scenario the main function would be much more complicated:

class Car { constructor(name, hp, weight) { this.name = name; this.hp = hp; this.weight = weight; this.setPowerToWeightRatio(); } setPowerToWeightRatio() { this.powerRatio = Math.round((this.hp/this.weight) * 100) + '%'; } // Complex functionality that also uses setPowerToWeightRatio() here } const miata = new Car('miata', 155, 2387); console.log(miata.powerRatio); // 6%

Assuming that calculatePowerToWeightRatio cannot be modified since other parts of the code rely on it, then its functionality can still be extracted. By a collecting its this settings and then returning those:

function powerToWeightRatio(hp, weight) { const collector = { hp, weight }; Car.prototype.setPowerToWeightRatio.call(collector); return collector.powerRatio; } console.log(powerToWeightRatio(1000, 1000)); // 100% console.log(powerToWeightRatio(500, 1000)); // 50%

Notice how you do not even need an instantiated object to extract the function. Just having a reference to the class works. I am calling this using a Collector since I could find no reference to this tactic on the internet (probably because it is very niche). So by using a Collector, the setPowerToWeightRatio method can be used across the code in general without having modified the original one or having copied any code.

Finally, it is best to avoid coding in the way of the original class when possible. At the very least, instead of using built in properties it is more flexible to pass in properties. Additionally, if a value is returned instead of set internally, it will make the method much more flexible without much extra work. The above tactic is used to work with legacy code (e.g. large libraries) that you do not have time to modify in the short term.

"Did I sleep through?" they ask.

Basically, 'use strict'; makes code more consistent and less error prone. You can read about the exact details here.

So should it be used everywhere? Contrary to most sources on the internet, the answer is no. For new projects and completely new code it should be used by default, but applying it to old code can in some rare cases cause that code to work differently. For example, here is some code made in an old JS style without 'use strict':

function addMessage(message) { var self = this || {}; self.messages = self.messages || []; self.messages.push(message); } addMessage('message1'); console.log(window.messages); // ["A message"]

The above occurs because the this value refers to the global scope in non-strict code. With adding 'use strict';:

'use strict'; function addMessage(message) { var self = this || {}; self.messages = self.messages || []; self.messages.push(message); } addMessage('message2'); console.log(window.messages); // undefined

Now this does not automatically set to the global scope in that function. Also, notice how no errors occured. In this case, unit testing that old code first before adding 'use strict'; would have caught this error. Though in some cases even unit testing may not be enough, so it is also necessary to manually analyze if old code will act differently under strict mode. Here is a good source on how to do that.

The good news, is in the future most code will automatically be in strict mode either via tools or by using new language features. For example, the upcoming language feature ES6 Modules will be supported natively in browsers and those modules are automatically in strict mode. Note these modules are different from the Node.js modules (there was no universal module format when Node.js was created). So Node.js code is not automatically in strict mode unless a compiler flag is used.

We’ve all been there: staring down a mountain of legacy code, feeling the weight of technical debt pressing down. It’s often brittle, poorly documented, and a constant source of anxiety for development teams struggling to innovate. Modernizing applications shouldn’t feel like an archaeological dig; it should be a strategic move towards agility and efficiency. Unfortunately, traditional approaches…