PHP

What is Pair Programming?

Two Minds, One Goal: The Power of Pair Programming

Pair programming is an agile software development technique in which two developers work together on the same computer to write code. One developer, called the driver, is responsible for typing the code while the other, called the observer, review the code and makes suggestions. The two developers then switch roles, with the observer becoming the driver and the driver becoming the observer.

The story of pair programming originates from a software development company called Chrysler. In the late 1990s, Chrysler was tasked with developing a new software system for its payroll operations. The project was behind schedule and the team was struggling to make progress. In desperation, the lead programmer, Xitij Kothi, suggested an unconventional solution: pair programming. He proposed that two programmers work together on each task, with one writing code while the other reviews and offers suggestions.

The strategy worked. The project was completed on time and the quality of the software was far superior to what had been expected. Since then, pair programming has become a widely accepted practice in software development.

Pair programming can reduce the time it takes to complete a task by allowing two developers to work together more effectively. By having two developers work side-by-side, they can quickly identify and resolve problems as they occur. The navigator can also provide insights into potential issues before they become problems, helping to reduce the amount of debugging and testing that needs to be done. Additionally, pair programming enables developers to learn from each other, which can help reduce the amount of time it takes to complete a task.

Pair programming also helps to spread knowledge and skills among the team members, as each programmer learns from the other. This can be especially useful in distributed software projects, where team members may be geographically dispersed.

Story Time

John and Jane had been classmates for the past couple of months, but never really got to know each other very well. They had been assigned a project in their programming class and had decided to work together. 

John was very knowledgeable in the subject and had a good understanding of what was expected. Jane, on the other hand, had little to no experience with programming but was eager to learn. Together, they decided to use the pair programming technique.

John and Jane sat down together and discussed their project. John explained the concept of pair programming, how it works, and what their roles would be. Jane was very willing to learn and was excited to get started. 

John and Jane began writing the code for their project. John took the lead and wrote most of the code while Jane watched and asked questions. Whenever Jane found a mistake or had an idea, she would suggest it to John, who would then incorporate it into the code. 

In this way, John and Jane worked together to complete their project. By the end of it, both of them had gained a better understanding of programming and had come to know each other better. 

“Pair programming had become a regular part of John and Jane’s programming class ever since.”

Issues we can face during Pair Programming and its Solutions

One type of problem that programmers can face during pair programming is communication breakdown. This is when two programmers are unable to effectively communicate with each other due to a lack of understanding or different working styles. To overcome this issue, it is important to ensure that both programmers are on the same page before starting to program. This can be done by discussing the problem, breaking it down into small manageable parts, and discussing how to approach it. It is also important to ensure that there is an equal amount of speaking and listening between the two programmers. It is also important to be aware of any language or cultural differences that may be present and to adjust your communication accordingly.

Different abilities can be a problem during pair programming because one programmer may be more knowledgeable or experienced in a certain area than the other. This can lead to the more experienced programmer taking on a larger share of the work, leaving the less experienced programmer feeling frustrated or left out. 

To overcome this, the two partners should agree on a division of tasks based on their respective strengths. For example, if one partner is more experienced with databases, they can take the lead on designing and setting up the database structure, while the other partner focuses on developing the business logic. Both partners should aim to challenge each other and provide feedback and support to ensure that the project is completed to the highest standard. Additionally, the partners should regularly rotate tasks so that both have the opportunity to learn from each other and gain a more comprehensive understanding of the project.

Task division can be a problem during pair programming if one person takes on more responsibility than the other, leaving the other feeling like they’re not contributing as much to the project. This can lead to frustration and resentment, and can ultimately undermine the collaborative nature of pair programming. To overcome this, the two people should agree on how they will divide the tasks before they begin. 

For example, they can decide that one person will take the lead on the coding while the other focuses on debugging and testing, or that each person will take turns writing sections of code. They should also make sure to have regular check-ins to discuss progress, address any issues, and ensure that both parties are on the same page. This will help ensure that both parties feel like they’re contributing equally to the project.

Distractions can be a major problem during pair programming, as they can prevent the pair from focusing on their task and completing it in a timely manner. Distractions could include anything from phones, emails, instant messages, or conversations with other people in the same room. To overcome distractions during pair programming, both partners should agree to have their phones on silent and out of sight. If possible, they should also try to find a quiet space where they can work without interruption. Additionally, they should set aside specific times to check emails and other messages and then get back to their task. They should also set specific goals and deadlines for the task ahead of time to help keep them on track.

one person may be more accustomed to writing code with fewer lines and using terse abbreviations, while the other person may prefer longer and more descriptive lines of code. This can lead to a lot of back and forth, which can slow down the programming process. To overcome this problem, it is important to have open communication and be respectful of each other’s coding styles. The pair should discuss their preferences and try to come to an agreement on which style they should use. They should also discuss the types of coding conventions they want to follow and agree on a coding style guide. Additionally, they should take time to explain their code to each other, as this can help them better understand each other’s coding styles. Finally, they should be open to feedback and criticism and be willing to compromise.

