blocks|key|765632|text|只需为此编写一个函数即可。类似于：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|765633|function+get_string($array,+$index,+$default+=+null)+{
++++if+(isset($array[$index])+&&+strlen($value+=+trim($array[$index]))+>+0)+{
++++++++return+get_magic_quotes_gpc()+?+stripslashes($value)+:+$value;
++++}+else+{
++++++++return+$default;
++++}
}|code-block|syntax|javascript|765634|，您可以将其用作|765635|$username+=+get_string($_POST,+'username');|765636|对get_number()、get_boolean()、get_array()等琐碎的东西做同样的事情。|offset|length|style|CODE|765637|entityMap^0|0|0|0|0|1|C|E|D|S|B|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]|$M|Z|N|10|O|P]|$M|11|N|12|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|R|$]]

Just write a function for that. Something like:

<pre><code>function get_string($array, $index, $default = null) {
 if (isset($array[$index]) &amp;&amp; strlen($value = trim($array[$index])) &gt; 0) {
 return get_magic_quotes_gpc() ? stripslashes($value) : $value;
 } else {
 return $default;
 }
}
</code></pre>

which you can use as

<pre><code>$username = get_string($_POST, 'username');
</code></pre>

Do the same for trivial stuff like <code>get_number()</code>, <code>get_boolean()</code>, <code>get_array()</code> and so on.

