All posts

Efficiency-first versus the collaborative-friendly

Portrait of Steve Morland
January 31, 2020
5 min read
Blog author Steve Morland sat at his desk.

What’s more important; minified, more-efficient fit-for-purpose succinct code, or bloated, well-commented, readable and reusable code?

Often when it comes to back-end code then the immediate answer would be to be as efficient as possible but, while that may solve today’s problems quickly when tomorrow’s problems arise it unearths a whole world of pain, especially if a different development team pick up the project.

The pitfalls of being shortsighted

Code can be extremely well written in terms of efficiency when crafted for a specific project. However, digital projects are rarely just one iteration. Business change, technologies change and ultimately what you need your software to do also changes.

There is no doubt that web pages and web applications should be snappy, so keeping your code as small as possible should definitely be at the forefront of your design; laggy JavaScript can ruin a user’s experience completely. But equally, you might not be the only developer to have to work on this file or functionality and invariably when a developer doesn’t understand existing code they break it, or duplicate it, or worse still, waste productive time re-writing it all.

Commenting code

Commenting code should be as important as writing the code itself. The important thing about comments is that not only does it mean it’s easier for someone to understand the code, but the comments can walk them through it, give them examples of parameters or explain any abstract functions and patterns. Equally, you can also explain any decisions you’ve made that might not be obvious.

Mind your programming practice

Use good programming practices; JavaScript is a very loose language, but it doesn’t mean your code has to be loose too. Using tools like JSLint you can make sure that you don’t accidentally start using a variable without declaring it meaning that one day it will make no sense whatsoever to someone else picking up development.

Stick native

If you have built a jQuery plugin try to continue to write in nativeJavaScript where possible; for example, loops are typical for loops rather than using jQuery .each loops. Most, if not all, selectors are written to best use native DOM operations such as getElementByID(), or on modern browsers use fulfeatures like querySelectorAll(). Any complex and non-native selectors should be broken down so that you use the nearest ID, element or class selector and simply .find() or .filter() within the collection. If you read up on jQuery performance, you’d be surprised by the difference it makes.

Code re-factoring

Put time aside for code re-factoring. As your code grows it’s very likely that you will repeat functionality, whether it’s duplicating some code in a multiple-condition block or repeating an action in two different functions. During this process you might also notice a better way to do what you’re trying to achieve and it’s also a very good opportunity to make sure you are caching.

A working example

One of the biggest benefactors in coding efficiency is caching. Caching is simple but effective. If you cache a selector, it saves you re-creating jQuery object repeatedly. Take this following code:

$("#myForm").submit(function(e){      e.preventDefault();

           if ($(this).validateForm() ) {

                       $(this).find("input, select, textarea").attr("disabled", "disabled");

                       $(this).find(".errorMessage").hide();

                       $.ajax({

                                   url:"submit.php",

                                   data: $(this).serialize(),

                                   success:function () {

                                               $(this).find("input,select, textarea").removeAttr("disabled");

                                               $(this).find(".successMessage").show();

                                   }

                       });

           } else {

                       $(this).find(".errorMessage").show();

           }          

});

Notice how many times we create a jQuery object using “this”. Instead, we could cache “this” as a jQuery object in a variable which would save us fromre-creating the object, like so:

$("#myForm").submit(function(e){

           var thisForm = $(this);

           e.preventDefault();

           if (thisForm.validateForm() ) {

                       thisForm.find("input, select, textarea").attr("disabled", "disabled");

                       thisForm.find(".errorMessage").hide();

                       $.ajax({

                                   url:"submit.php",

                                   data:thisForm.serialize(),

                                   success:function () {

                                               thisForm.find("input,select, textarea").removeAttr("disabled");

                                               thisForm.find(".successMessage").show();

                                   }

                       });

           } else {

                       thisForm.find(".errorMessage").show();

           }          

});

It might not seem a lot, but each slice of processing time saved soon adds up, imagine if this was inside a loop that was executed hundreds or thousands of times.

Don’t forget to chain

One of the things with creating a jQuery plugin is that when the plugin is instantiated it will return back the jQuery collection from the original selector. Why is this important? It’s important because we can do multiple actions to a collection without recreating the collection. So, it’s a bit like caching too, for example:

$(".successMessage").addClass("highlight");

$(".successMessage").slideDown();  

$(".successMessage").css("marginBottom","20px");

3 lines of code could effectively become one:

$(".successMessage").addClass("highlight").slideDown().css("marginBottom","20px");

There’s nothing wrong with chaining to your cached objects either, just be careful of jQuery methods that don’t return the collection e.g. serialize().

If we put all that together we get well documented code that the next developer can pick up and understand, while also keeping our user’s experiences as streamlined as possible.

So, what is more important, focusing primarily on efficiency or making your code as readable and understandable as possible? Given the iterative nature of digital projects readable code is essential to future proofing your products. Just because it’s readable doesn’t mean it has to be bloated; minifying and clever programming can make that readable code extremely performance efficient.

Share this post
Portrait of Steve Morland
January 31, 2020
5 min read
All posts
Blog author Steve Morland sat at his desk.

Efficiency-first versus the collaborative-friendly

