DEV Community: Sergii Shymko

Do Programmers Need to Know Math?

Sergii Shymko — Mon, 07 Nov 2022 17:11:00 +0000

The debate of whether being good at math makes for a great programmer is as old as the tech industry itself. Opinions are wildly polarizing ranging from completely discarding mathematics as irrelevant to claiming a math or CS degree to be an absolute prerequisite for software engineering.

As always, the truth is somewhere in the middle of the spectrum. This write-up aims to give a practical example of how math can inform programming.

Disclaimer

No doubt, there are niche areas of programming that require unique skill sets and/or specialized education. For example: computer graphics, image/video processing, cryptography, machine learning, modeling physical processes, etc. Some of these are closer to scientific research than practical programing and may indeed require academic training.

As opposed to the domains above, general purpose software engineering is all about mundane business applications: desktop, mobile, and web applications. It's not rocket science.

Practical Example

Consider a practical coding example that most developers encounter early on in their career. The task is to render a human-friendly rounded number with a unit prefix, for example:

350,000 → 350K
1,500,000 → 1.5M
and so on.

This algorithm is everywhere: from financial charts to YouTube likes.

Here's a recent Tweet from the Laravel community on the topic.

Matt Kingshott

@mattkingshott

🔥 #Laravel Tip: When dealing with large numbers e.g. for analytics, the exact value often becomes less important the larger it gets. It can therefore be better to simplify the value when displaying it in the UI…

14:40 PM - 01 Feb 2022

Code snippets are in PHP, but they translate to any high-level programming language, such as JavaScript.

Basic Implementation

A straightforward implementation would be to handle conversion to each unit of measurement individually, checking for all supported integer ranges.

The initial implementation:

function formatNumber(
    int|float $number,
    int $precision = 1
): string {
    if ($number < 1000) {
        $result = $number;
        $unit = '';
    } else if ($number < 1000000) {
        $result = $number / 1000;
        $unit = 'K';
    } else if ($number < 1000000000) {
        $result = $number / 1000000;
        $unit = 'M';
    } else {
        $result = $number / 1000000000;
        $unit = 'B';
    }
    return (string)round($result, $precision) . $unit;
}

This algorithm has several disadvantages.

One of the biggest drawbacks is having to modify source code to register new unit prefixes; they're hard-coded in the implementation. It's not universal enough to serve as a reusable library.

Another disadvantage is the duplication of 1000s across the implementation. You need to type in 0s very carefully to not make a mistake.

Let's try to overcome these limitations.

Generalized Implementation

The next iteration in the evolution of our algorithm accepts units as input and loops over them. It now works with any number of unit prefixes!

The improved implementation:

function formatNumber(
    int|float $number,
    int $precision = 1,
    int $base = 1000,
    array $units = ['K', 'M', 'B']
): string {
    $result = $number;
    $unit = '';
    $unitCount = count($units);
    for ($unitIndex = 0; $unitIndex < $unitCount; $unitIndex++) {
        if ($result < $base) {
            break;
        }
        $result = $result / $base;
        $unit = $units[$unitIndex];
    }
    return (string)round($result, $precision) . $unit;
}

For a fixed set of units, this loop-based approach is equivalent to the original implementation, just more flexible.

Now that the base factor 1000 isn't hard-coded anymore, both decimal and binary units are supported, for instance:

formatNumber($number, base: 1024, units: ['KiB', 'MiB', 'GiB'])

We haven't considered algorithmic complexity yet, let's see where the implementation stands. The time complexity in Big O notation is O(n), where n is the number of unit prefixes.

The algorithm is pretty flexible, short, and easy to understand and maintain. But can the linear complexity be improved upon?

Optimized Implementation

Making further improvements requires completely rethinking the approach. Ideally, the algorithm should be independent of the input size. That means there should be no loop at all.

Take a closer look at the algorithm. What does each iteration do? It calculates intermediate results, building upon results of the previous iteration. But can we jump to the solution immediately? That's where math comes in.

