| Conditions | 22 |
| Paths | 784 |
| Total Lines | 97 |
| 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 |
||
| 110 | public function request($method, $endpoint, $options = [], $query_string = null, $requires_auth = true) |
||
| 111 | { |
||
| 112 | $url = $this->generateUrl($endpoint, $query_string, $requires_auth); |
||
| 113 | |||
| 114 | $options = array_merge($this->clientOptions, $options); |
||
| 115 | $options["headers"]["User-Agent"] = $this->user_agent; |
||
| 116 | |||
| 117 | if ($this->oauth2) { |
||
| 118 | $options["headers"]["Authorization"] = "Bearer " . $this->key; |
||
| 119 | } |
||
| 120 | |||
| 121 | try { |
||
| 122 | $keepTrying = true; |
||
|
|
|||
| 123 | $exceptionCounter = 0; |
||
| 124 | if($this->handleRateLimits |
||
| 125 | && !is_null($this->requestsRemainingThisSecond) |
||
| 126 | && ( |
||
| 127 | ($this->requestsRemainingThisSecond <= 1) |
||
| 128 | || |
||
| 129 | (($this->requestsRemainingThisSecond <= 2) |
||
| 130 | && ($this->requestsRemainingThisSecondTime == time())) |
||
| 131 | ) |
||
| 132 | ){ |
||
| 133 | usleep($this->backOffDelay); |
||
| 134 | } |
||
| 135 | do { |
||
| 136 | try { |
||
| 137 | $response = $this->client->request($method, $url, $options); |
||
| 138 | $keepTrying = false; |
||
| 139 | } catch (\GuzzleHttp\Exception\BadResponseException $e) { |
||
| 140 | if(!$this->handleRateLimits) { |
||
| 141 | throw $e; |
||
| 142 | } |
||
| 143 | switch ($e->getCode()) { |
||
| 144 | /** |
||
| 145 | * @see https://developers.hubspot.com/docs/faq/api-error-responses |
||
| 146 | * |
||
| 147 | * 500 This is not documented but it happens. Seems like its part of the rate limiting but they |
||
| 148 | * choose this instead of 429 in some cases. If the message is "internal error" then that means |
||
| 149 | * we have to backoff, otherwise re-throw the user error for them to handle it |
||
| 150 | */ |
||
| 151 | case 500: |
||
| 152 | if(strpos($e->getMessage(),'"message":"internal error"') === false) { |
||
| 153 | throw $e; |
||
| 154 | } |
||
| 155 | /** |
||
| 156 | * 502/504 timeouts - HubSpot has processing limits in place to prevent a single client causing |
||
| 157 | * degraded performance, and these responses indicate that those limits have been hit. |
||
| 158 | * You'll normally only see these timeout responses when making a a large number of requests |
||
| 159 | * over a sustained period. If you get one of these responses, you should pause your requests |
||
| 160 | * for a few seconds, then retry. |
||
| 161 | */ |
||
| 162 | case 502: |
||
| 163 | case 504: |
||
| 164 | /** |
||
| 165 | * 429 Too many requests - Returned when your portal or app is over the API rate limits. |
||
| 166 | * Please see this document for details on those rate limits and suggestions for working within |
||
| 167 | * those limits. |
||
| 168 | */ |
||
| 169 | case 429: |
||
| 170 | $matches = []; |
||
| 171 | preg_match('/X-HubSpot-RateLimit-Daily-Remaining: (\d+)/', $e->getMessage(), $matches); |
||
| 172 | if(isset($matches[1])) { |
||
| 173 | $dailyLimitLeft = (int)$matches[1]; |
||
| 174 | if($dailyLimitLeft === 0) { |
||
| 175 | throw $e; |
||
| 176 | } |
||
| 177 | } |
||
| 178 | $exceptionCounter++; |
||
| 179 | if ($exceptionCounter >= $this->exceptionMax) { |
||
| 180 | throw $e; |
||
| 181 | } |
||
| 182 | usleep($this->exceptionDelay); |
||
| 183 | $keepTrying = true; |
||
| 184 | break; |
||
| 185 | default: // Throw to outer handler |
||
| 186 | throw $e; |
||
| 187 | } |
||
| 188 | } |
||
| 189 | } while ($keepTrying === true); |
||
| 190 | |||
| 191 | // Check headers for delay |
||
| 192 | if($this->handleRateLimits) { |
||
| 193 | $this->requestsRemainingThisSecond = (int)$response->getHeader('X-HubSpot-RateLimit-Secondly-Remaining')[0]; |
||
| 194 | $this->requestsRemainingThisSecondTime = time(); |
||
| 195 | } |
||
| 196 | |||
| 197 | if ($this->wrapResponse === false) { |
||
| 198 | return $response; |
||
| 199 | } |
||
| 200 | return new Response($response); |
||
| 201 | } catch (\GuzzleHttp\Exception\BadResponseException $e) { |
||
| 202 | throw new BadRequest(\GuzzleHttp\Psr7\str($e->getResponse()), $e->getCode(), $e); |
||
| 203 | } catch (\Exception $e) { |
||
| 204 | throw new BadRequest($e->getMessage(), $e->getCode(), $e); |
||
| 205 | } |
||
| 206 | } |
||
| 207 | |||
| 239 |
This check looks for variable assignements that are either overwritten by other assignments or where the variable is not used subsequently.
Both the
$myVarassignment in line 1 and the$higherassignment in line 2 are dead. The first because$myVaris never used and the second because$higheris always overwritten for every possible time line.