What’s more important; minified, more-efficient fit-for-purpose succinct code, or bloated, well-commented, readable and reusable code?

Often when it comes to back-end code then the immediate answer would be to be as efficient as possible but, while that may solve today’s problems quickly when tomorrow’s problems arise it unearths a whole world of pain, especially if a different development team pick up the project.

The pitfalls of being shortsighted

Code can be extremely well written in terms of efficiency when crafted for a specific project. However, digital projects are rarely just one iteration. Business change, technologies change and ultimately what you need your software to do also changes.

There is no doubt that web pages and web applications should be snappy, so keeping your code as small as possible should definitely be at the forefront of your design; laggy JavaScript can ruin a user’s experience completely. But equally, you might not be the only developer to have to work on this file or functionality and invariably when a developer doesn’t understand existing code they break it, or duplicate it, or worse still, waste productive time re-writing it all.

Commenting code

Commenting code should be as important as writing the code itself. The important thing about comments is that not only does it mean it’s easier for someone to understand the code, but the comments can walk them through it, give them examples of parameters or explain any abstract functions and patterns. Equally, you can also explain any decisions you’ve made that might not be obvious.

Mind your programming practice

Use good programming practices; JavaScript is a very loose language, but it doesn’t mean your code has to be loose too. Using tools like JSLint you can make sure that you don’t accidentally start using a variable without declaring it meaning that one day it will make no sense whatsoever to someone else picking up development.

Stick native

If you have built a jQuery plugin try to continue to write in nativeJavaScript where possible; for example, loops are typical for loops rather than using jQuery .each loops. Most, if not all, selectors are written to best use native DOM operations such as getElementByID(), or on modern browsers use fulfeatures like querySelectorAll(). Any complex and non-native selectors should be broken down so that you use the nearest ID, element or class selector and simply .find() or .filter() within the collection. If you read up on jQuery performance, you’d be surprised by the difference it makes.

Code re-factoring

Put time aside for code re-factoring. As your code grows it’s very likely that you will repeat functionality, whether it’s duplicating some code in a multiple-condition block or repeating an action in two different functions. During this process you might also notice a better way to do what you’re trying to achieve and it’s also a very good opportunity to make sure you are caching.

A working example

One of the biggest benefactors in coding efficiency is caching. Caching is simple but effective. If you cache a selector, it saves you re-creating jQuery object repeatedly. Take this following code:

$("#myForm").submit(function(e){      e.preventDefault();

           if ($(this).validateForm() ) {

                       $(this).find("input, select, textarea").attr("disabled", "disabled");

                       $(this).find(".errorMessage").hide();

                       $.ajax({

                                   url:"submit.php",

                                   data: $(this).serialize(),

                                   success:function () {

                                               $(this).find("input,select, textarea").removeAttr("disabled");

                                               $(this).find(".successMessage").show();

                                   }

                       });

           } else {

                       $(this).find(".errorMessage").show();

           }          

});

Notice how many times we create a jQuery object using “this”. Instead, we could cache “this” as a jQuery object in a variable which would save us fromre-creating the object, like so:

$("#myForm").submit(function(e){

           var thisForm = $(this);

           e.preventDefault();

           if (thisForm.validateForm() ) {

                       thisForm.find("input, select, textarea").attr("disabled", "disabled");

                       thisForm.find(".errorMessage").hide();

                       $.ajax({

                                   url:"submit.php",

                                   data:thisForm.serialize(),

                                   success:function () {

                                               thisForm.find("input,select, textarea").removeAttr("disabled");

                                               thisForm.find(".successMessage").show();

                                   }

                       });

           } else {

                       thisForm.find(".errorMessage").show();

           }          

});

It might not seem a lot, but each slice of processing time saved soon adds up, imagine if this was inside a loop that was executed hundreds or thousands of times.

Don’t forget to chain

One of the things with creating a jQuery plugin is that when the plugin is instantiated it will return back the jQuery collection from the original selector. Why is this important? It’s important because we can do multiple actions to a collection without recreating the collection. So, it’s a bit like caching too, for example:

$(".successMessage").addClass("highlight");

$(".successMessage").slideDown();  

$(".successMessage").css("marginBottom","20px");

3 lines of code could effectively become one:

$(".successMessage").addClass("highlight").slideDown().css("marginBottom","20px");

There’s nothing wrong with chaining to your cached objects either, just be careful of jQuery methods that don’t return the collection e.g. serialize().

If we put all that together we get well documented code that the next developer can pick up and understand, while also keeping our user’s experiences as streamlined as possible.

So, what is more important, focusing primarily on efficiency or making your code as readable and understandable as possible? Given the iterative nature of digital projects readable code is essential to future proofing your products. Just because it’s readable doesn’t mean it has to be bloated; minifying and clever programming can make that readable code extremely performance efficient.

Watch now!

To watch the on-demand video, please enter your details below:
By completing this form, you provide your consent to our processing of your information in accordance with Leighton's privacy policy.

Thank you!

Use the button below to watch the video. By doing so, a separate browser window will open.
Watch now
Oops! Something went wrong while submitting the form.
All posts
Blog author Steve Morland sat at his desk.