Each iteration gradually converts the input number to ever larger units. The number of iterations corresponds to the largest applicable unit. Each division essentially increments the power of the base used in the conversion.

We can convert the input number to the respective unit by dividing it by the base raised to the power of the unit. How do we determine the base power? We can use logarithms to calculate the power of the base yielding the input number. Then round it down to the closest integer. That also gives us the sequential index in the units array (to be adjusted for zero-based indexes). And voilà, we get both the converted number and its unit prefix!

The final implementation:

function formatNumber(
    int|float $number,
    int $precision = 1,
    int $base = 1000,
    array $units = ['K', 'M', 'B']
): string {
    $unitCount = count($units);
    $power = (int)floor(log(abs($number), $base));
    $power = min($power, $unitCount);
    $result = $number / pow($base, $power);
    $unitIndex = $power - 1;
    $unit = $units[$unitIndex] ?? '';
    return (string)round($result, $precision) . $unit;
}

Expression min($power, $unitCount) limits the algorithm to units whose prefixes have been defined, i.e. the conversion stops at the largest unit.

Note that abs($number) makes it work for negative numbers, support of which all previous implementations have overlooked.

The time complexity of the algorithm is O(1) as it completes in a fixed time regardless of the number of unit prefixes. Absence of conditionals and loops also improves other code quality metrics, namely Cyclomatic complexity and NPath complexity.

Conclusion

Math is by no means required in day-to-day coding. In practice, even if it does come down to advanced math, one would use an existing library provided by the rich OSS ecosystem of their tech stack.

However, middle school algebra and geometry do occasionally come in handy in programming. Mathematics underlies performance optimizations of certain otherwise resource-intensive algorithms: proficiency in the subject allows to understand and implement these optimizations.

Happy programming, with or without math!

Arrow Function vs Function

Sergii Shymko — Fri, 30 Oct 2020 20:53:18 +0000

In JavaScript, arrow functions provide a concise syntax for anonymous function expressions stripped off of their OOP baggage. They are a syntactic sugar on a subset of the function capabilities. Both can be used as closures capturing variables of the outer scope.

Arrow functions are part of the ECMAScript 2015 standard also known as ES6. We will unpack variations of the arrow function ES6 syntax to their analogous function implementation and discuss the differences.

The article assumes familiarity with the traditional functions and builds on the prior knowledge by drawing parallels between the two language mechanisms.

Syntax

The "fat arrow" syntax => is dedicated to arrow functions, hence the name.

Arrow function declaration:

(arg1, arg2, ..., argN) => expression

Equivalent anonymous function:

(function (arg1, arg2, ..., argN) {
  return expression;
}).bind(this)

There's a lot going on here: omitted keywords, the implicit return statement, this context binding. Each aspect is discussed separately below.

Semantics

Return Expression

Unlike ordinary functions (anonymous or otherwise), arrow functions implicitly return an evaluated expression without having to use the return statement.

Arrow function:

(arg1, arg2, ..., argN) => expression

Equivalent anonymous function:

function (arg1, arg2, ..., argN) {
  return expression;
}

Once you get used to the syntax, you'll appreciate how much shorter the code becomes and would never want to go back.

Block Statement

The short return expression syntax cannot represent sequence of statements. That's where the familiar block statement {} comes in. Within the curly braces you'd have to explicitly return result of the function.

Arrow function:

(arg1, arg2, ..., argN) => {
  let result = doSomething();
  doDependentThing(result);
  return result;
}

Equivalent anonymous function:

function (arg1, arg2, ..., argN) {
  let result = doSomething();
  doDependentThing(result);
  return result;
}

The functions look more alike now, don't they?

Object Expression

Functions often return newly constructed objects. There's a catch: the object declaration notation {} is clashes with the block statement syntax. The solution is to surround the inline object with () to make it an expression.

Arrow function:

(arg1, arg2, ..., argN) => ({
  prop1: value1,
  prop2: value2,
  ...,
  propN: valueN
})

