
Clean Code concepts adapted for PHP - djug
https://github.com/jupeter/clean-code-php
======
bahjoite
A nice thing about this being open and editable is that the original author
has obviously learnt quite a bit since their initial commit.

How to do for and foreach loops for example:
[https://github.com/jupeter/clean-code-
php/commit/08d73d655ef...](https://github.com/jupeter/clean-code-
php/commit/08d73d655efcbab0ae789326fc016ffacc2fdaa2)

~~~
radicalbyte
The best thing about open source is that even seasoned PHP Architects can
learn useful language features such as for and for each loops.

~~~
throwaway2016a
I'm giving him the benefit of the doubt that this was a copy and paste error.
With that said, as someone who has written physical paper programming books...
this kind of thing would get me 10 x 1 star reviews on Amazon.

~~~
radicalbyte
I think that you're being kind. Unfortunately these types are more the rule
than the exception, and are most certainly not restricted to PHP. The dotnet
world is full of failed developers who manage to talk themselves up.

For all the good that Uncle Bob and the like do they have become enablers for
these snake oil architects.

~~~
mtzaldo
I can't agree more about the dotnet "architects"

------
huhtenberg
This is an odd mix of common sense, random cosmetic advice, subjective bits
and points that are plain wrong or contradictory to other points. For example:

    
    
        Bad:
            $ymdstr = $moment->format('y-m-d');
    
        Good:
            $currentDate = $moment->format('y-m-d');
    

Both are inferior to "$ymd".

    
    
        Use searchable names
        
            addExpireAt(DateGlobal::SECONDS_IN_A_DAY);
    

Who would ever need to search for _that_? You'd _search_ for "Expire". This
doesn't preclude from using named constants, but it has nothing to do with
search-ability per se.

    
    
        Don't use flags as function parameters
    
        Good:
    
            function createFile($name) { touch($name); }
            function createTempFile($name) { touch('./temp/'.$name); }
    

Now, this is how you create the good old copypasta.

What you need instead is a single universal function that does in fact accept
a boatload of parameters, but that is never meant to be called directly. You
then supplement it with a host of simpler one-liners that fill in most of the
parameters with defaults and forward just the select few.

    
    
        Avoid negative conditionals
    

should be "Avoid double-negative conditionals".

    
    
        Avoid conditionals
    

this is just overly broad to the point of being completely pointless. What the
example proposes is to use abstraction and inheritance instead. In some cases
it helps, but it many it leads to needlessly obscure code that's impossible to
read off the page.

    
    
        Use method chaining
    
        Good:
    
            $car = (new Car())
              ->setColor('pink')
              ->setMake('Ford')
              ->setModel('F-150')
              ->dump();
    

Except at some point you will need setModel() to fail for some arguments, e.g.
setModel('Trabant'), and you will end up with some methods returning $this and
some not. This is not going to be a "clean code" by any measure.

(edited for clarity a bit)

~~~
zimpenfish
> Both are inferior to "$ymd".

I half-prefer `$currentDate` but then it doesn't really contain the essential
"it's a YMD string" information. `$currentYMD` would be better than all of the
above, IMO.

All of which assumes you religiously stick to "`...YMD` means a 'Y-M-D'
formatted string" and "`...Date` means a date object", mind, otherwise you
might as well pick random strings.

~~~
coldtea
> _I half-prefer `$currentDate` but then it doesn 't really contain the
> essential "it's a YMD string" information_

That information is not essential. If the date is later changed to also take
hour/minute etc, it will still be currentDate but not YMD.

Unless you need to work with the structure of the date, and not just pass it
along, currentDate is better.

~~~
zimpenfish
> That information is not essential.

It is if you're passing it to something which expects to receive a YMD date.

Also a `$currentDate` which also contains the time is borderline acceptable if
specifically called out in comments / docs but I would still ding it in a
review.

~~~
coldtea
> _It is if you 're passing it to something which expects to receive a YMD
> date._

You don't want to expose what kind of date string that something depends upon
in your variable name.

This way you you can change the internal implementation (what you pass and the
function that received it) and not 1000 places where it's called.

~~~
zimpenfish
> You don't want to expose what kind of date string that something depends
> upon in your variable name.

Sure you do if you're a subscriber to Hungarian Notation. And if you're
working in a loosely-typed language, it helps a lot to be able to track types
through variable names.