Efficiency-first versus the collaborative-friendly

What’s more important; minified, more-efficient fit-for-purpose succinct code, or bloated, well-commented, readable and reusable code?

Often when it comes to back-end code then the immediate answer would be to be as efficient as possible but, while that may solve today’s problems quickly when tomorrow’s problems arise it unearths a whole world of pain, especially if a different development team pick up the project.

The pitfalls of being shortsighted

Code can be extremely well written in terms of efficiency when crafted for a specific project. However, digital projects are rarely just one iteration. Business change, technologies change and ultimately what you need your software to do also changes.

There is no doubt that web pages and web applications should be snappy, so keeping your code as small as possible should definitely be at the forefront of your design; laggy JavaScript can ruin a user’s experience completely. But equally, you might not be the only developer to have to work on this file or functionality and invariably when a developer doesn’t understand existing code they break it, or duplicate it, or worse still, waste productive time re-writing it all.

Commenting code

Commenting code should be as important as writing the code itself. The important thing about comments is that not only does it mean it’s easier for someone to understand the code, but the comments can walk them through it, give them examples of parameters or explain any abstract functions and patterns. Equally, you can also explain any decisions you’ve made that might not be obvious.

Mind your programming practice

Use good programming practices; JavaScript is a very loose language, but it doesn’t mean your code has to be loose too. Using tools like JSLint you can make sure that you don’t accidentally start using a variable without declaring it meaning that one day it will make no sense whatsoever to someone else picking up development.

Stick native

If you have built a jQuery plugin try to continue to write in nativeJavaScript where possible; for example, loops are typical for loops rather than using jQuery .each loops. Most, if not all, selectors are written to best use native DOM operations such as getElementByID(), or on modern browsers use fulfeatures like querySelectorAll(). Any complex and non-native selectors should be broken down so that you use the nearest ID, element or class selector and simply .find() or .filter() within the collection. If you read up on jQuery performance, you’d be surprised by the difference it makes.

Code re-factoring

Put time aside for code re-factoring. As your code grows it’s very likely that you will repeat functionality, whether it’s duplicating some code in a multiple-condition block or repeating an action in two different functions. During this process you might also notice a better way to do what you’re trying to achieve and it’s also a very good opportunity to make sure you are caching.

A working example

One of the biggest benefactors in coding efficiency is caching. Caching is simple but effective. If you cache a selector, it saves you re-creating jQuery object repeatedly. Take this following code:

$("#myForm").submit(function(e){      e.preventDefault();

           if ($(this).validateForm() ) {

                       $(this).find("input, select, textarea").attr("disabled", "disabled");

                       $(this).find(".errorMessage").hide();

                       $.ajax({

                                   url:"submit.php",

                                   data: $(this).serialize(),

                                   success:function () {

                                               $(this).find("input,select, textarea").removeAttr("disabled");

                                               $(this).find(".successMessage").show();

                                   }

                       });

           } else {

                       $(this).find(".errorMessage").show();

           }          

});

Notice how many times we create a jQuery object using “this”. Instead, we could cache “this” as a jQuery object in a variable which would save us fromre-creating the object, like so:

$("#myForm").submit(function(e){

           var thisForm = $(this);

           e.preventDefault();

           if (thisForm.validateForm() ) {

                       thisForm.find("input, select, textarea").attr("disabled", "disabled");

                       thisForm.find(".errorMessage").hide();

                       $.ajax({

                                   url:"submit.php",

                                   data:thisForm.serialize(),

                                   success:function () {

                                               thisForm.find("input,select, textarea").removeAttr("disabled");

                                               thisForm.find(".successMessage").show();

                                   }

                       });

           } else {

                       thisForm.find(".errorMessage").show();

           }          

});

It might not seem a lot, but each slice of processing time saved soon adds up, imagine if this was inside a loop that was executed hundreds or thousands of times.

Don’t forget to chain

One of the things with creating a jQuery plugin is that when the plugin is instantiated it will return back the jQuery collection from the original selector. Why is this important? It’s important because we can do multiple actions to a collection without recreating the collection. So, it’s a bit like caching too, for example:

$(".successMessage").addClass("highlight");

$(".successMessage").slideDown();  

$(".successMessage").css("marginBottom","20px");

3 lines of code could effectively become one:

$(".successMessage").addClass("highlight").slideDown().css("marginBottom","20px");

There’s nothing wrong with chaining to your cached objects either, just be careful of jQuery methods that don’t return the collection e.g. serialize().

If we put all that together we get well documented code that the next developer can pick up and understand, while also keeping our user’s experiences as streamlined as possible.

So, what is more important, focusing primarily on efficiency or making your code as readable and understandable as possible? Given the iterative nature of digital projects readable code is essential to future proofing your products. Just because it’s readable doesn’t mean it has to be bloated; minifying and clever programming can make that readable code extremely performance efficient.

Download
To download the assets, please enter your details below:
By completing this form, you provide your consent to our processing of your information in accordance with Leighton's privacy policy.

Thank you!

Use the button below to download the file. By doing so, the file will open in a separate browser window.
Download now
Oops! Something went wrong while submitting the form.
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.