Equivalent anonymous function:

function (arg1, arg2, ..., argN) {
  return {
    prop1: value1,
    prop2: value2,
    ...,
    propN: valueN
  };
}

Single Argument

There's an extra syntactic sugar for a special case of an arrow function having only one argument. You can omit the parentheses () around the argument.

Arrow function:

arg => expression

Equivalent anonymous function:

function (arg) {
  return expression;
}

No Arguments

An arrow function w/o arguments is just an edge case of empty parentheses. Unlike the single argument syntax, the parentheses are required here.

Arrow function:

() => expression

Equivalent anonymous function:

function () {
  return expression;
}

Context Binding

Let's talk about the elephant in the room – the this context. Arrow functions aside, this (pun intended) has always been a confusing topic in JavaScript.

Functions have access to a special variable this holding the context assigned in runtime. The problem is that the value varies depending on how the function is called which is error-prone and often undesirable.

With callbacks being the primary use case, in most cases you'd want access to this context defined at a declaration time, not at invocation. You'd find yourself sprinkling your code with the following closure boilerplate:

let self = this;
let callback = function () {
  self.doSomething();
};

or the re-binding to avoid self in the callback:

let callback = function () {
  this.doSomething();
};
callback = callback.bind(this);

In contrast, arrow functions provide no this context of their own and instead inherit the current "lexical" scope. They're naturally suited for inline callbacks.

Equivalent arrow function:

let callback = () => void this.doSomething();

The void operator discards the result returned by this.doSomething(), if any. In practice, passing the result though is often okay and void can be omitted. The block statement {} is another (perhaps better) way to ignore the result.

Class Methods

Arrow functions come in handy in classes due to the nature of this context. Ordinary methods are prone to losing class context when called from outside of class methods. Arrow methods are immune to this issue.

The arrow method syntax is nothing but a class property declaration with an arrow function assigned in place of the value. Note the class properties are introduced in the ECMAScript 2017 specification.

Arrow method (arrow function property):

class Example {
  constructor(arg) {
    this.arg = arg;
  }

  callback = () => {
    console.log(this.arg);
  }
}

Equivalent ES6 class method:

class Example {
  constructor(arg) {
    this.arg = arg;
    this.callback = this.callback.bind(this);
  }

  callback() {
    console.log(this.arg);
  }
}

Examples

Loop Refactoring

Single argument is quite common in array method callbacks, such as map() and its cousins, that iterate over items.

Loop over array of items:

let ids = [];
for (let i = 0; i < items.length; i++) {
  ids.push(items[i].id);
}
return ids;

Equivalent traditional function implementation:

let ids = items.map(function (item) {
  return item.id;
});

Equivalent arrow function implementation:

let ids = items.map(item => item.id);

This example vividly demonstrates the level of code compression provided by arrow functions without sacrificing readability and even improving it.

Enjoy the utility of arrow functions in your modern JavaScript code!

Objective Code Review

Sergii Shymko — Fri, 25 Sep 2020 01:03:49 +0000

Code review (peer review) is an established software development practice. Having another pair of eyes to validate an implementation is a proven quality control measure. It facilitates collaboration and knowledge sharing between team members. On the flip side, it creates an avenue where opinions and personalities collide which can hurt the team morale and hinder productivity.

This article establishes a formal approach to conducting code reviews in an objective methodical manner. It aims to take personal opinions, biases, and attitudes out of the equation.

The described code review process was established in 2011 during the early development phases of Magento 2. It arose out of frustration with subjectivity of the views and disagreements between opinionated architects/developers during mutual code reviews. Since then the process has matured and been successfully applied on projects of various sizes using diverse technologies.

Review Process

Actors:

Author — developer who implemented a Changeset
Reviewer — engineer qualified to conduct code reviews

Workflow:

