Conditions | 27 |
Paths | 4225 |
Total Lines | 81 |
Code Lines | 42 |
Lines | 0 |
Ratio | 0 % |
Changes | 0 |
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
1 | <?php |
||
24 | function sign_current_request( $override = array() ) { |
||
25 | if ( isset( $override['scheme'] ) ) { |
||
26 | $scheme = $override['scheme']; |
||
27 | if ( !in_array( $scheme, array( 'http', 'https' ) ) ) { |
||
28 | return new Jetpack_Error( 'invalid_sheme', 'Invalid URL scheme' ); |
||
29 | } |
||
30 | } else { |
||
31 | if ( is_ssl() ) { |
||
32 | $scheme = 'https'; |
||
33 | } else { |
||
34 | $scheme = 'http'; |
||
35 | } |
||
36 | } |
||
37 | |||
38 | $host_port = isset( $_SERVER['HTTP_X_FORWARDED_PORT'] ) ? $_SERVER['HTTP_X_FORWARDED_PORT'] : $_SERVER['SERVER_PORT']; |
||
39 | |||
40 | if ( is_ssl() ) { |
||
41 | // 443: Standard Port |
||
42 | // 80: Assume we're behind a proxy without X-Forwarded-Port. Hardcoding "80" here means most sites |
||
43 | // with SSL termination proxies (self-served, Cloudflare, etc.) don't need to fiddle with |
||
44 | // the JETPACK_SIGNATURE__HTTPS_PORT constant. The code also implies we can't talk to a |
||
45 | // site at https://example.com:80/ (which would be a strange configuration). |
||
46 | // JETPACK_SIGNATURE__HTTPS_PORT: Set this constant in wp-config.php to the back end webserver's port |
||
47 | // if the site is behind a proxy running on port 443 without |
||
48 | // X-Forwarded-Port and the back end's port is *not* 80. It's better, |
||
49 | // though, to configure the proxy to send X-Forwarded-Port. |
||
50 | $port = in_array( $host_port, array( 443, 80, JETPACK_SIGNATURE__HTTPS_PORT ) ) ? '' : $host_port; |
||
51 | } else { |
||
52 | // 80: Standard Port |
||
53 | // JETPACK_SIGNATURE__HTTPS_PORT: Set this constant in wp-config.php to the back end webserver's port |
||
54 | // if the site is behind a proxy running on port 80 without |
||
55 | // X-Forwarded-Port. It's better, though, to configure the proxy to |
||
56 | // send X-Forwarded-Port. |
||
57 | $port = in_array( $host_port, array( 80, JETPACK_SIGNATURE__HTTP_PORT ) ) ? '' : $host_port; |
||
58 | } |
||
59 | |||
60 | $url = "{$scheme}://{$_SERVER['HTTP_HOST']}:{$port}" . stripslashes( $_SERVER['REQUEST_URI'] ); |
||
61 | |||
62 | if ( array_key_exists( 'body', $override ) && ! empty( $override['body'] ) ) { |
||
63 | $body = $override['body']; |
||
64 | } else if ( 'POST' == strtoupper( $_SERVER['REQUEST_METHOD'] ) ) { |
||
65 | $body = isset( $GLOBALS['HTTP_RAW_POST_DATA'] ) ? $GLOBALS['HTTP_RAW_POST_DATA'] : null; |
||
66 | |||
67 | // Convert the $_POST to the body, if the body was empty. This is how arrays are hashed |
||
68 | // and encoded on the Jetpack side. |
||
69 | if ( defined( 'IS_WPCOM' ) && IS_WPCOM ) { |
||
70 | if ( empty( $body ) && is_array( $_POST ) && count( $_POST ) > 0 ) { |
||
71 | $body = $_POST; |
||
72 | } |
||
73 | } |
||
74 | } else if ( 'PUT' == strtoupper( $_SERVER['REQUEST_METHOD'] ) ) { |
||
75 | // This is a little strange-looking, but there doesn't seem to be another way to get the PUT body |
||
76 | $raw_put_data = file_get_contents( 'php://input' ); |
||
77 | parse_str( $raw_put_data, $body ); |
||
78 | |||
79 | if ( defined( 'IS_WPCOM' ) && IS_WPCOM ) { |
||
80 | $put_data = json_decode( $raw_put_data, true ); |
||
81 | if ( is_array( $put_data ) && count( $put_data ) > 0 ) { |
||
82 | $body = $put_data; |
||
83 | } |
||
84 | } |
||
85 | } else { |
||
86 | $body = null; |
||
87 | } |
||
88 | |||
89 | if ( empty( $body ) ) { |
||
90 | $body = null; |
||
91 | } |
||
92 | |||
93 | $a = array(); |
||
94 | foreach ( array( 'token', 'timestamp', 'nonce', 'body-hash' ) as $parameter ) { |
||
95 | if ( isset( $override[$parameter] ) ) { |
||
96 | $a[$parameter] = $override[$parameter]; |
||
97 | } else { |
||
98 | $a[$parameter] = isset( $_GET[$parameter] ) ? stripslashes( $_GET[$parameter] ) : ''; |
||
99 | } |
||
100 | } |
||
101 | |||
102 | $method = isset( $override['method'] ) ? $override['method'] : $_SERVER['REQUEST_METHOD']; |
||
103 | return $this->sign_request( $a['token'], $a['timestamp'], $a['nonce'], $a['body-hash'], $method, $url, $body, true ); |
||
104 | } |
||
105 | |||
246 |
PHP has two types of connecting operators (logical operators, and boolean operators):
and
&&
or
||
The difference between these is the order in which they are executed. In most cases, you would want to use a boolean operator like
&&
, or||
.Let’s take a look at a few examples:
Logical Operators are used for Control-Flow
One case where you explicitly want to use logical operators is for control-flow such as this:
Since
die
introduces problems of its own, f.e. it makes our code hardly testable, and prevents any kind of more sophisticated error handling; you probably do not want to use this in real-world code. Unfortunately, logical operators cannot be combined withthrow
at this point:These limitations lead to logical operators rarely being of use in current PHP code.