Code Reuse: Generic vs Specific code

Code reuse is probably the most important key to productivity and quality when programming. Node.js is very successful, partly because NPM is very successful at facilitating simple code reuse of vast amounts of reusable packages (of various quality).

However, a project can suffer from too many (external) dependencies which can cause problems with quality, complexity, reliability, maintainability and flexibility: the problems the external code was supposed to solve, not cause.

Generic code
Being generic is generally good when it comes to code. A successful (as in many downloads) NPM library is probably quite generic (like Express, Moment or Bootstrap), otherwise it would not appeal to a large number of developers. One problem with generic functionality is that when used, it is often not the easiest and most compact way to do things.

Specific code
Being specific means that code (especially it API) is shaped exactly for the what is needed in the current project. It may not be very useful outside this project (or organisation), or most other organisations would choose do do things differently and would not agree with it. However, for the project it is being used in, it maximizes reuse.

Example: Bootstrap
Imagine you use Bootstrap and you have a lot of buttons that look the same. You use standard Bootstrap (not to confuse other people or reinvent the wheel) and may end up with exactly the following in many places:

  <button type="button" class="btn btn-outline-danger btn-sm">...

This is 60 characters, repeated exactly all over the application. How about:

  <button class="button-red">...

Now, the first is the result of using Generic and widely reusable classes. The second is the result of deciding that in this application there are a few button types only, each with a specific custom class.

The more specific way is more compact, less prone to typing mistakes and clearer. It is simply better because it maximizes reuse.

Example: Moment
Imagine in your application that in many places you produce date strings of the form “2018-12-24”. Not wanting to use the annoying (ES) standard library you use Moment.js.

  var datestr = moment(somedate).format('YYYY-MM-DD');

This is admittedly as good as a generic library gets, but if you do this in multiple places you can be more specific:

  var datestr = dateToStr(somedate);

It is clearly more compact and consistent and less prone to error. It is simply a better way to write code. The authors of Moment cant make such a specific dateToStr-function because it makes no sense to a lot of use cases. But in your project it makes a lot of sense (to effectively restrict date strings to a single format).

Making your specific choices
My point is that in your project you make specific choices and the code you write should conform to these choices automatically (by reusing your own function) not by passing (the same) arguments to functions too generic for your needs.

Wrapping or writing your own
What I find sometimes happens when I use generic code is something like:

  1. I start using it naively
  2. I get too much redundancy and my code is not as compact as I want
  3. I start wrapping the generic code with my own interfaces
  4. The generic code is not capable of what I want
  5. I extend my own interfaces to do things on their own
  6. I realise I don’t need the generic code at all

I wrote a wrapper around Angular (v1) $http because a lot of my parameters were always the same. Later I wanted to use my wrapper in an application that did not use Angular at all, so I reimplemented my wrapper using XMLHttpRequest (the JS standard library). In the end the code was just marginally larger and more complex than it was when it depended on $http and it had 0 dependencies. So now I have my own http-request-library, but it is arguably too specific and narrow for use in other places.

So one problem with using generic code (first) is that you don’t know much value it creates. I thought $http did great stuff for me, when in fact it was easily removed and I might as well have been using XMLHttpRequest from the beginning.

How much do you save?
If you want to travel from Paris to San Francisco, would you:

  • Use a free train ticket Paris-London?
  • Use a free flight ticket to Dallas?
  • Use a 25% discount coupon with Icelandic Air (flying via Reykjavik)
  • Rather be in Bogata in the first place

The fact is that if Air France sells direct tickets Paris-SF none of the above offers might really be worth it. I think it is the same with programming. Using 10 dependencies, each to save a few lines of codes, in a rather simple project, is in a way the equivalent of flying from Paris to San Francisco with 10 connections for $1.

Please notice that I don’t intend to be ridiculous about this. You should use standard browsers available, web servers, compilers, linters to check your code, an editor that makes you productive, appropriate testing tools and so on. I am not saying write everything in C or ams.js from scratch! I am saying, understand that the standard tools (browsers, Node.js) and the real published standards (ES, HTTP, HTML, CSS) offer (most) everything you actually really need. They are the equivalent of airlines, airplanes, passports and open borders: the things that make it possible for most people in the West to safely cross the Atlantic ocean for fun, something unimaginable 200 years ago. It is not the bonus programs, airport lounges or in-flight-entertainment that make a significant difference when travelling between continents.