blocks|key|765689|text|对于感兴趣的人，我已经将这个主题扩展为一篇小文章，它以一种更好的结构化形式提供了以下信息：The+Definitive+Guide+To+PHP's+isset+And+empty|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|765690|765691|我想你应该考虑的不仅仅是让这个应用程序"E_NOTICE兼容“，而是整个事情的重组。在你的代码中有数百个点经常尝试使用不存在的变量，这听起来像是一个结构相当糟糕的程序。尝试访问不存在的变量永远不应该发生，其他语言在编译时会对此犹豫不决。PHP允许这样做并不意味着您应该这样做。|765692|这些警告是为了帮助你，而不是为了惹恼你。如果您收到警告“您正在尝试使用不存在的东西！”，您的反应应该是“哦，我的错，让我尽快修复它。”否则你将如何区分“工作正常的变量未定义”和可能导致严重错误的错误代码？？这也是为什么你总是，总是使用错误报告turned+to+11进行开发，并且一直在你的代码上努力，直到一个NOTICE都没有发出。关闭错误报告仅适用于生产环境，以避免信息泄漏并提供更好的用户体验，即使面对错误代码也是如此。|style|BOLD|CODE|765693|765694|详述：|765695|您总是需要在代码中的某个位置使用isset或empty，减少它们出现的唯一方法是正确地初始化您的变量。根据情况，有不同的方法可以做到这一点：|765696|函数参数：|765697|function+foo+($bar,+$baz+=+null)+{+...+}|code-block|syntax|javascript|765698|不需要检查是否在函数内部设置了$bar或$baz，因为您只需设置它们，您只需担心它们的值是否为true或false+(或其他任何值)。|765699|任何地方的常规变量：|765700|$foo+=+null;
$bar+=+$baz+=+'default+value';|765701|在要使用变量的代码块的顶部初始化变量。这解决了!isset问题，确保您的变量总是有一个已知的默认值，让读者知道下面的代码将如何工作，从而也可以作为一种自我文档。|765702|数组：|765703|$defaults+=+array('foo'+=>+false,+'bar'+=>+true,+'baz'+=>+'default+value');
$values+=+array_merge($defaults,+$incoming_array);|765704|与上面一样，您使用默认值初始化数组，并用实际值覆盖它们。|765705|在其余情况下，假设是一个模板，其中您输出的值可能是由控制器设置的，也可能不是由控制器设置的，您只需检查：|765706|<table>
++++<?php+if+(!empty($foo)+&&+is_array($foo))+:+?>
++++++++<?php+foreach+($foo+as+$bar)+:+?>
++++++++++++<tr>...</tr>
++++++++<?php+endforeach;+?>
++++<?php+else+:+?>
++++++++<tr><td>No+Foo!</td></tr>
++++<?php+endif;+?>
</table>|765707|如果你发现自己经常使用array_key_exists，你应该评估一下你使用它的目的。唯一有意义的时候就是这里：|765708|$array+=+array('key'+=>+null);
isset($array['key']);+//+false
array_key_exists('key',+$array);+//+true|765709|如上所述，如果您正确地初始化了变量，则不需要检查键是否存在，因为您知道它确实存在。如果您从外部源获取数组，则值很可能不是null，而是''、0、'0'、false或类似的值，即可以使用isset或empty计算的值，具体取决于您的意图。如果您经常将数组键设置为null，并且希望它表示false以外的任何含义，例如，如果在上面的示例中，isset和array_key_exists的不同结果对您的程序逻辑造成了不同，那么您应该问问自己为什么。一个变量的存在并不重要，只有它的值才是重要的。如果键是true/false标志，则使用true或false，而不是null。唯一的例外是希望null有意义的第三方库，但由于null在PHP中很难检测，我还没有找到任何这样做的库。|765710|entityMap|0|LINK|mutability|MUTABLE|url|http://kunststube.net/isset/|1|http://en.wikipedia.org/wiki/It_goes_to_eleven^0|19|19|0|0|0|0|2P|5|4B|6|3D|C|1|0|0|0|G|5|M|5|0|0|0|F|4|K|4|1B|4|1G|5|0|0|0|N|6|0|0|0|0|0|0|B|G|0|0|1O|4|1V|2|1Y|1|20|3|24|5|2K|5|2Q|5|3M|4|3Y|5|4O|5|4U|G|6W|4|71|5|7C|4|7H|5|7Q|4|83|4|8J|4|0^^$0|@$1|2|3|4|5|6|7|1V|8|@]|9|@$A|1W|B|1X|1|1Y]]|C|$]]|$1|D|3|-4|5|6|7|1Z|8|@]|9|@]|C|$]]|$1|E|3|F|5|6|7|20|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|21|8|@$A|22|B|23|I|J]|$A|24|B|25|I|K]]|9|@$A|26|B|27|1|28]]|C|$]]|$1|L|3|-4|5|6|7|29|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|2A|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|2B|8|@$A|2C|B|2D|I|K]|$A|2E|B|2F|I|K]]|9|@]|C|$]]|$1|Q|3|R|5|6|7|2G|8|@]|9|@]|C|$]]|$1|S|3|T|5|U|7|2H|8|@]|9|@]|C|$V|W]]|$1|X|3|Y|5|6|7|2I|8|@$A|2J|B|2K|I|K]|$A|2L|B|2M|I|K]|$A|2N|B|2O|I|K]|$A|2P|B|2Q|I|K]]|9|@]|C|$]]|$1|Z|3|10|5|6|7|2R|8|@]|9|@]|C|$]]|$1|11|3|12|5|U|7|2S|8|@]|9|@]|C|$V|W]]|$1|13|3|14|5|6|7|2T|8|@$A|2U|B|2V|I|K]]|9|@]|C|$]]|$1|15|3|16|5|6|7|2W|8|@]|9|@]|C|$]]|$1|17|3|18|5|U|7|2X|8|@]|9|@]|C|$V|W]]|$1|19|3|1A|5|6|7|2Y|8|@]|9|@]|C|$]]|$1|1B|3|1C|5|6|7|2Z|8|@]|9|@]|C|$]]|$1|1D|3|1E|5|U|7|30|8|@]|9|@]|C|$V|W]]|$1|1F|3|1G|5|6|7|31|8|@$A|32|B|33|I|K]]|9|@]|C|$]]|$1|1H|3|1I|5|U|7|34|8|@]|9|@]|C|$V|W]]|$1|1J|3|1K|5|6|7|35|8|@$A|36|B|37|I|K]|$A|38|B|39|I|K]|$A|3A|B|3B|I|K]|$A|3C|B|3D|I|K]|$A|3E|B|3F|I|K]|$A|3G|B|3H|I|K]|$A|3I|B|3J|I|K]|$A|3K|B|3L|I|K]|$A|3M|B|3N|I|K]|$A|3O|B|3P|I|K]|$A|3Q|B|3R|I|K]|$A|3S|B|3T|I|K]|$A|3U|B|3V|I|K]|$A|3W|B|3X|I|K]|$A|3Y|B|3Z|I|K]|$A|40|B|41|I|K]|$A|42|B|43|I|K]|$A|44|B|45|I|K]]|9|@]|C|$]]|$1|1L|3|-4|5|6|7|46|8|@]|9|@]|C|$]]]|1M|$1N|$5|1O|1P|1Q|C|$1R|1S]]|1T|$5|1O|1P|1Q|C|$1R|1U]]]]