Conclusion

The importance of pair programming lies in its ability to improve the quality of code while also reducing the time it takes to develop software.

What’s new in PHP 8

PHP 8 is here! PHP 8 is a new major improved version, which means that it will introduce performance improvements and lots of new features such as the JIT compiler, union types, attributes, and more.

New features

Let’s start with all new features, it’s quite a list!

Union types

Given the dynamically typed nature of PHP, there are lots of cases where union types can be useful. Union types are a collection of two or more types which indicate that either one of those can be used.

public function foo(Foo|Bar $input): int|float;

Note that void can never be part of a union type, since it indicates “no return value at all”. Furthermore, nullable unions can be written using |null, or by using the existing ? notation:

public function foo(Foo|null $foo): void;

public function bar(?Bar $bar): void;

JIT

The JIT — just in time — compiler promises significant performance improvements, albeit not always within the context of web requests. I’ve done my own benchmarks on real-life web applications, and it seems like the JIT doesn’t make that much of a difference, if any, on those kinds of PHP projects.

The nullsafe operator

If you’re familiar with the null coalescing operator you’re already familiar with its shortcomings: it doesn’t work on method calls. Instead you need intermediate checks, or rely on optional helpers provided by some frameworks:

$startDate = $booking->getStartDate();

$dateAsString = $startDate ? $startDate->asDateTimeString() : null;

With the addition of the nullsafe operator, we can now have null coalescing-like behaviour on methods!

$dateAsString = $booking->getStartDate()?->asDateTimeString();

Named arguments

Named arguments allow you to pass in values to a function, by specifying the value name, so that you don’t have to take their order into consideration, and you can also skip optional parameters!

function foo(string $a, string $b, ?string $c = null, ?string $d = null) 
{ /* … */ }

foo(
    b: 'value b', 
    a: 'value a', 
    d: 'value d',
);

Attributes

Attributes, commonly known as annotations in other languages, offers a way to add meta data to classes, without having to parse docblocks.

As for a quick look, here’s an example of what attributes look like, from the RFC:

use App\Attributes\ExampleAttribute;

#[ExampleAttribute]
class Foo
{
    #[ExampleAttribute]
    public const FOO = 'foo';
 
    #[ExampleAttribute]
    public $x;
 
    #[ExampleAttribute]
    public function foo(#[ExampleAttribute] $bar) { }
}

#[Attribute]
class ExampleAttribute
{
    public $value;
 
    public function __construct($value)
    {
        $this->value = $value;
    }
}

Note that this base Attribute used to be called PhpAttribute in the original RFC, but was changed with another RFC afterwards. If you want to take a deep dive in how attributes work, and how you can build your own; you can read about attributes in depth on this blog.

Match expression

You could call it the big brother of the switch expression: match can return values, doesn’t require break statements, can combine conditions, uses strict type comparisons and doesn’t do any type coercion.

It looks like this:

$result = match($input) {
    0 => "hello",
    '1', '2', '3' => "world",
};

Constructor property promotion

This RFC adds syntactic sugar to create value objects or data transfer objects. Instead of specifying class properties and a constructor for them, PHP can now combine them into one.

Instead of doing this:

class Money 
{
    public Currency $currency;
 
    public int $amount;
 
