newspaint

Documenting Problems That Were Difficult To Find The Answer To

Monthly Archives: Mar 2024

Compilers Treating Unused Variables as Errors

It seems to be a recent phenomenon where some new programming languages have decided to treat the presence of an unused variable in code as an error that causes compilation to fail.

This never used to be an issue. The presence of a declared variable that had never been read/used could produce a warning but it certainly wasn’t a compiler error.

Arguments in favour of this behaviour are along the lines of “it helped me identify bugs in my code”. Such arguments ignore that exactly the same could be achieved by paying attention to warnings and changing the code until those warnings were no longer produced.

Arguments against this behaviour, however, hold much greater weight. It is a common debugging pattern to comment out a block or line of code to observe what difference this makes at runtime. Having to identify a variable declaration elsewhere, however, in order to comment it out or to change it to a placeholder requires significantly more effort and also necessitates remembering those changes which will need reversing when the code block is uncommented/restored.

Ultimately what is the goal of turning all warnings into errors? The sole reason must be to avoid broken code being published in that language. It is reputational damage control.

These language designers are fearful of the reputation of languages like Perl or C – which allow the developer the freedom to write as clean or messy code as they wish. If, however, they could make the compiler so strict that no broken code could ever be published then the language’s reputation may remain strong.

It is a propaganda tool. Nothing more.

And like any propaganda tool it is half truths mixed with half lies. It does not result in “better” code. Only code written by developers who do not have a thorough understanding of the difference between development and production. In other words mediocre programmers. Experienced developers will abandon nannying languages and use those that offer flexibility and pragmatism.

GenieACS Provision Script Helper Functions

The following are some helper functions that can be added to a GenieACS provision script to make things easier.

// getFirstValue() - takes iterator and returns the first value found
//
// Usage (to create new branch and return the path to it):
//   var softwareVersion = getFirstPath(
//     declare( "InternetGatewayDevice.DeviceInfo.SoftwareVersion", {value:0} )
//   );
//
//   if ( ! softwareVersion ) {
//     softwareVersion = getFirstPath(
//       declare( "Device.DeviceInfo.SoftwareVersion", {value:0} )
//     );
//   }

function getFirstValue( iterator ) {
  for (let element of iterator) {
    if ( element.value && ( element.value[0] != undefined ) ) {
      return element.value[0];
    }
  }

  return undefined;
}
// getFirstPath() - takes iterator and returns the first path found
//
// Usage (to create new branch and return the path to it):
//   const newPathWANPPPConnection = getFirstPath(
//     declare(
//       `${pathWANConnectionDevice}.WANPPPConnection.[Name:MyNewPPP]`,
//       {path: now},
//       {path: 1}
//     )
//   );

function getFirstPath( iterator ) {
  for (let element of iterator) {
    if ( element.path ) {
      return element.path;
    }
  }

  return undefined;
}