A simple test case
I decided to write a very simple responsive web page. It allows you to enter a date and obtain the weekday. It is not a datepicker test. I use:

  • Moment to validate input date YYYY-MM-DD
  • Moment to calculate week day
  • Bootstrap to make the application responsive (it looks different on a mobile phone in portrait mode)
  • Vue.js for DOM manipulation

I then removed Bootstrap and Moment and used CSS and standard library Date instead.

When you try them I think you find that they essentially equivalent. Both are crude and require more work before the UX is perfect for all screen sizes. I did not intend the non-Bootstrap version to be an exact copy of the Bootstrap version (they both have their pros and cons).

Bootstrap: benefits and implications
For this simple application all I needed was the minimised bootstrap css (144k, larger than vue, moment and my code together), no javascript code.

With Bootstrap my CSS was 10 lines. Even for this trivial application Bootstrap did not satisfy my requirements (this may be due to my ignorance when it comes to Bootstrap). The HTML code was 37 lines.

Without Bootstrap my CSS was 39 lines and the HTML code was 27 lines. This basically means that writing my own (more specific, reusable) CSS allows for more compact and consistent HTML.

I am not saying this is real evidence for anything or that the solutions are perfectly equivalent. I am just saying that Bootstrap is not like getting from Paris to LA for free. It is more like starting in London instead of Paris. And you will hardly write more compact HTML with Bootstrap then you would with a well crafted project specific CSS.

Moment.js: benefits and implications
I will just show the code. With Moment:

      function dateValidate(d) {
        return d === moment(d, 'YYYY-MM-DD').format('YYYY-MM-DD');
      }
      function dateToWeekday(d) {
        return moment(d, 'YYYY-MM-DD').format('dddd');
      }

As you can see, I wrapped Moment to make the component code cleaner. Using standard library Date instead of Moment:

      function zPad(x,l) {
        var r = '' + x;
        while ( r.length < l ) r = '0' + r;
        return r;
      }
      function jsDateToStr(d) {
        return zPad(d.getFullYear(),4) + '-'
             + zPad(d.getMonth()+1 ,2) + '-'
             + zPad(d.getDate()    ,2);
      }
      function strToJsDate(s) {
        return new Date( +(s.substr(0,4))   ,
                         +(s.substr(5,2))-1 ,
                         +(s.substr(8,2)) );
      }
      function dateValidate(d) {
        return d === jsDateToStr(strToJsDate(d));
      }
      function dateToWeekday(s) {
        return ['Sunday','Monday','Tuesday','Wednesday','Thursday',
                'Friday','Saturday'][strToJsDate(s).getDay()];
      }

In a real project you would probably have a pad-function available but now I wrote one. And perhaps there are better ways to use the standard library.

My point here is that if you don’t do much Date-manipulation, using Moment eliminates 10 lines of code (at the cost of an external dependency of 51k minimized). These 10 lines of code are something every programmer should be very capable of writing, they are easily testable, and highly reusable.

Vue.js
How about eliminating Vue.js as well? The ironic thing is that I don’t know how to do direct DOM manipulation (with or without JQuery). So I just presume that vue.js is worth it at 87k minimized.

If I did know how to eliminate Vue.js I would at least have a clue about what its value actually is. Now I just trust I am better off with it than without it. And that is what I encourage you not to do about every external dependency that could be used in your project.

More Reading
I found this blog post interesting.

BTW: Bootstrap sucks
I am not claiming that my no-bootstrap-version is perfect. But I think Bootstrap gets responsive UX wrong. My little appliation looks ridiculous on a really wide screen. I don’t need room for more than 10 characters, and the buttons don’t need to be spread out. A good responsive design reorganises blocks of content without changing the size of elements such as buttons.

BTW: Moment is slower
I made some benchmarks of my date validation functions based on Moment and based on Standard Library. Depending on Moment roughly doubled execution times. On my Chromebook I could do about 10000 validations per second, which is not a huge number. There might be better ways to check if a date is valid (both for Moment and Standard Library) so perhaps this is nonsense.

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Time limit is exhausted. Please reload CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.