For those interested, I have expanded this topic into a small article, which provides the below information in a somewhat better structured form: <a href="http://kunststube.net/isset/" rel="noreferrer">The Definitive Guide To PHP's isset And empty</a>

<hr>

IMHO you should think about not just making the app "E_NOTICE compatible", but restructuring the whole thing. Having hundreds of points in your code that regularly try to use non-existent variables sounds like a rather badly structured program. Trying to access non-existent variables should never ever happen, other languages balk at this at compile time. The fact that PHP allows you to do it doesn't mean you should.

These warnings are there to help you, not to annoy you. If you get a warning "You're trying to work with something that doesn't exist!", your reaction should be "Oops, my bad, let me fix that ASAP." How else are you going to tell the difference between "variables that work just fine undefined" and honestly wrong code that may lead to serious errors? This is also the reason why you always, always, develop with error reporting <a href="http://en.wikipedia.org/wiki/It_goes_to_eleven" rel="noreferrer">turned to 11</a> and keep plugging away at your code until not a single <code>NOTICE</code> is issued. Turning error reporting off is for production environments only, to avoid information leakage and provide a better user experience even in the face of buggy code.

<hr>

To elaborate:

You will always need <code>isset</code> or <code>empty</code> somewhere in your code, the only way to reduce their occurrence is to initialize your variables properly. Depending on the situation there are different ways to do that:

Function arguments:

<pre><code>function foo ($bar, $baz = null) { ... }
</code></pre>

There's no need to check whether <code>$bar</code> or <code>$baz</code> are set inside the function because you just set them, all you need to worry about is if their value evaluates to <code>true</code> or <code>false</code> (or whatever else).

Regular variables anywhere:

<pre><code>$foo = null;
$bar = $baz = 'default value';
</code></pre>

Initialize your variables at the top of a block of code in which you're going to use them. This solves the <code>!isset</code> problem, ensures that your variables always have a known default value, gives the reader an idea of what the following code will work on and thereby also serves as a sort of self-documentation.

Arrays:

<pre><code>$defaults = array('foo' =&gt; false, 'bar' =&gt; true, 'baz' =&gt; 'default value');
$values = array_merge($defaults, $incoming_array);
</code></pre>

The same thing as above, you're initializing the array with default values and overwrite them with actual values.

In the remaining cases, let's say a template where you're outputting values that may or may not be set by a controller, you'll just have to check:

<pre><code>&lt;table&gt;
 &lt;?php if (!empty($foo) &amp;&amp; is_array($foo)) : ?&gt;
 &lt;?php foreach ($foo as $bar) : ?&gt;
 &lt;tr&gt;...&lt;/tr&gt;
 &lt;?php endforeach; ?&gt;
 &lt;?php else : ?&gt;
 &lt;tr&gt;&lt;td&gt;No Foo!&lt;/td&gt;&lt;/tr&gt;
 &lt;?php endif; ?&gt;
&lt;/table&gt;
</code></pre>

If you find yourself regularly using <code>array_key_exists</code>, you should evaluate what you're using it for. The only time it makes a difference is here:

<pre><code>$array = array('key' =&gt; null);
isset($array['key']); // false
array_key_exists('key', $array); // true
</code></pre>