Author ensures the Changeset is free from Code Defects
Author submits the Changeset for a code review
Reviewer validates the Changeset against the Defect Classification
Reviewer identifies Code Defects in defect comments
Reviewer posts recommendations in non-defect comments
Reviewer accepts the Changeset if no Code Defects have been identified
Reviewer rejects the Changeset if any Code Defects have been identified
Author fixes the identified Code Defects
Author considers non-defect comments

Roles

Author

Author takes full responsibility for his/her implementation to be defect-free. Reviewer is a safety net and not a substitute for personal quality control.

Author must be intimately familiar with the code review process to foresee its outcome. The code review workflow should not be started until there's a confidence in the implementation passing without any changes.

Reviewer

The Defect Classification plays the role of the quality arbiter, not Reviewers.

Reviewer must identify Code Defects and clearly articulate why changes fall under respective categories of the Defect Classification. It is helpful to outline an alternative defect-free implementation.

Reviewer can use non-defect comments to propose optional changes deemed to be beneficial. It's at the Author's sole discretion whether to act on such recommendations or ignore them. Reputation and communication skills of the Reviewer will be a factor here.

It's up to the team how to appoint Reviewers. Strong teams where members are on about the same level, can review after each other. Less experienced teams may benefit from external senior engineers conducting code reviews. Dedicated part-time reviewers will become a bottleneck and team members should grow into reviewing one another.

Code Defects

The Defect Classification represents the baseline code quality requirements imposed on all code changes. It's a collective team effort to refine it.

Once the team agrees to formalize a substandard coding practice as a Code Defect, it becomes a hard requirement to follow from that point on.

The Defect Classification:

1. Standards Violation
2. Logic Duplication
3. Unreliable Implementation
4. Technology Misuse
5. Performance Degradation
6. Security Vulnerability

1. Standards Violation

Established standards and adopted conventions must be obeyed at all times. The team documents an exhaustive list of the standards and can amend it.

Scope:

Coding standards for each technology
- Naming conventions
- Typos, misspells, grammatical errors
Automated testing standards
- Types of tests: unit, integration, functional, performance
- Code coverage

2. Logic Duplication

Copy-pasting any non-trivial code identically or with variations is discouraged.

Scope:

Copied file
Copied business rules
Copied algorithm
Copied expression: formula, regular expression, SQL, XPath, etc.

3. Unreliable Implementation

Unreliable code may produce an error or behave inadequately under specific conditions or on certain input data.

Scope:

Backend
- Unsafe data manipulation
- Data type assumptions
- Data structure assumptions
- Unreliable error handling: suppressing exceptions
- Dead code: unreachable statements, unused dependencies
- Data corruption risk: unhandled race conditions
- Infinite loops
- Infinite recursion
- Errors in logs
Frontend
- Incompatibility with supported browsers
- Unsafe DOM access
- Dependency on timing of events
- Errors in developer console
Database
- Mishandling transactions: asymmetric begin & commit/rollback
- Data integrity issues: missing foreign keys in RDBMS

4. Technology Misuse

Technologies, languages, and frameworks should be used to the full extent of their capabilities according to established best practices.

Scope:

Project directory structure
Ignoring built-in capabilities of a language/framework
Alternative implementation of existing functionality
Violation of dependency boundaries between application tiers

5. Performance Degradation

Performance impact of code changes should be avoided as much as possible.

Scope:

Backend
- Heavy operations in constructors
- Loading unused data
- Computing unused data
Frontend
- Loading unused assets: CSS, JavaScript, images, fonts
- Executing no-op JavaScript
- Excessive AJAX requests
- High network bandwidth usage
Database
- Missing/unused indexes
- Repetitive database queries
- SELECT more records than necessary
- CRUD multiple records one by one

6. Security Vulnerability

Potential security vulnerabilities must be avoided regardless of whether they're exploitable at the moment or not.

Scope:

Infrastructure
- Unnecessary public access
- Unencrypted connection: HTTP, FTP
- Compromised hashing algorithms: MD5, SHA1, etc.
- Insufficient encryption strength: SSL, TLSv1, etc.
- PCI DSS compliance violation: storing credit cards
- OWASP Top 10 threats exposure
- CORS misconfiguration
Backend
- Insufficient user input validation
- Dangerous functions: shell, eval, file system functions
Frontend
- Rendering unescaped markup
- Non-secure cookies accessible via JavaScript
Database (can be considered misuse of a framework)
- Raw SQL
- Bypassing DBAL
- Bypassing query builder
- Not using prepared statements

The code review process is a template applicable to almost any tech stack, particularly web-applications. Fill in the technologies specific to your project and reference the corresponding standards and the process is ready to go.

Enjoy the constructive stress-free code reviews!

Demystifying Exceptions

Sergii Shymko — Mon, 09 Mar 2020 18:38:38 +0000

A solid understanding of exceptions is crucial to writing reliable programs. This article aims to lift the veil of mystery surrounding peculiar aspects of exception handling by unraveling their inner workings to familiar concepts.

The code examples and some nuances are specific to PHP, but the principles are transferable to other languages — particularly JavaScript.

Introduction

Exceptions are a special language mechanism designated for error handling. It relieves programmers of the need to reinvent ad hoc error formats and means for error carryover across the call stack. Without support on the language level, source code would be muddled with tedious error pass-through boilerplate.

Exceptions do not necessarily mean errors, although these words are often used interchangeably. They represent negative scenarios in an otherwise optimistic execution flow. In a broader sense, they’re exceptional situations defined by a programmer as worthy distinguishing in a particular domain.

Let the syntax guide us in unwinding the exception-handling behavior.

throw

The throw operator emits an exception that stops the normal sequential execution flow of a program, passing control to the exception-handling mechanism.

Common way to trigger an exception:

throw new \Exception;

Resist the temptation to ascribe extra significance to the throw new expression. Keywords throw and new belong to independent paradigms (exceptions and OOP, respectively). Exceptions just happen to be object-oriented and throw works on exception objects carrying debug information.

Here’s a more verbose equivalent:

$e = new \Exception();
throw $e;

Exceptions are often created inline right before use, but that doesn’t have to always be the case. An exception object can be instantiated, passed around, and kept in memory arbitrarily long before being thrown or even discarded.

Exceptions are ordinary objects with properties and methods. They can use inheritance to form hierarchies like other classes. There’s one unique trait: Exceptions must extend a class, such as \Exception, that can be thrown.

PHP 7 features \Throwable interface implemented by both \Exception and \Error classes, with the latter replacing the error-handling mechanism.

Whether you can locate a source code that triggered an exception or not, assume there’s a throw statement somewhere in there. See official docs on exceptions thrown by internal functions, as you cannot view their sources.

try..catch

Surrounding code with the try..catch block allows to handle exceptions that may be thrown during its execution at any call depth. The blocks can be nested directly or indirectly. Exceptions “bubble up” from their origin to the closest catch matching the exception type.

Basic exception-handling syntax:

try {
    doSomethingDangerous();  // throw new \Exception;
} catch (\Exception $e) {
    // ...
}

The caught exception can be either handled in full or processed partially and rethrown to give higher-level blocks a chance to participate in its handling. The empty catch block essentially suppresses or “swallows” an exception. Once fully handled, the execution proceeds to the next statement following the try..catch resuming the normal control flow of a program.

In the worst-case scenario, the exception remains unhandled and the built-in handler halts the program after outputting the debug information. Think of it as a try..catch surrounding the entire program, whose implementation echo $e; exit(255); is deliberately hidden from your eyes.

Handling of multiple exception types:

try { 
    doSomethingDangerous();
} catch (\InvalidArgumentException $e) { 
    // ...
} catch (\LogicException $e) { 
    // ...
} catch (\RuntimeException $e) { 
    // ...
}

The behavior of multiple catch clauses and dependency on declaration order can be understood using the following equivalent transformation:

