Manuál:Konvence pro psaní kódu/PHP

From MediaWiki.org
Jump to navigation Jump to search
This page is a translated version of the page Manual:Coding conventions/PHP and the translation is 39% complete.
Other languages:
English • ‎dansk • ‎español • ‎français • ‎čeština • ‎русский • ‎中文 • ‎日本語
shortcut: CC/PHP

Tato stránka popisuje konvenci která se používá při psaní u PHP skriptů u MediaWiki . Nezapomeňte se podívat také na stránku obecná konvence která je platná pro všechny programovací jazyky s nimiž se tu můžete setkat, včetně PHP. Pokud vás zajímá pouze stručné resumé, co by vám pomohlo překontrolovat váš commit, zkuste použít Pre-commit checklist .

Aby mohli vývojáři snadno odhalit kód, který není v souladu s touto konvencí, existuje nástroj stylize, který kontroluje syntaxi a doplní mezery na příslušná místa; tento nástroj je dostupný přes webové rozhraní. Je doporučeno ho použít ke kontrole souborů dřív, než je uložen commit, který se bude odesílat do Gitu.

Pravidla pro PHP_CodeSniffer jsou také k dispozici. Na stránce Continuous integration/PHP CodeSniffer se dozvíte více. Git repozitář https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/tools/codesniffer obsahuje konfigurační nastavení pro PHP CodeSniffer, optimalizované pro kód MediaWiki.

Struktura kódu

Mezery

Pro MediaWiki je prvořadým úkolem srozumitelnost a přehlednost kódu, proto se při psaní hojně využívají mezery.

U binárních operátorů, přidejte z každé strany jednu mezeru, tak aby byly naprosto jasně odděleny. Viz příklad:

// No:
$a=$b+$c;

// Yes:
$a = $b + $c;

Také obsah závorek oddělujte mezerami. Výjimkou je pouze situace, kdy závorky nemají žádný obsah. Naopak mezi jméno funkce a otevírací závorku pro její obsah mezeru nedávejte.

$a = getFoo( $b );
$c = getBar();

Mezeru do závorek vložte jen pokud chcete deklarovat pole, které nemá být prázdné. Mezery také nepoužívejte při adresování jednotlivých prvků pole.

// Yes
$a = [ 'foo', 'bar' ];
$c = $a[0];
$x = [];

// No
$a = ['foo', 'bar'];
$c = $a[ 0 ];
$x = [ ];

Za řídící prvky, jako je if, while, for, foreach, switch, nebo klíčové slovo catch, naopak mezeru vložte vždy:

// Yes
if ( isFoo() ) {
	$a = 'foo';
}

// No
if( isFoo() ) {
	$a = 'foo';
}

U deklarování typu proměnné mezery nepoužívejte nikdy. Ani v závorkách, ani za nimi:

// Yes
(int)$foo;

// No
(int) $bar;
( int )$bar;
( int ) $bar;

U komentářů přidejte mezeru za #, resp. //, a teprve pak napište svůj komentář.

// Yes: Proper inline comment
//No: Missing space
/***** Do not comment like this ***/

Jako vývojářskou pomůcku, která se postará o správné umístění mezer, lze použít nástroj stylize, který přidává mezery automaticky podle konvence PHP. Nástroj je dostupný přes webové rozhraní.

Ternární operátor

The ternary operator can be used profitably if the expressions are very short and obvious:

$title = $page ? $page->getTitle() : Title::newMainPage();

But if you're considering a multi-line expression with a ternary operator, please consider using an if () block instead. Remember, disk space is cheap, code readability is everything, "if" is English and ?: is not. If you are using a multi-line ternary expression, the question mark and colon should go at the beginning of the second and third lines and not the end of the first and second (in contrast to MediaWiki's JavaScript convention).

Since MediaWiki requires PHP 7.0.13 or later, use of the shorthand ternary operator (?:) also known as the elvis operator, introduced in PHP 5.3, is allowed.

Since PHP 7.0 the null coalescing operator is also available and can replace the ternary operator in some use cases. For example, instead of

$wiki = isset( $this->mParams['wiki'] ) ? $this->mParams['wiki'] : false;

you could instead write the following:

$wiki = $this->mParams['wiki'] ?? false;

Literální řetězce