As stated above though, if you're properly initializing your variables, you don't need to check if the key exists or not, because you know it does. If you're getting the array from an external source, the value will most likely not be <code>null</code> but <code>''</code>, <code>0</code>, <code>'0'</code>, <code>false</code> or something like it, i.e. a value you can evaluate with <code>isset</code> or <code>empty</code>, depending on your intent. If you regularly set an array key to <code>null</code> and want it to mean anything but <code>false</code>, i.e. if in the above example the differing results of <code>isset</code> and <code>array_key_exists</code> make a difference to your program logic, you should ask yourself why. The mere existence of a variable shouldn't be important, only its value should be of consequence. If the key is a <code>true</code>/<code>false</code> flag, then use <code>true</code> or <code>false</code>, not <code>null</code>. The only exception to this would be 3rd party libraries that want <code>null</code> to mean something, but since <code>null</code> is so hard to detect in PHP I have yet to find any library that does this.

blocks|key|1952034|text|我和你在一起。但是PHP的设计者犯过比这更严重的错误。除了为任何值读取定义一个自定义函数之外，没有任何方法可以绕过它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1952035|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'm here with you. But PHP designers has made a lot more worse mistakes than that. Short of defining a custom function for any value reading, there isn't any way around it.

blocks|key|649217|text|我不确定您对可读性的定义是什么，但正确使用empty()、isset()和try/throw/catch块对整个过程非常重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649218|如果您的E_NOTICE来自$_GET或$_POST，那么应该根据empty()检查它们，以及数据必须通过的所有其他安全检查。|649219|如果它来自外部提要或库，则应该将其包装在try/catch中。|649220|如果它来自数据库，则应该检查$db_num_rows()或它的等价物。|649221|如果它来自内部变量，它们应该被正确初始化。通常，这些类型的通知来自将一个新变量赋值给在失败时返回FALSE的函数。这些应该包装在测试中，在失败的情况下，可以为变量分配代码可以处理的可接受的默认值，或者抛出代码可以处理的异常。|649222|这些事情使代码变得更长，添加了额外的块，并添加了额外的测试，但我不同意你的观点，我认为它们肯定会增加额外的价值。|649223|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I'm not sure what your definition of readability is, but proper use of empty(), isset() and try/throw/catch blocks, is pretty important to the whole process.
If your E_NOTICE is coming from $_GET or $_POST, then they should be checked against empty() right along with all the other security checks that that data should have to pass.
If it's coming from external feeds or libraries, it should be wrapped in try/catch.
If it's coming from the database, $db_num_rows() or its equivalent should be checked.
If it's coming from internal variables, they should be properly initialized. Often, these types of notices come from assigning a new variable to the return of a function that returns FALSE on a failure. Those should be wrapped in a test that, in the event of a failure, can either assign the variable an acceptable default value that the code can handle, or throwing an exception that the code can handle.
These things make the code longer, add extra blocks, and add extra tests, but I disagree with you in that I think they most definitely add extra value.

blocks|key|1952097|text|软件并不是靠上帝的恩典神奇地运行的。如果你期望的东西丢失了，你需要正确地处理它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1952098|如果您忽略它，您可能会在您的应用程序中创建安全漏洞。在访问未定义变量的静态语言中，这是不可能的。如果它是空的，它不会简单地编译或崩溃你的应用程序。|1952099|此外，这会使您的应用程序不可维护，并且当发生意想不到的事情时，您会发疯的。严格的语言是必须的，而PHP在很多方面都是错误的。如果你没有意识到这一点，它会让你成为一个糟糕的程序员。|1952100|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Software does not magically run by the grace of god. If you are expecting something that is missing, you need to properly handle it.

If you ignore it, you are probably creating security holes in your applications. In static languages accessing a non-defined variable it is just not possible. It won't simply compile or crash your application if it's null.

Furthermore, it makes your application unmaintainable, and you are going to go mad when unexpected things happen. Language strictness is a must and PHP, by design, is wrong in so many aspects. It will make you a bad programmer if you are not aware.

