Improve bad code

How-to setup GDPR cookie consent with Gatsby

Sun, 26 Jan 2020 00:00:00 GMT

General Data Protection Regulation (GDPR) imposes a couple of requirements on websites in regard to collecting and processing user data.

Simple tracking solutions like Google Analytics or Facebook Pixel can only be used in compliance when the users agree with their visits and actions being tracked.

To make your Gatsby site compliant there are two parts you need to implement.

Allow or prevent user data to be collected based on user choice.
Give the user a choice to opt-in or opt-out to have their data collected.

Control when users data is collected

To be compliant with GDPR, no user data can be collected unless the user gave an explicit consent. When it comes to tracking scripts that means the scripts can’t be activated before the user gives the consent.

A convenient Gatsby plugin takes care of this part. The gatsby-plugin-gdpr-cookies checks for two cookies that control if Google Analytics or Facebook Pixel scripts should be activated.

The cookies are named after the scripts gatsby-gdpr-google-analytics and gatsby-gdpr-facebook-pixel. When these cookies value is true the scripts are activated.

You can install the plugin using npm:

npm install --save gatsby-plugin-gdpr-cookies

To configure the plugin put the configuration in your gatsby-config.js:

module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-gdpr-cookies`,
      options: {
        googleAnalytics: {
          trackingId: 'YOUR_GOOGLE_ANALYTICS_TRACKING_ID',
          // Setting this parameter is optional
          anonymize: true
        },
        facebookPixel: {
          pixelId: 'YOUR_FACEBOOK_PIXEL_ID'
        },
        // Defines the environments where the tracking should be available  - default is ["production"]
        environments: ['production', 'development']
      },
    },
  ],
};

Collect user consent

Giving the user a way to give consent for their data to be collected can be done by building your own form and setting the cookies (gatsby-gdpr-google-analytics and gatsby-gdpr-facebook-pixel).

If you’re using React in your Gatsby site, you can opt for a ready made solution react-cookie-consent.

The React component comes packaged in an npm module, so you can add it to your project by running:

npm install --save react-cookie-consent

After that add the component in your layout.js file or wherever you define your layout. It’s important that the component is loaded on any page so the consent can be collected regardless of the entry page.

import CookieConsent from 'react-cookie-consent';

<CookieConsent
          location="bottom"
          buttonText="Accept"
          declineButtonText="Decline"
          cookieName="gatsby-gdpr-google-analytics">
This site uses cookies ...
</CookieConsent>

The important part is to set the cookieName prop to the value of the cookie you want to set (e.g.: gatsby-gdpr-google-analytics).

There are many props to configure the components behaviour and appearance.

Quick tip When you want to set both cookies with one action, you can hook into the flow by using the onAccept and onDecline callbacks. You can set the cookies yourself by importing the Cookies (from js-cookie) like this:

import CookieConsent, { Cookies } from "react-cookie-consent";

Hopefully this helped you making your Gatsby site GDPR compliant.

P.S.: I wrote a short StackOverflow answer on this topic as well after solving this for my own Gatsby sites.

Conditional statement the safe way

Mon, 15 Jun 2015 00:00:00 GMT

This post will be really short. No big story behind it, just a simple habit that you should practice to give the quality of your code a level up.

Conditional statements seem easy and there should be no real complexity behind them. On the other hand how many times a simple mistake like this happened to you?

BAD CODE

<?php
 
if ($payment = 100) {
    // do something here
}
else {
    // do something else here
}

Did you catch the issue in the conditional statement above? This sort of thing happens a lot, regardless if you’re a novice developer or a software architect ninja. Using an assignment operator (=) instead of a comparison operator (==) can lead to unexpected behavior from overwriting a variable. However, there is a simple trick, to catch these errors before they turn your day into a sad bug hunting trip.

GOOD CODE

<?php
 
if (100 == $payment) {
    // do something here
}
else {
    // do something else here
}

The easy trick to getting your conditional expressions safe is to turn them around. In this case, if we would make the mistake of using an assignment (=) instead of a comparison (==), since you can’t assign values to constants. Such errors are then caught early on, before they make it into some part of your code, that is later behaving strangely.

Hope you find this short tip useful, please share your ideas in the comments below.

Conditional statement the readable way

Wed, 03 Jun 2015 00:00:00 GMT

Conditional statements and conditional expressions are a good way to branch our computational or business logic. Sometimes we as developers can be tempted to combine multiple conditional expressions in one long worm-like expression that is hard to understand, let alone test. Such cases should either be avoided or follow a coding style guide, which would at the very least improve the readability of a combined expression.

Readability wise, long combined conditional expressions can be extracted into a method, which can have a nice descriptive name.

GOOD CODE

<?php
 
if ($this->positiveBalance($account)) {
    // do something here
}
else {
    // do something else here
}

Reading this conditional it is immediately clear what it is checking. The actual conditional expression can be more complex, but that is no reason to decrease the readability of the code. Here’s an example of a badly written conditional expression, which is following a coding style guide for readability, but is stil hard to comprehend.

BAD CODE

<?php
 
if (
       ($account['balance'] > 0
        && $account['status'] == 'active')
       || ($account['hasLimit'] == true
           && $account['balance'] > $account['limit'])) {
    // do something here
}
else {
    // do something else here
}

Untestable code and how-to improve it

Tue, 06 Jan 2015 00:00:00 GMT

Did you find out what was the key culprit of the untestable code segment in my previous post How to recognize bad code?

If you don’t have the time to spend reading the previous article, here’s the problematic code segment again. Let’s just dive straight in.

<?php
  
namespace \CompanyX;
  
class CokeDispenser {
  
    protected $coinCollector;
  
    public function __construct() {
        $this->coinCollector = new CoinCollector();
    }
  
    public function getCoke() {
        if ($this->coinCollector->collectedAmount() >= 2.0) {
            return 'coke';
        }
    }
}

Testability of the code is defined by the openness of the design and loose coupling of the collaborating classes. In this example we can clearly spot two issues.

Actual work in the constructor
Collaborating class instantiation within the class

Both of these issues make testing of the CokeDispenser class difficult, but combined they make it nearly impossible. Let’s take a quick look at why this is bad.

Actual work in the constructor

While there is nothing wrong with having code in the constructor of the class, that code should only be operating on the properties of the class and not doing any “real” work.

BAD CODE

<?php
namespace \CompanyX;
  
class CokeDispenser {
  
    protected $coinCollector;
  
    public function __construct() {
        $this->coinCollector = new CoinCollector();
    }
}

This code is clearly doing “real” work and what’s even worse it has side effects. Whenever we instantiate a CokeDispenser class, a CoinCollector object is created as a side effect. Definitely not what we desire or expect from instantiating a CokeDispenser object. Not to mention, that it’s violating the Single Responsibility Principle.

Collaborating class instantiation within the class

Objects are rarely isolated and mostly they collaborate with instances of other classes. In such cases there are some good practices to follow in order to make the classes loosely coupled with their collaborators.

BAD CODE

<?php
 
namespace \CompanyX;
  
class CokeDispenser {
  
    protected $coinCollector;
  
    public function __construct() {
        $this->coinCollector = new CoinCollector();
    }
}

The CokeDispenser class is glued to the CoinCollector class, since that class is instantiated in the constructor. It would be difficult to exchange the “Payment Collector” with some other class like CreditCardProcessor or SmartCardProcessor.

In writing good and loosely coupled code, we strive for loosely coupled designs. Who knows which classes will our class have to collaborate with in the future. Two rules to abide by are:

Program to abstractions
Ask for collaborators, don’t look for them

To improve our problematic piece of code, we’ll abide by both these rules and create a nicely loosely coupled CokeDispenser.

GOOD CODE

First we’ll abstract the CoinCollector class with creating an interface called PaymentCollector and make CoinCollector implement that interface.

So here’s the PaymentCollector interface.

<?php
 
namespace \CompanyX;
 
interface PaymentCollector {
    public function collectedAmount();
}

Let’s make CoinCollector implement the PaymentCollector interface.

<?php
 
namespace \CompanyX;
 
class CoinCollector implements PaymentCollector {
 
    public function collectedAmount() {
        return $this->collectedCoinsAmount;
    }
}

Lastly let’s change the CokeDispenser class to ask for a PaymentCollector class in its constructor. This way our CokeDispenser clearly asks for the collaborating class and doesn’t attempt to create it on its own. Following the Single Responsibility Principle, the CokeDispensers single responsibility is to dispense Cokes, not create CoinCollectors.

<?php
 
namespace \CompanyX;
 
class CokeDispenser {
 
    protected $paymentCollector;
 
    public function __construct(PaymentCollector $collector) {
        $this->paymentCollector = $collector;
    }
 
    public function getCoke() {
        if ($this->paymentCollector->collectedAmount() >= 2.0) {
            return 'coke';
        }
    }
}

This way our CokeDispenser class can easily be tested using a DummyPaymentCollector class that implements the PaymentCollector interface.

I hope this example was easy enough to follow how we turned a badly designed CokeDispenser class that was bound to the CoinCollector collaborator class and turned it into a testable and extendable class.

When you look at it now, it all makes sense. A CokeDispenser needs some sort of a PaymentCollector (coins, bank notes, credit cards, smart cards, …) and our improved class can support them all without any needed modifications for whatever the future brings (i.e.: ImplantedChipPaymentProcessor, BitCoinCollector …).

Coding style quick improvement tip – IF statements

Tue, 06 Jan 2015 00:00:00 GMT

In my todays quick improvement tip for your coding style we’ll be focusing on the control structures, more accurately the IF statements.

BAD CODE

<?php
 
if($owedAmount>1000)
    send_email_to_client('owes_over_1000');

While there is nothing syntactically or semantically wrong with this code it is following bad practice and might provide a place for future bugs to hide. Let’s imagine we want to send an extra email to our billing department. With an inattentive programer, the inclusion of the required curly braces could be simply overlooked.

We could end up with a code like this. A nasty bug would find its new home and send false emails to our billing department.

BAD CODE

<?php
 
if($owedAmount>1000)
    send_email_to_client('owes_over_1000');
    send_email_to_billing('owes_over_1000');

Putting some care into our code when writing it, we can take care of such pitfalls and protect us or other programers from unintentionally creating bugs.

So let’s clear up this code so it reads better and is more solid. First we’ll add spaces to separate the language keywords from the parentheses and add curly braces to clearly define which part of the code, the control structure controls. While we’re at it, we will also add spaces around the logical operators to more clearly distinguish the parts of the logical expression.

GOOD CODE

<?php
 
if ($owedAmount > 1000) {
    send_email_to_client('owes_over_1000');
}

As you can see, the result is much easier to read and we removed the possibility of creating a bug when adding code to this control structure.

We have been following the PSR-2 Coding Style Guide for PHP.

These are the rules we followed:

Control structure keywords MUST have one space after them; method and function calls MUST NOT.
Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

Code readability is a big part of good code and it is essential for any good programer to follow a coding style guide. The primary benefit is that other programers will read your code more easily. But it can also provide a few not so apparent improvements of the code quality, like removing places for bugs to hide as in our example.

How to recognize bad code?

Sat, 13 Dec 2014 00:00:00 GMT

What is bad code and how to spot it immediately?

A simple description would say bad code equals untested or untestable code. While the former is something that can rather easily be overcome, the latter is a completely different story. It is unfortunately present in many legacy applications and takes a big amount of commitment and knowledge to overcome successfully. Untestable code can quickly find its way into modern applications if we’re not paying attention when designing our code.

So let’s focus on both cases to see where this big difference comes from.

Untested code

Untested code is the code for which no tests exist. Depending on the quality of the code, this can be overcome quickly and easily or slowly and painfully. Let’s jump straight into an example in CompanyX.

<?php
 
namespace \CompanyX;
 
class CokeDispenser {
    public function getCoke() {
        return 'coke';
    }
}

The class CokeDispenser is a very simplified class and the following is a test written in PHPUnit that shows how easy it is to write a test that validates this class.

<?php
 
use \CompanyX\CokeDispenser;
 
class CokeDispenserTest extends PHPUnit_Framework_TestCase {
 
    /**
    * @before
    */
    public function setUp() {
        $this->cokeDispenser = new CokeDispenser();
    }
 
    /**
    * @test
    */
    public function shouldReturnACokeWhenGetCokeIsCalled()
    {
        $expectedResult = 'coke';
        $this->assertEquals($expectedResult, $this->cokeDispenser->getCoke());
    }
}

Untestable code

The previous example code was intentionally very simple, but that should be your goal when designing your code. Keeping things simple and straightforward is the key in making your designs testable. Cutting corners and hacking your way without taking the time to think the design through will mostly result in untestable code. And combining loads of untestable code will eventually mount up into what we like to call spaghetti code, which is a pile of disorganized coding mess. A developers hell if you’d like and in time, such code starts to rot, scaring novice developers away.

It also discourages better developers from diving in, since such code will clearly require a lot of effort upfront before it will become graspable and maintainable. So let’s take a look at some untestable code.

<?php
 
namespace \CompanyX;
 
class CokeDispenser {
 
    protected $coinCollector;
 
    public function __construct() {
        $this->coinCollector = new CoinCollector();
    }
 
    public function getCoke() {
        if ($this->coinCollector->collectedAmount() >= 2.0) {
            return 'coke';
        }
    }
}

This code looks quite simple and clean, but testing or extending it is a nightmare. We’ll take a closer look in the next post . Can you spot what’s wrong with it? Write your comments below. Until next time!