Benefit of keeping the parameter optional:
- In maintenance scripts that really only have one parameter, it's a
little more convenient to be able to ask for *the* parameter via an
empty getArg().
Disadvantages:
- It's unclear what getArg() means when there is no indication *which*
argument the code asks for. This might as well return the last
argument, or an array of all arguments.
- In scripts with two or more arguments, it's confusing to see
getArg( 1 ) next to an empty getArg().
- The methods are more complex and a bit more complicated to use with
the extra feature of this parameter being optional. Users need to
look up what the default is to be able to use it safely.
Change-Id: I22a43bfdfc0f0c9ffdb468c13aba73b888d1f15e
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
Variables in classes should be declared using public $foo
instead of var $foo for various reasons. As we require PHP 5.3
we don't have to take care about that PHP4 left over, but can
get rid of it in favour of the more clear and better readable
public.
See also: http://php.net/manual/en/language.oop5.visibility.php
(Divided into several commits to keep reviewable)
Change-Id: Ic723d0347ab2e3c78bc0097345c68bbee3dc035a
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
@fixme is simply not recognized by doxygen whereas @todo is used to
generate a nice ... todo list!!
Change-Id: If956c0a164373126ce48b791d45c56962034eecd
This also confirms JSMin+'s fairly abysmal memory usage on large complex files. :) Pass --memory-limit to set to arbitrary values to see where it dies on your file. ;)