blocks|key|765896|text|我认为解决这个问题的最好方法之一是访问GET和POST的值(COOKIE、SESSION等)。通过一个类创建数组。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|765897|为每个数组创建一个类，并声明__get和__set方法(overloading)。__get接受一个参数，它将是一个值的名称。此方法应使用isset()或empty()在相应的全局数组中检查该值，如果该值存在，则返回该值，否则返回null+(或其他一些默认值)。|offset|length|style|CODE|765898|之后，您可以放心地以这种方式访问数组值：$POST->username，并在需要时执行任何验证，而无需使用任何isset()或empty()。如果相应的全局数组中不存在username，则将返回null，因此不会生成任何警告或通知。|765899|entityMap|0|LINK|mutability|MUTABLE|url|http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members^0|0|E|5|K|5|15|5|1X|7|25|7|37|4|S|B|0|0|K|F|1J|7|1R|7|2C|8|2P|4|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@$D|T|E|U|F|G]|$D|V|E|W|F|G]|$D|X|E|Y|F|G]|$D|Z|E|10|F|G]|$D|11|E|12|F|G]|$D|13|E|14|F|G]]|9|@$D|15|E|16|1|17]]|A|$]]|$1|H|3|I|5|6|7|18|8|@$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]|$D|1H|E|1I|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I believe one of the best ways of coping with this problem is by accessing values of GET and POST (COOKIE, SESSION, etc.) arrays through a class.

Create a class for each of those arrays and declare <code>__get</code> and <code>__set</code> methods (<a href="http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members" rel="nofollow noreferrer">overloading</a>). <code>__get</code> accepts one argument which will be the name of a value. This method should check this value in the corresponding global array, either using <code>isset()</code> or <code>empty()</code> and return the value if it exists or <code>null</code> (or some other default value) otherwise.

After that you can confidently access array values in this manner: <code>$POST-&gt;username</code> and do any validation if needed without using any <code>isset()</code>s or <code>empty()</code>s. If <code>username</code> does not exist in the corresponding global array then <code>null</code> will be returned, so no warnings or notices will be generated.

blocks|key|1949435|text|我使用这些函数|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1949436|function+load(&$var)+{+return+isset($var)+?+$var+:+null;+}
function+POST($var)+{+return+isset($_POST[$var])+?+$_POST[$var]+:+null;+}|code-block|syntax|javascript|1949437|示例|1949438|$y+=+load($x);+//+null,+no+notice

//+this+attitude+is+both+readable+and+comfortable
if($login=POST("login")+and+$pass=POST("pass"))+{+//+really+=,+not+==
++//+executes+only+if+both+login+and+pass+were+in+POST
++//+stored+in+$login+and+$pass+variables
++$authorized+=+$login=="root"+&&+md5($pass)=="f65b2a087755c68586568531ad8288b4";
}|1949439|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I use these functions

<pre><code>function load(&amp;$var) { return isset($var) ? $var : null; }
function POST($var) { return isset($_POST[$var]) ? $_POST[$var] : null; }
</code></pre>

Examples

<pre><code>$y = load($x); // null, no notice

// this attitude is both readable and comfortable
if($login=POST("login") and $pass=POST("pass")) { // really =, not ==
 // executes only if both login and pass were in POST
 // stored in $login and $pass variables
 $authorized = $login=="root" &amp;&amp; md5($pass)=="f65b2a087755c68586568531ad8288b4";
}
</code></pre>

blocks|key|649286|text|使用@运算符怎么样？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|649287|例如：|649288|if(@$foo)+{+/*+Do+something+*/+}|code-block|syntax|javascript|649289|您可能会说这很糟糕，因为您无法控制“在”$foo内部发生的事情(例如，如果它是包含PHP错误的函数调用)，但如果您只对变量使用这种技术，则等同于：|649290|if(isset($foo)+&&+$foo)+{+/*+...+*/+}|649291|entityMap^0|2|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|Q|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|R|$]]

What about using the <code>@</code> operator?

For example:

<pre><code>if(@$foo) { /* Do something */ }
</code></pre>

You may say this is bad because you have no control of what happens "inside" $foo (if it was a function call that contains a PHP error for example), but if you only use this technique for variables, this is equivalent to:

<pre><code>if(isset($foo) &amp;&amp; $foo) { /* ... */ }
</code></pre>