~~~
coldtea
> _Sure you do if you 're a subscriber to Hungarian Notation._

Hungarian notation encodes types (and/or scope etc) -- not formatting details.
Where would it stop if the latter was the case?

> _And if you 're working in a loosely-typed language, it helps a lot to be
> able to track types through variable names._

ymd is not a type though. str_currentDate is.

~~~
zimpenfish
> Hungarian notation encodes types (and/or scope etc) -- not formatting
> details

That entirely depends on your interpretation of Hungarian - there are many.
Plus "YMD" is easily valid as a type - imagine creating a struct with { y int;
m int; d int; } and using that instead.

> ymd is not a type though.

Only because you have decided it isn't in this instance. There is no obstacle
to it being a type.

~~~
coldtea
Also because types in PHP are specific things.

------
sitepodmatt
Interesting. I'm not sure if enterprise OO design patterns / clean code /
solid / GoF / all golden OO etc.. is a help or hindrance in a typical build
the world destroy the world per request model that is PHP. It might be in the
spirit but if you're freshly creating all these objects and a big ass
dependency graph from scratch per request for each request then you'd be
better be sure the promise of PHP 7 VM being superbly improved holds true in
your app's case. In other stacks you'd have a lot of this available for the
next request at app level or cached somehow (already deserialized), in PHP you
really are Creation Day 1 each hit. When you grow to something as complicated
as an ecommerce frontend all nasty hacks come into play around the New World
New Request model definitely undo a lot of benefits - see Magento as a good
example (the cache system - essentially concat / rewriting PHP files) - people
have even suggested let's go back to pure SQL and echo..

I initially thought this was going to be the use something else meme -
[http://devhumor.com/content/uploads/images/December2016/php-...](http://devhumor.com/content/uploads/images/December2016/php-
best-practices.jpg)

~~~
debacle
> if you're freshly creating all these objects and a big ass dependency graph
> from scratch per request for each request

That's not how modern PHP works.

~~~
icedchai
How's it work then?

~~~
debacle
[https://community.1and1.com/php-7/](https://community.1and1.com/php-7/)

That article isn't great, but okay enough for this discussion.

There's a great deal of interpreter level caching + object caching (in more
advanced system) that allows modern PHP to reap a lot of the benefits of the
"everything fresh every request" model while also being faster than pretty
much anything but Lua and Perl.

------
mattdeboard
Top thread: People dickering over variable naming in PHP, based on a post
about an open-source translation of an Uncle Bob book.

It's like HackerNews BINGO.

------
steinuil
I'd like to recommend "Taking PHP Seriously" by Keith Adams, a lecture by an
engineer at Facebook on the alleged good points of using PHP.

------
brian-armstrong
I can't be the only one expecting it to say "just don't", right?

~~~
mhd
Because of PHP or Uncle Bob?

~~~
ge96
Is using PHP bad? I've seen speed comparisons and it is slow. I feel bad so
far it's the only back end language I know unless counting JavaScript but
don't currently use Node in development.

I just keep seeing it being labeled bad a lot. I guess it depends if you can
avoid it right? The current company that I work for (contract hourly) is a
LEMP stack built on WordPress. Ideally I could strip WordPress out and get to
the core purpose of the web application but it's not at that stage yet. I like
the idea of separated services but

Edit: I saw some infographic saying PHP was too easy to use/get into and
resulted in many bad coders who were using it. It's also old, whenever I'm on
the manual site and see the comments dating back to 10 years haha. What about
machine code running on computers.

~~~
thisrod
After being forced to use PHP, I've come to respect it a lot more than when
I'd only looked at it. There is nothing ground breaking in bog-standard
imperative control flow, a default data structure of association lists whose
keys are numbers or strings, and libraries to parse every format under the sun
into that structure and generate it again. On the other hand, that combination
is very efficient for the many non-web programmers who occasionally need to do
something with a web server.

~~~
ge96
Kind of funny going the other approach, web to non-hardware. Working with
Raspberry Pi to hookup an LCD panel and get the local IP on shared network.
Man that was challenging, not the python/code but the wiring... Then just
include libraries and add to cron. It's cool interfacing sensors/physical with
web.

------
aaronchall
_writes a book on php best practices_

 _all the pages are blank_

