rfc:conditional_break_continue_return

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:conditional_break_continue_return [2020/05/16 19:18] – ralphschindlerrfc:conditional_break_continue_return [2022/04/17 18:38] (current) – Move to inactive ilutov
Line 1: Line 1:
-====== PHP RFC: Your Title Here ====== +====== PHP RFC: Conditional Return, Break, and Continue Statements ====== 
-  * Version: 0.9 +  * Version: 1.0 
-  * Date: 2013-02-24 (use today's date here)+  * Date: 2020-05-16
   * Author: Ralph Schindler, ralphschindler@php.net   * Author: Ralph Schindler, ralphschindler@php.net
-  * Status: Draft+  * Status: Inactive
   * First Published at: http://wiki.php.net/rfc/conditional_break_continue_return   * First Published at: http://wiki.php.net/rfc/conditional_break_continue_return
 ===== Introduction ===== ===== Introduction =====
 +
 +Most generally, this is a syntactical change that (IMO, of course) allows for a terser and more expressive way to achieve conditional returns (along with breaks and continues).
  
 This proposal is a syntatical addition that allows `break`, `continue` and `return` to be conditionally qualified. Two variations are possible (depending on which, if either are desirable to have.) This proposal is a syntatical addition that allows `break`, `continue` and `return` to be conditionally qualified. Two variations are possible (depending on which, if either are desirable to have.)
Line 45: Line 47:
 In short [I perceive], a benefit of using guard clauses is to avoid deeply nested conditionals and to avoid increasing cognitive complexity in a function or method. Utilizing this technique in code results in code that is more easily code reviewable and easier to determine possible code paths that exists from the top to the bottom of a function or method. In short [I perceive], a benefit of using guard clauses is to avoid deeply nested conditionals and to avoid increasing cognitive complexity in a function or method. Utilizing this technique in code results in code that is more easily code reviewable and easier to determine possible code paths that exists from the top to the bottom of a function or method.
  
-Over the past few years, I've seen a growing number of blog posts, conference talks, and even tooling (for example code complexity scoring), that suggest writing guard clauses is a good practice to utilize.  I've also seen it more prevalent in code, and even attempts at achieving this with Exceptions (in an HTTP context) in a framework like Laravel.+Over the past few years, I've seen a growing number of blog posts, conference talks, and even tooling (for example code complexity scoring), that suggest writing guard clauses is a good practice to utilize.  I've also seen it more prevalent in code, and even attempts at achieving this with Exceptions (in an HTTP context) in a framework like Laravel. See abort_if/throw_if [[https://laravel.com/docs/7.x/helpers#method-abort-if|in Laravel]].
  
-  see abort_if/throw_if: https://laravel.com/docs/7.x/helpers#method-abort-if+It is also worth mentioning that Ruby has similar features (called a modifier), and I believe they are heavily utilized.. [[https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals|see here]].
  
-It is also worth mentioning that Ruby has similar features (called a modifier), and I believe they are heavily utilized: +(While the text of this applies most arguments to `return`, at current the same arguments apply for break and continue, and are included in this proposal.)
- +
-  see: https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals+
  
 ==== Variation #1 ==== ==== Variation #1 ====
Line 84: Line 84:
 Con: Con:
   - Large optional return values will create more space between the `return` and `if` keywords, potentially making it harder for (humans) to scan for the conditional qualifier.   - Large optional return values will create more space between the `return` and `if` keywords, potentially making it harder for (humans) to scan for the conditional qualifier.
 +
 +==== A visual argument between the two variations ====
 +
 +(Click to view full)
 +
 +{{:rfc:return-if-visual-reasoning.png}}
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
  
-No BC issues.+No BC issues: there are no new keywords, nor does not impact any existing code. 
 + 
 +This syntactical change is reusing existing keywords.
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
Line 113: Line 121:
  
 The recently contributed [[rfc:guard_statement|Guard RFC]] The recently contributed [[rfc:guard_statement|Guard RFC]]
 +
 +https://stackoverflow.com/questions/5436034/is-there-a-ruby-one-line-return-if-x
 +
 +https://engineering.helpscout.com/reducing-complexity-with-guard-clauses-in-php-and-javascript-74600fd865c7
 +
 +https://guidelines.spatie.be/code-style/laravel-php#avoid-else
 +
  
rfc/conditional_break_continue_return.1589656713.txt.gz · Last modified: 2020/05/16 19:18 by ralphschindler

Page Tools