blocks|key|2174504|text|创建一个函数，如果未设置，则返回false；如果指定，则返回空的false。如果有效，它将返回变量。您可以添加更多选项，如以下代码所示：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2174505|<?php
function+isset_globals($method,+$name,+$option+=+"")+{
++++if+(isset($method[$name]))+{++++//+Check+if+such+a+variable
++++++++if+($option+===+"empty"+&&+empty($method[$name]))+{+return+false;+}+//+Check+if+empty+
++++++++if+($option+===+"stringLength"+&&+strlen($method[$name]))+{+return+strlen($method[$name]);+}++++//+Check+length+of+string+--+used+when+checking+length+of+textareas
++++++++return+($method[$name]);
++++}+else+{+return+false;+}
}

if+(!isset_globals("$_post",+"input_name",+"empty"))+{
++++echo+"invalid";
}+else+{
++++/*+You+are+safe+to+access+the+variable+without+worrying+about+errors!+*/
++++echo+"you+uploaded:+"+.+$_POST["input_name"];
}
?>|code-block|syntax|javascript|2174506|entityMap^0|G|5|W|5|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|L|$]]

Make a function which returns <code>false</code> if not set, and, if specified, <code>false</code> if empty. If valid it returns the variable. You can add more options as seen in the code below:

<pre><code>&lt;?php
function isset_globals($method, $name, $option = "") {
 if (isset($method[$name])) { // Check if such a variable
 if ($option === "empty" &amp;&amp; empty($method[$name])) { return false; } // Check if empty 
 if ($option === "stringLength" &amp;&amp; strlen($method[$name])) { return strlen($method[$name]); } // Check length of string -- used when checking length of textareas
 return ($method[$name]);
 } else { return false; }
}

if (!isset_globals("$_post", "input_name", "empty")) {
 echo "invalid";
} else {
 /* You are safe to access the variable without worrying about errors! */
 echo "you uploaded: " . $_POST["input_name"];
}
?&gt;
</code></pre>

blocks|key|2174556|text|欢迎使用+(PHP+>=+7.0.1)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2174557|$field+=+$_GET['field']+??+null;|code-block|syntax|javascript|2174558|PHP说：|2174559|2174560|空合并运算符(??)被添加为语法糖，用于需要与isset()结合使用三元的常见情况。如果第一个操作数存在且不为空，则返回第一个操作数；否则返回第二个操作数。|blockquote|2174561|2174562|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Q|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|R|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|T|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|O|$]]

Welcome to <a href="https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.null-coalesce-op" rel="nofollow noreferrer">null coalescing operator</a> (PHP >= 7.0.1):

<pre><code>$field = $_GET['field'] ?? null;
</code></pre>

PHP says:

<blockquote>
 The null coalescing operator (??) has been added as syntactic sugar for the common case of needing to use a ternary in conjunction with isset(). It returns its first operand if it exists and is not NULL; otherwise it returns its second operand.
</blockquote>

I have several older applications that throw a lot of "xyz is undefined" and "undefined offset" messages when running on the E_NOTICE error level, because the existence of variables is not explicitly checked using <code>isset()</code> and consorts.

I am considering working through them to make them E_NOTICE compatible, as notices about missing variables or offsets can be lifesavers, there may be some minor performance improvements to be gained, and it's overall the cleaner way. 

However, I don't like what inflicting hundreds of <code>isset()</code> <code>empty()</code> and <code>array_key_exists()</code> s does to my code. It gets bloated, becomes less readable, without gaining anything in terms of value or meaning. 

How can I structure my code without an excess of variable checks, while also being E_NOTICE compatible?

How to avoid isset() and empty()

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有几个较旧的应用程序，当在E_NOTICE错误级别上运行时，它们会抛出许多"xyz is undefined“和"undefined offset”消息，因为不会使用isset()和consorts显式检查变量的存在。我正在考虑通过它们来使它们与E_NOTICE兼容，因为关于丢失变量或偏移量的通知可以是救命稻草，可能...

问如何避免isset()和empty()
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何避免isset()和empty()EN