Haszprus

Automata refaktor #2

©   Haszprus   |   fejlesztés php phpstorm

Muszáj vagyok tovább menni az automata refaktorálás "csapdáin".

Valamiért a PHPStorm is nagyon kínálgatja hogy egy függvényből való visszatérés előtt az utolsó változót inline-oljam, és a Rector is simán automatán kiirtja a fölöslegesnek vélt utolsó változókat return előtt, tehát:

$x = something(..);
return $x;

Helyett használjam ezt:

return something(...);

De vaffankúló (amúgy ezt nem szoktam használni, de ide illik), komolyan, miért?! Mi ez a trend? Rájöttünk ezer éve, hogy a függvénynevek és változónevek ugye milyen fontosak hogy jól legyenek elnevezve, erre jön valaki (egy egész trend), és azt mondja, hogy szerinte spóroljunk meg egy változónevet.

Ami azt jelenti, hogy elveszítesz egy tök fontos információt, hogy mi történt az utolsó lépésben.

Csak a példa kedvéért:

function foo($pattern) {
  // ... some other logic here ...
  return preg_replace('{^(([^.+*?\[^\]$(){}=!<>|:\\\\#-]+|\\\\[.+*?\[^\]$(){}=!<>|:#-])*).*}', '$1', $pattern);
}

A fenti kódot a Composer Autoloaderéből szedtem, szóval teljesen real world, és biztosan nem a saját hülyeségem (ott fel van kommentezve* amúgy, és nem ennyiből áll a függvény, de ettől még tök jó példa). Tegye fel a kezét, aki szerint tök fasza, ha nincs elnevezve, hogy mit is kapunk ebből a preg_replace-ből. :Đ

* arról nem is beszéltem h van aki szerint a kommentek is hülyeségek :D Egy időben amúgy totál ezt vallottam én is, most szopok rendesen ahogy refaktorálom a blogot :D Kommentezek "mindent". (És nem azért mert nem használtam jó változóneveket/függvényneveket.)

RSS: hozzászólások ehhez a bejegyzéshez 4 hozzászólás

Szólj hozzá Te is!

mit is kapunk ebből a preg_replace
ha beszédes* a neve a hívott függvénynek, akkor máris átjön, nem?

* foo(…) helyett ugye irl get_something(…)

adamo, gondoltam, gondoltam h ez el fog hangzani érvként

De nem feltétlen

Azaz persze a függvénynévből kiderül h mit kapunk vissza de az utolsó lépés akkor se derül ki h mi volt

Ha mondjuk ez az utolsó lépés h preg_replace(valami világrengető regex) akkor.. na mi történt abban a lépésben?

míg mondjuk egy mittomén $withoutHtml = preg_replace("… ") rögtön érthetővé teszi h mi történik a sorban

De bevallom h ha egy változón egymás után mondjuk 5 preg_replace-t csinálok tény h nem hívom a változót minden sorban új változónak, pedig amúgy most így utólag belegondolva kiváló ötlet lenne (ha memória szempontjából nem is)

A preg_replace-t csak azért hozom példának, mert az nyilvánvalóan nem az a kategória hogy ránézel és tudod

Ezen kívül van még egy okom a külön
  $x =…;
  return $x;

Sorokra

Könnyebb breakpointot rakni bele. (vagy csak én nem tudok breakpointot rakni egy return valamikifejezés-be? )
válasz 1 like

Ezek általában ökölszabályok amik általánosan jók, de nem vakon mindig alkalmazva.

A konkrét példában el lehetne nevezni a patternt is kb így:


Function foo($pattern) {
  //… some other logic here…
  $tagContentMatcher = '{^(([^.+*?\[^\]$(){}=!<>|:\\\\#-]+|\\\\[.+*?\[^\]$(){}=!<>|:#-])*).*}';
  return preg_replace($tagContentMatcher, '$1', $pattern);
}
válasz 2 like

Orca, ah ez, amit írsz amúgy egy kurvajó megoldás

Btw kezdem beadni a derekam ezek előtt a rule-ok előtt, mert az uniformizálás azért nem rossz, meg legalább érezzem h valaki velem együtt dolgozik a kódon , szóval nem azért raktam fel a rectort hogy kirakjon két voidot return type-nak
válasz 1 like
Hozzászólásod:


Nem vagy bejelentkezve, de...

A)
hozzászólhatsz regisztrálatlanul...

B)
ha regisztrálva vagy, bejelentkezhetsz...