Single quotes are preferred in all cases where they are equivalent to double quotes. Code using single quotes is less error-prone and easier to review, as it cannot accidentally contain escape sequences or variables. For example, the regular expression "/\\n+/" requires an extra backslash, making it slightly more confusing and error-prone than '/\n+/'. Also for people using US/UK qwerty keyboards, they are easier to type, since it avoids the need to press shift.

However, do not be afraid of using PHP's double-quoted string interpolation feature: $elementId = "myextension-$index"; This has slightly better performance characteristics than the equivalent using the concatenation (dot) operator, and it looks nicer too.

Heredoc-style strings are sometimes useful:

$s = <<<EOT
<div class="mw-some-class">
$boxContents
</div>
EOT;

Some authors like to use END as the ending token, which is also the name of a PHP function. This leads to IRC conversations like the following:

<Simetrical>	vim also has ridiculously good syntax highlighting.
<TimStarling>	it breaks when you write <<<END in PHP
<Simetrical>	TimStarling, but if you write <<<HTML it syntax-highlights as HTML!
<TimStarling>	I have to keep changing it to ENDS so it looks like a string again
<brion-codereview>	fix the bug in vim then!
<TimStarling>	brion-codereview: have you ever edited a vim syntax script file?
<brion-codereview>	hehehe
<TimStarling>	http://tstarling.com/stuff/php.vim
<TimStarling>	that's half of it...
<TimStarling>	here's the other half: http://tstarling.com/stuff/php-syntax.vim
<TimStarling>	1300 lines of sparsely-commented code in a vim-specific language
<TimStarling>	which turns out to depend for its operation on all kinds of subtle inter-pass effects
<werdnum>	TimStarling: it looks like some franken-basic language.

Funkce a jejich parametry

Avoid passing huge numbers of parameters to functions or constructors:

// Constructor for Block.php from 1.17 to 1.26. *DON'T* do this!
function __construct( $address = '', $user = 0, $by = 0, $reason = '',
	$timestamp = 0, $auto = 0, $expiry = '', $anonOnly = 0, $createAccount = 0, $enableAutoblock = 0,
	$hideName = 0, $blockEmail = 0, $allowUsertalk = 0
) {
	...
}

It quickly becomes impossible to remember the order of parameters, and you will inevitably end up having to hardcode all the defaults in callers just to customise a parameter at the end of the list. If you are tempted to code a function like this, consider passing an associative array of named parameters instead.

In general, using boolean parameters is discouraged in functions. In $object->getSomething( $input, true, true, false ), without looking up the documentation for MyClass::getSomething(), it is impossible to know what those parameters are meant to indicate. Much better is to either use class constants, and make a generic flag parameter:

$myResult = MyClass::getSomething( $input, MyClass::FROM_DB | MyClass::PUBLIC_ONLY );

Or to make your function accept an array of named parameters:

$myResult = MyClass::getSomething( $input, [ 'fromDB', 'publicOnly' ] );

Try not to repurpose variables over the course of a function, and avoid modifying the parameters passed to a function (unless they're passed by reference and that's the whole point of the function, obviously).

Assignment expressions

Using assignment as an expression is surprising to the reader and looks like an error. Do not write code like this:

if ( $a = foo() ) {
    bar();
}

Space is cheap, and you're a fast typist, so instead use:

$a = foo();
if ( $a ) {
    bar();
}

Using assignment in a while() clause used to be legitimate, for iteration:

$res = $dbr->query( 'SELECT * FROM some_table' );
while ( $row = $dbr->fetchObject( $res ) ) {
    showRow( $row );
}

This is unnecessary in new code; instead use:

$res = $dbr->query( 'SELECT * FROM some_table' );
foreach ( $res as $row ) {
    showRow( $row );
}

Výpůjčky z jazyka C

PHP je programovací jazyk, který byl navržen lidmi, co milovali programování v C a proto chtěli do PHP implementovat také syntaxim na jakou byli zvyklí. Ovšem PHP se v několika významných detailech od jazyka C liší.

U jazyka C se konstanty implementují jako makra pro preprocesor a tím pádem se zpracovávají velmi rychle. U PHP, se ale vyhledává jméno konstanty v indexované tabulce což je mnohem pomalejší než když se použije řetězcový literál. Ve většině případů, tam, kde byste použili v jazyce C množinu maker, je u PHP výhodnější použít řetězcové literály.

PHP has three special literals for which upper-/lower-/mixed-case is insignificant in the language (since PHP 5.1.3), but for which our convention is always lowercase: true, false and null.