    public function __construct(
        Currency $currency,
        int $amount,
    ) {
        $this->currency = $currency;
        $this->amount = $amount;
    }
}

You can now do this:

class Money 
{
    public function __construct(
        public Currency $currency,
        public int $amount,
    ) {}
}

New static return type

While it was already possible to return self, static wasn’t a valid return type until PHP 8. Given PHP’s dynamically typed nature, it’s a feature that will be useful to many developers.

class Foo
{
    public function test(): static
    {
        return new static();
    }
}

New mixed type

Some might call it a necessary evil: the mixed type causes many to have mixed feelings. There’s a very good argument to make for it though: a missing type can mean lots of things in PHP:

• A function returns nothing or null
• We’re expecting one of several types
• We’re expecting a type that can’t be type hinted in PHP

Because of the reasons above, it’s a good thing the mixed type is added. mixed itself means one of these types:

• array
• bool
• callable
• int
• float
• null
• object
• resource
• string

Note that mixed can also be used as a parameter or property type, not just as a return type.

Also note that since mixed already includes null, it’s not allowed to make it nullable. The following will trigger an error:

// Fatal error: Mixed types cannot be nullable, null is already part of the mixed type.
function bar(): ?mixed {}

Throw expression

This RFC changes throw from being a statement to being an expression, which makes it possible to throw exception in many new places:

$triggerError = fn () => throw new MyError();

$foo = $bar['offset'] ?? throw new OffsetDoesNotExist('offset');

Inheritance with private methods

Previously, PHP used to apply the same inheritance checks on public, protected and private methods. In other words: private methods should follow the same method signature rules as protected and public methods. This doesn’t make sense, since private methods won’t be accessible by child classes.

This RFC changed that behaviour, so that these inheritance checks are not performed on private methods anymore. Furthermore, the use of final private function also didn’t make sense, so doing so will now trigger a warning:

Warning: Private methods cannot be final as they are never overridden by other classes

Allowing ::class on objects

A small, yet useful, new feature: it’s now possible to use ::class on objects, instead of having to use get_class() on them. It works the same way as get_class().

$foo = new Foo();

var_dump($foo::class);

Non-capturing catches

Whenever you wanted to catch an exception before PHP 8, you had to store it in a variable, regardless whether you used that variable or not. With non-capturing catches, you can omit the variable, so instead of this:

try {
    // Something goes wrong
} catch (MySpecialException $exception) {
    Log::error("Something went wrong");
}

You can now do this:

try {
    // Something goes wrong
} catch (MySpecialException) {
    Log::error("Something went wrong");
}

Note that it’s required to always specify the type, you’re not allowed to have an empty catch. If you want to catch all exceptions and errors, you can use Throwable as the catching type.

Trailing comma in parameter lists

Already possible when calling a function, trailing comma support was still lacking in parameter lists. It’s now allowed in PHP 8, meaning you can do the following:

public function(
    string $parameterA,
    int $parameterB,
    Foo $objectfoo,
) {
    // …
}

Create DateTime objects from interface

You can already create a DateTime object from a DateTimeImmutable object using DateTime::createFromImmutable($immutableDateTime), but the other way around was tricky. By adding DateTime::createFromInterface() and DatetimeImmutable::createFromInterface() there’s now a generalised way to convert DateTime and DateTimeImmutable objects to each other.

DateTime::createFromInterface(DateTimeInterface $other);

DateTimeImmutable::createFromInterface(DateTimeInterface $other);

New Stringable interface

The Stringable interface can be used to type hint anything that implements __toString(). Whenever a class implements __toString(), it automatically implements the interface behind the scenes and there’s no need to manually implement it.

class Foo
{
    public function __toString(): string
    {
        return 'foo';
    }
}

function bar(string|Stringable $stringable) { /* … */ }

bar(new Foo());
bar('abc');

New str_contains() function

Some might say it’s long overdue, but we finally don’t have to rely on strpos() anymore to know whether a string contains another string.

Instead of doing this:

if (strpos('string with lots of words', 'words') !== false) { /* … */ }

You can now do this

if (str_contains('string with lots of words', 'words')) { /* … */ }

New str_starts_with() and str_ends_with() functions

Two other ones long overdue, these two functions are now added in the core.

str_starts_with('haystack', 'hay'); // true
str_ends_with('haystack', 'stack'); // true

New fdiv() function

The new fdiv() function does something similar as the fmod() and intdiv() functions, which allows for division by 0. Instead of errors you’ll get INF, -INF or NAN, depending on the case.

New get_debug_type() function

get_debug_type() returns the type of a variable. Sounds like something gettype() would do? get_debug_type() returns more useful output for arrays, strings, anonymous classes and objects.

For example, calling gettype() on a class \Foo\Bar would return object. Using get_debug_type() will return the class name.

A full list of differences between get_debug_type() and gettype() can be found in the RFC.

New get_resource_id() function

Resources are special variables in PHP, referring to external resources. One example is a MySQL connection, another one a file handle.

Each one of those resources gets assigned an ID, though previously the only way to know that id was to cast the resource to int:

$resourceId = (int) $resource;

PHP 8 adds the get_resource_id() functions, making this operation more obvious and type-safe:

$resourceId = get_resource_id($resource);

Abstract methods in traits improvements

Traits can specify abstract methods which must be implemented by the classes using them. There’s a caveat though: before PHP 8 the signature of these method implementations weren’t validated. The following was valid:

trait Test {
    abstract public function test(int $input): int;
}

class UsesTrait
{
    use Test;

    public function test($input)
    {
        return $input;
    }
}

PHP 8 will perform proper method signature validation when using a trait and implementing its abstract methods. This means you’ll need to write this instead:

class UsesTrait
{
    use Test;

    public function test(int $input): int
    {
        return $input;
    }
}

Object implementation of token_get_all()

The token_get_all() function returns an array of values. This RFC adds a PhpToken class with a PhpToken::tokenize() method. This implementation works with objects instead of plain values. It consumes less memory and is easier to read.

Variable syntax tweaks

From the RFC: “the Uniform Variable Syntax RFC resolved a number of inconsistencies in PHP’s variable syntax. This RFC intends to address a small handful of cases that were overlooked.”

Type annotations for internal functions externals

Lots of people pitched in to add proper type annotations to all internal functions. This was a long standing issue, and finally solvable with all the changes made to PHP in previous versions. This means that internal functions and methods will have complete type information in reflection.

ext-json always available

Previously it was possible to compile PHP without the JSON extension enabled, this is not possible anymore. Since JSON is so widely used, it’s best developers can always rely on it being there, instead of having to ensure the extension exist first.

For more information and to develop web application using PHP, WordPress OR Laravel, Hire PHP Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop custom web apps using PHP, Laravel or WordPress, please visit our technology page.

Content Source:

1. stitcher.io