try { 
    doSomethingDangerous();
} catch (\Exception $e) { 
    if ($e instanceof \InvalidArgumentException) { 
        // ...
    } else if ($e instanceof \LogicException) { 
        // ...
    } else if ($e instanceof \RuntimeException) { 
        // ...
    } else { 
        throw $e; 
    }
}

Alternative branches are mutually exclusive following the else if analogy. Exceptions of irrelevant types propagate further, as implied by throw $e.

The declaration order is important, as the evaluation stops at the first match. Parent-child relations between exception classes are carefully considered. For instance, if the \LogicException clause was declared first, it would match the subtype \InvalidArgumentException, rendering its specialized handler unreachable. Moving \RuntimeException around wouldn’t make a difference in this example, as it’s unrelated to \LogicException in the class hierarchy.

It is up to a programmer to decide which types of exceptions to handle on a particular application layer and which ones to pass through. Frameworks impose an error-handling philosophy to guide such decisions.

Rethrow

Rethrowing a caught exception is fundamentally no different from initially throwing an exception. The syntax is the same, except that throw is now called from within catch, which does have access to the exception instance. A brand new exception can be thrown instead of rethrowing the caught one.

One question arises, though: Will subsequent catch blocks of the same try construct that had caught an exception also catch a rethrown one?

try { 
    doSomethingDangerous();
} catch (\InvalidArgumentException $e) { 
    // ...
    throw new \LogicException();
} catch (\LogicException $e) { 
    // Will it catch the exception thrown above? 
    // ...
} catch (\RuntimeException $e) { 
    // ...
}

No, they won’t, as evident from the rewritten equivalent:

try { 
    doSomethingDangerous();
} catch (\Exception $e) { 
    if ($e instanceof \InvalidArgumentException) { 
        // ...
        throw new \LogicException(); 
    } else if ($e instanceof \LogicException) { 
        // Will it catch the exception thrown above? Nope 
        // ...
    } else if ($e instanceof \RuntimeException) { 
        // ...
    } else { 
        throw $e; 
    }
}

try..finally

The try..finally construct is used to specify the finalization logic to execute regardless of whether an exception occurs or not:

doSomethingSafe();
try { 
    doSomethingDangerous();
} finally { 
    undoSomethingSafe();
}

This is equivalent to the following try..catch:

doSomethingSafe();
try { 
    doSomethingDangerous(); 
    undoSomethingSafe();
} catch (\Throwable $e) { 
    undoSomethingSafe(); 
    throw $e;
}

As you can see, in the general case, the “undo” logic has to be duplicated. However, when a rethrow is not intended, the finalization logic can go after the try..catch without resorting to finally:

doSomethingSafe();
try { 
    doSomethingDangerous();
} catch (\Throwable $e) { 
    // Handle without throwing exceptions...
}
undoSomethingSafe();

try..finally..return

Besides the copy-paste relief, finally is useful in conjunction with return.

doSomethingSafe();
try { 
    return getSomethingDangerous();
} finally { 
    undoSomethingSafe();
}

This equivalent implementation reveals what’s going on underneath:

doSomethingSafe();
try { 
    $result = getSomethingDangerous(); 
    undoSomethingSafe(); 
    return $result;
} catch (\Throwable $e) { 
    undoSomethingSafe(); 
    throw $e;
}

The finally version is more concise and doesn’t use an extra variable.

finally..return

The behavior of return inside of finally is somewhat unintuitive.

try {
    return getSomethingDangerous();
} finally {
    return 'value returned no matter what';
}

The result of the call will always be discarded and any exceptions silenced!

Rewriting the code without finally makes it clear that the execution will never reach return $result or throw $e statements:

try { 
    $result = getSomethingDangerous(); 
    return 'value returned no matter what'; 
    return $result;
} catch (\Throwable $e) { 
    return 'value returned no matter what'; 
    throw $e;
}

The finally..return construct indicates a coding mistake to be avoided.

Pass on the exception-handling insights to your fellow programmers!