Use elseif not else if. They have subtly different meanings:

// Tento kód:
if ( $foo == 'bar' ) {
	echo 'Hello world';
} else if ( $foo == 'Bar' ) {
	echo 'Hello world';
} else if ( $baz == $foo ) {
	echo 'Hello baz';
} else {
	echo 'Eh?';
}

// Bude mít v zásadě stejný efekt, jako tento kód:
if ( $foo == 'bar' ) {
	echo 'Hello world';
} else {
	if ( $foo == 'Bar' ) {
		echo 'Hello world';
	} else {
		if ( $baz == $foo ) {
			echo 'Hello baz';
		} else {
			echo 'Eh?';
		}
	}
}

Ovšem z hlediska výkonu na tom bude druhá varianta hůř.

Alternativní syntaxe pro řídící struktury

PHP umožňuje pro řídicí struktury, jako endif, endwhile, atp., používat alternativní syntaxi, při které se místo složených závorek použije dvojtečka:

if ( $foo == $bar ):
    echo "<div>Hello world</div>";
endif;

Takové syntaxi byste se však měli vyhnout širokým obloukem, protože řada textových editorů by se zobrazením takového kódu mohla mít problém. Takže použijte raději složené závorky:

if ( $foo == $bar ) {
    echo "<div>Hello world</div>";
}

Závorky

Více o závorkách viz část věnovanou odsazování a zarovnání kódu na stránce věnované všeobecné konvenci pro psaní zdrojového kódu.

Deklarování typů v parametrech funkce

Používejte vstupní deklaraci typu (podívejte se na naznačení typu – type hinting) a deklarujte i typ návratové hodnoty, všude kde to jen lze.

Upozorňuji, že u starších verzí PHP (před 7.4), nelze obsloužit naznačování typu (ať již restriktivní, či volné) v rámci podtřídy.

Scalar typehints are allowed as of MediaWiki 1.35, following the switch to PHP 7.2 (T231710).

Use PHP 7.1 syntax for nullable parameters: choose

public function foo ( ?MyClass $mc ) {}

instead of

public function foo ( MyClass $mc = null ) {}

The former conveys precisely the nullability of a parameter, without risking any ambiguity with optional parameters. IDEs and static analysis tools will also recognize it as such, and will not complain if a non-nullable parameter follows a nullable one.

Konvence pro jména

Pro názvy funkcí a proměnných používejte lower-CamelCase notaci. Jak demonstruje ukázkový příklad:

private function doSomething( $userPrefs, $editSummary )

Pro názvy tříd používejte naopak Upper-CamelCase: class ImportantClass. Use uppercase with underscores for global and class constants: DB_MASTER, Revision::REV_DELETED_TEXT. Other variables are usually lowercase or lowerCamelCase; avoid using underscores in variable names.

Používejte také zavedené prefixy. I ty v kódu napovídají oč jde:

