Skip to main content
Code Review

Return to Answer

added 598 characters in body
Source Link
KIKO Software
  • 6.1k
  • 15
  • 24

DEMO: https://3v4l.org/nii9c https://3v4l.org/WioCJ

Built-in PHP classes, objects, methods, and functions are part of the PHP language. With some exceptions, which are always documented in the manual, you can use them freely everywhere. Don't view them as risky "dependencies". Of course, some features of PHP do get deprecated over time, but it's hard to predict which those will be, and you shouldn't be held hostage by this.

Finally:

You can use Type declarations in your function declarations:

function monthsBetween(DateTime $date1, DateTime $date2 = NULL)

DEMO: https://3v4l.org/68Qur

This way you'll get an error message when you supply a stringy date or another type of object.

Your functions don't need them, but have a look at DateTimeImmutable , they are preferred because the normal DateTime can often cause unexpected effects when you use them as function arguments.

DEMO: https://3v4l.org/nii9c

Built-in PHP classes, objects, methods, and functions are part of the PHP language. With some exceptions, which are always documented in the manual, you can use them freely everywhere. Don't view them as risky "dependencies". Of course, some features of PHP do get deprecated over time, but it's hard to predict which those will be, and you shouldn't be held hostage by this.

DEMO: https://3v4l.org/WioCJ

Built-in PHP classes, objects, methods, and functions are part of the PHP language. With some exceptions, which are always documented in the manual, you can use them freely everywhere. Don't view them as risky "dependencies". Of course, some features of PHP do get deprecated over time, but it's hard to predict which those will be, and you shouldn't be held hostage by this.

Finally:

You can use Type declarations in your function declarations:

function monthsBetween(DateTime $date1, DateTime $date2 = NULL)

DEMO: https://3v4l.org/68Qur

This way you'll get an error message when you supply a stringy date or another type of object.

Your functions don't need them, but have a look at DateTimeImmutable , they are preferred because the normal DateTime can often cause unexpected effects when you use them as function arguments.

deleted 9 characters in body
Source Link
KIKO Software
  • 6.1k
  • 15
  • 24

Obviously I have chosen to turn stringy dates into PHP objects before using these functions. The reason is obvious, when you look at the code. AAnother good argument for this is that you often need to make sure stringy dates are valid before you use them, and converting them to objects is one way of doing this.

Built-in PHP classes, objects, methods, and functions are part of the PHP language. With some exceptions, which are always documented in the manual, you can use them use them freely everywhere. Don't view them as risky "dependencies". Of course, some features of PHP do get deprecated over time, but it's hard to predict which those will be, and you shouldn't be held hostage by this.

Obviously I have chosen to turn stringy dates into PHP objects before using these functions. The reason is obvious, when you look at the code. A good argument for this is that you often need to make sure stringy dates are valid before you use them, and converting them to objects is one way of doing this.

Built-in PHP classes, objects, methods, and functions are part of the PHP language. With some exceptions, which are always documented in the manual, you can use them use them freely everywhere. Don't view them as risky "dependencies". Of course, some features of PHP do get deprecated over time, but it's hard to predict which those will be, and you shouldn't be held hostage by this.

Obviously I have chosen to turn stringy dates into PHP objects before using these functions. The reason is obvious, when you look at the code. Another good argument for this is that you often need to make sure stringy dates are valid before you use them, and converting them to objects is one way of doing this.

Built-in PHP classes, objects, methods, and functions are part of the PHP language. With some exceptions, which are always documented in the manual, you can use them freely everywhere. Don't view them as risky "dependencies". Of course, some features of PHP do get deprecated over time, but it's hard to predict which those will be, and you shouldn't be held hostage by this.

Source Link
KIKO Software
  • 6.1k
  • 15
  • 24

You have a bucket load of questions in your question. πŸ™‚ I'm not sure I'll be able to answer them all, but I will give it a try. First the code. Things I notice immediately are:

  • Function 1 repeats function 0 with only a slight difference.
  • Function 3 doesn't use function 2, which would have made sense.
  • Function names combine camelCase and snake_case.
  • Use of parenthesis where they are not needed.
  • The use of the variable $months inside the functions doesn't make much sense.
  • Not using default values for parameters, see code below.

Incorporating these changes gives:

<?php
// Function 0 & 1
function monthsBetween($date1, $date2 = NULL) {
 if (is_null($date2)) {
 $date2 = new DateTime("now");
 }
 $interval = $date2->diff($date1); 
 return 12 * $interval->y + $interval->m;
}
// Function 2 & 3
function hasMonthBetween($date1, $date2 = NULL) {
 return monthsBetween($date1, $date2) > 0;
}
$startDate = new DateTime('2000-01-11');
$endDate = new DateTime('2000-02-11');
// Function 0 Call
echo monthsBetween($startDate, $endDate) . PHP_EOL;
// Function 1 Call
echo monthsBetween($startDate) . PHP_EOL;
// Function 2 Call
echo hasMonthBetween($startDate, $endDate) . PHP_EOL;
// Function 3 Call
echo hasMonthBetween($startDate) . PHP_EOL;

DEMO: https://3v4l.org/nii9c

Obviously I have chosen to turn stringy dates into PHP objects before using these functions. The reason is obvious, when you look at the code. A good argument for this is that you often need to make sure stringy dates are valid before you use them, and converting them to objects is one way of doing this.

Notice how I can merge 2 function together because of the use of NULL as the default value for the second argument.

I renamed the functions slightly. I agree that "passed" and "between" are quite similar, but I felt that "between" more clearly describes that these functions look at the interval "between" the dates.

Now, given this, let me look at your questions again:

I think that hasMonthBetween($date1, $date2) and monthsBetween($date1, $date2) > 0 look very similar. As Your Common Sense already said; It's up to you. I'm always in favor of general functions and code reuse. This doesn't mean you cannot have a function like hasMonthBetween(). It depends on what your code needs to do. The function makes perfect sense when the question, whether two dates have a month between them, is important in your software.

I prefer shorter functions, because they are easier to read and understand. It's really time to refactor when a function is longer than what fits on your computer screen. Shorter functions are often also easier to test. If this means you'll have more functions then so be it.

Built-in PHP classes, objects, methods, and functions are part of the PHP language. With some exceptions, which are always documented in the manual, you can use them use them freely everywhere. Don't view them as risky "dependencies". Of course, some features of PHP do get deprecated over time, but it's hard to predict which those will be, and you shouldn't be held hostage by this.

lang-php

AltStyle γ«γ‚ˆγ£γ¦ε€‰ζ›γ•γ‚ŒγŸγƒšγƒΌγ‚Έ (->γ‚ͺγƒͺγ‚ΈγƒŠγƒ«) /