Funkce

  • wf (wiki funkce) – funkce, dostupné na té nejvyšší úrovni, např.
    function wfFuncname() { ... }
    
  • ef (funkce rozšíření) = jsou globální funkce, napsané v rámci rozšíření. I když většina skriptů napsaných v moderním stylu vkládá do svých tříd funkce, které se registrují jako háčky, jako statické metody třídy, aby na té nejvyšší úrovni do budoucna zbylo jen minimum, takto pojmenovaného kódu. (-- brion in Manual_talk:Coding_conventions#ef_prefix_9510)

V tomto případě se preferují slovesa, která jasně naznačí co má funkce udělat: takže místo returnText() použijte getReturnText().

Proměnné

  • $wg – global variables, e.g. $wgVersion, $wgTitle. Always use this for new globals, so that it's easy to spot missing "global $wgFoo" declarations. In extensions, the extension name should be used as a namespace delimiter. For example, $wgAbuseFilterConditionLimit, not $wgConditionLimit.
  • Global declarations should be at the beginning of a function so dependencies can be determined without having to read the whole function.

It is common to work with an instance of the Database class; we have a naming convention for these which helps keep track of the nature of the server to which we are connected. This is of particular importance in replicated environments, such as Wikimedia and other large wikis; in development environments, there is usually no difference between the two types, which can conceal subtle errors.

  • $dbw – a Database object for writing (a master connection)
  • $dbr – a Database object for non-concurrency-sensitive reading (this may be a read-only replica, slightly behind master state, so don't ever try to write to the database with it, or get an "authoritative" answer to important queries like permissions and block status)

The following may be seen in old code but are discouraged in new code:

  • $ws – Session variables, e.g. $_SESSION['wsSessionName']
  • $wc – Cookie variables, e.g. $_COOKIE['wcCookieName']
  • $wp – Post variables (submitted via form fields), e.g. $wgRequest->getText( 'wpLoginName' )
  • $m – object member variables: $this->mPage. This is discouraged in new code, but try to stay consistent within a class.

Pitfalls

empty()

The empty() function should only be used when you want to suppress errors. Otherwise just use ! (boolean conversion).

  • empty( $var ) essentially does !isset( $var ) || !$var.
    Common use case: Optional boolean configuration keys that default to false. $this->enableFoo = !empty( $options['foo'] );
  • Beware of boolean conversion pitfalls.
  • It suppresses errors about undefined properties and variables. If only intending to test for undefined, use !isset(). If only intending to test for "empty" values (e.g. false, zero, empty array, etc.), use !.

isset()

Do not use isset to test for null. Using isset in this situation could introduce errors by hiding misspelled variable names. Instead, use $var === null.

Boolean conversion

if ( !$var ) {
    
}
  • Do not use ! or empty to test if a string or array is empty, because PHP considers '0' to be falsy – but '0' is a valid title and valid user name in MediaWiki. Use === '' or === [] instead.
  • Study the rules for conversion to boolean. Be careful when converting strings to boolean.

Ostatní

  • Array plus does not renumber the keys of numerically-indexed arrays, so [ 'a' ] + [ 'b' ] === [ 'a' ]. If you want keys to be renumbered, use array_merge(): array_merge( [ 'a' ], [ 'b' ] ) == [ 'a', 'b' ]
  • Make sure you have error_reporting() set to -1. This will notify you of undefined variables and other subtle gotchas that stock PHP will ignore. See also Manuál:Odstraňování chyb .
  • When working in a pure PHP file (e.g. not an HTML template), omit any trailing ?> tags. These tags often cause issues with trailing white-space and "headers already sent" error messages (cf. bugzilla:17642 and http://news.php.net/php.general/280796). It is conventional in version control for files to have a new line at end-of-file (which editors may add automatically), which would then trigger this error.
  • Do not use the goto() syntax introduced in 5.3. PHP may have introduced the feature, but that does not mean we should use it.
  • Do not pass by reference when traversing an array unless you have to. Even then, be aware of the consequences. (See http://www.king-foo.be/2010/10/php-quirks-passing-an-array-by-reference/)
  • PHP lets you declare static variables even within a non-static method of a class. This has led to subtle bugs in some cases, as the variables are shared between instances. Where you would not use a private static property, do not use a static variable either.

Equality operators

Be careful with double-equals comparison operators. Triple-equals (===) is generally more intuitive and should be preferred unless you have a reason to use double-equals (==).

  • 'foo' == 0 is true (!)
  • '000' == '0' is true (!)
  • '000' === '0' is false
  • To check if two scalars that are supposed to be numeric are equal, use ==, e.g. 5 == "5" is true.
  • To check if two variables are both of type 'string' and are the same sequence of characters, use ===, e.g. "1.e6" === "1.0e6" is false.

JSON number precision

JSON uses JavaScript's type system, so all numbers are represented as 64bit IEEE floating point numbers. This means that numbers lose precision when getting bigger, to the point where some whole numbers become indistinguishable: Numbers beyond 2^52 will have a precision worse than ±0.5, so a large integer may end up changing to a different integer. To avoid this issue, represent potentially large integers as strings in JSON.

Dos and Don'ts

Don't use built in serialization

PHP's built in serialization mechanism (the serialize() and unserialize() functions) should not be used for data stored (or read from) outside of the current process. Use JSON based serialization instead (however, beware the pitfalls). This is policy established by RFC T161647.

The reason is twofold: (1) data serialized with this mechanism cannot reliably be unserialized with a later version of the same class. And (2) crafted serialized data can be used to execute malicious code, posing a serious security risk.

Sometimes, your code will not control the serialization mechanism, but will be using some library or driver that uses it internally. In such cases, steps should be taken to mitigate risk. The first issue mentioned above can be mitigated by converting any data to arrays or plain anonymous objects before serialization. The second issue can perhaps be mitigated using the whitelisting feature PHP 7 introduces for unserialization.

Komentáře a dokumentace

Je nezbytné, aby váš kód byl dobře zdokumentován, aby ostatní vývojáři a opraváři chyb mohli snadno pochopit logiku vašeho kódu. New classes, methods, and member variables should include comments providing brief descriptions of their functionality (unless it is obvious), even if private. In addition, all new methods should document their parameters and return values.

Při dokumentaci využíváme značky a styl, podobný jako když se používá Doxygen (ostatně PHPDoc z něj vychází, takže se jejich styl navzájem moc neliší). Díky tomu lze dokumentaci automaticky generovat rovnou z komentářů v kódu (viz Manual:mwdocgen.php). Begin a block of Doxygen comments with /**, instead of the Qt-style formatting /*!. Doxygen structural commands start with @tagname. (Use @ rather than \ as the escape character – both styles work in Doxygen, but for backwards and future compatibility MediaWiki has chosen the @param style.) They organize the generated documentation (using @ingroup) and identify authors (using @author tags).

Používají se při popisu parametrů, které se předávají funkci (metodě) (@param), a i toho co funkce vrací (@return). Při popisu parametrů to vypadá takto:

@param type $paramName Description of parameter

Pokud parametr akceptuje různé typy, použijte k jejich oddělení znak roury, neboli svislítka '|' (pipe), podobně jako u následujícího příkladu:

@param string|Language|bool $lang Language for the toc title, defaults to user language

V popisu pokračujte na dalším řádku, odsazeném o jednu mezeru navíc.

For every public interface (method, class, variable, whatever) you add or change, provide a @since VERSION tag, so people extending the code via this interface know they are breaking compatibility with older versions of the code.

class Foo {

	/**
	 * @var array $bar: Description here
	 * @example [ 'foo' => Bar, 'quux' => Bar, .. ]
	 */
	protected $bar;

	/**
	 * Description here, following by documentation of the parameters.
	 *
	 * Some example:
	 * @code
	 * ...
	 * @endcode
	 *
	 * @since 1.24
	 * @param FooContext $context context for decoding Foos
	 * @param array|string $options Optionally pass extra options. Either a string
	 *  or an array of strings.
	 * @return Foo|null New instance of Foo or null of quuxification failed.
	 */
	public function makeQuuxificatedFoo( FooContext $context = null, $options = [] ) {
		/* .. */
	}

}

FIXME usually means something is bad or broken. TODO means that improvements are needed; it does not necessarily mean that the person adding the comment is going to do it. HACK means that a quick but inelegant, awkward or otherwise suboptimal solution to an immediate problem was made, and that eventually a more thorough rewrite of the code should be done.

Záhlaví zdrojáků

In order to be compliant with most licenses you should have something similar to the following (specific to GPLv2 applications) at the top of every source file.

<?php
/**
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write to the Free Software Foundation, Inc.,
 * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 * http://www.gnu.org/copyleft/gpl.html
 *
 * @file
 */

Značky pro Doxygen

V našich zdrojácích používáme při vkládání poznámek následující značky, s nimiž pracuje Doxygen. Aby byla zajištěna konzistence vašeho souboru, zachovejte prosím při jejich použití i vy stejné pořadí, v jakém jsou uvedeny zde:

Poznámky k souboru:

  • @file
  • @ingroup
  • @author

Třídy a jejich vlastnosti:

  • @todo
  • @var
  • @deprecated
  • @class
  • @see
  • @since
  • @param
  • @return
  • @throws
  • @private

Poznámky k testům

U testů používáme, mimo jiné, i následující poznámky. V tomto případě se nejedná o dokumentaci, protože mají význam pouze pro PHPUnit a svůj význam mají pouze při testování.

  • @depends
  • @group
  • @covers
  • @dataProvider
  • @expectedException
  • @expectedExceptionMessage

Integrace kódu

V kódu MediaWiki najdete i kódy, které jsou na ní zcela nezávislé a tím pádem je lze snadno implementovat do jiných aplikací. While some of these now exist as separate libraries, others remain within the MediaWiki source tree (e.g. the files in /includes/libs). Apart from these, code should be integrated into the rest of the MediaWiki environment, and should allow other areas of the codebase to integrate with it in return.

Viditelnost

Svoje metody (funkce) si nastavte jako public/protected/private (podle toho jak uznáte za vhodné). Ale není důvod k tomu, aby byly veřejné (public) všechny!

Globální objekty

Nepřistupujte k superglobálním proměnným PHP jako $_GET, $_POST, atp. přímo. Použijte získávejte jejich hodnotu raději přes volání metody >$request->get*( 'param' ). Většinou jsou k dispozici různé metody, které vám umožní získat požadovanou hodnotu ve formě typu, jaký zrovna potřebujete. Takže hodnotu pro aktuální WebRequest můžete zjistit z nejbližšího objektu RequestContext, takže není vůbec nutné kvůli tomu volat RequestContext::getMain(). Stejně tak kvůli tomu nemusíte sahat přímo do $_SERVER. Pokud chcete získat IP adresu aktuálního uživatele, stačí použít $request->getIP().

Statické metody a jejich vlastnosti

Ve svém PHP statické metody a vlastnosti klidně používejte, jenom mějte neustále na paměti, jaký je rozdíl mezi self a static. self bude vždy odkazovat na funkce a proměnné v rámci třídy, zatímco static bude odkazovat na konkrétní podtřídu, která ji zavolá. Pro víc podrobnosti si přečtěte v dokumentaci k PHP o dědičnosti a pozdních statických vazbách.

Třídy

Zapouzdřete svůj kód do objektově orientované třídy, nebo ho přidejte jako novou funkci do třídy již existující; nepřidávejte nové globální funkce či proměnné, pokud to není nezbytné. Snažte se mít neustále na paměti rozdíl mezi třídami, které patří k backendu, jakou jsou například entity které pracují s databází, jako User, Block, Revision, aj. A třídami co obsluhují frontend, jako SpecialPage, Article, ChangesList a jiné, co zastupují stránky a rozhraní co se vrací uživateli. A i pokud není váš kód zrovna objektově orientovaný, je lepší ho umístit alespoň do statické třídy, jako jsou např. třídy IP nebo Html.

As a holdover from PHP 4's lack of private class members and methods, older code will be marked with comments such as /** @private */ to indicate the intention; respect this as if it were enforced by the interpreter.

Mark new code with proper visibility modifiers, including public if appropriate, but do not add visibility to existing code without first checking, testing and refactoring as required. It's generally a good idea to avoid visibility changes unless you're making changes to the function which would break old uses of it anyway.

Jak ošetřit chyby

Don't suppress errors with PHP's @ operator, for any reason ever. It's broken when E_STRICT is enabled and it causes an unlogged, unexplained error if there is a fatal, which is hard to support.

The proper method of handling errors is to actually handle the errors. For example, if you are thinking of using an error suppression operator to suppress an invalid array index warning, you should instead perform an isset check on the array index before trying to access it. When possible, always prevent PHP errors rather than catching and handling them afterwards. It makes the code more understandable and avoids dealing with slow error suppression methods.

If and only if there is a situation where you are expecting an unavoidable PHP warning, you may use Wikimedia\AtEase\AtEase::suppressWarnings() and Wikimedia\AtEase\AtEase::restoreWarnings() from the at-ease library instead of the @ operator. This is for cases where:

  1. It is impossible to anticipate the error that is about to occur; and
  2. You are planning on handling the error in an appropriate manner after it occurs.

An example of this is opening a file with fopen(). You can anticipate the error by calling file_exists() and is_readable(), but it is possible the file will have been deleted in between the check and the actual fopen() call. In this case, your code should be ready to handle the case that the file will fail to open, and you can use Wikimedia\AtEase\AtEase::suppressWarnings() to prevent PHP from being noisy. Note that using Wikimedia\AtEase\AtEase::suppressWarnings() and Wikimedia\AtEase\AtEase::restoreWarnings() are slow. They are much slower than using the @ operator, since it involves at least four function calls and reference counting, rather than just an opcode.

When your code encounters a sudden error, you should throw an exception rather than using PHP's trigger_error. The exception handler will display this as nicely as possible to the end user and wiki administrator, and also provides a stack trace to developers. Don't throw an instance of Exception itself, but instead a subclass of it. Exceptions that indicate programming errors should be one of the exceptions that ship with PHP or a more specific subclass, while exceptions that indicate errors that are relevant to the end user should be an ErrorPageError or one of its subclasses.

Viz též