One of the great challenges of PHP is that it’s so easy to learn, that just about anyone can learn it with not too much of an effort. While this is great for the number of PHP developers, it also seems to have the effect, that there is a huge number of bad examples of code out there. How do you then know good code?
In my book there are a few signs, which you could judge from – and they may even apply broader than just php-code.
First sign: It does the job
The code should be designed for the challenge at hand. Too often developers seem to apply the same style and energy to solve a challenge – no matter how much they differ in complexity and importance. If it’s a simple little function being developed, it shouldn’t require a huge framework.
If it deals with financial or personal data, it should probably utilize transactions and apply logging. Did the developer think of the challenge they set out to solve? – if so it’s a good sign.
Second sign: Well-structed
How does the sourcecode look? Are there mile long lines of code or are they sanely formatted? Is the code broken into functions, classes or another structure – or is it just page after page of sourcecode? – I don’t need to see all code as classes nor as neat function-libraries, but I do like if the developer has made an effort to break an application into some manageable pieces somehow.
Third sign: Reasonable naming scheme and comments
How does the function names, classnames and variable names look? is it random garbage or does it make sense? – I really hate variables named from $a to $z – and I do hate functions named “doSomething” – without specifying it further. I would expect great code to utilize the same naming conventions (CamelCaseing, underscores and so on) across all functions and/or variables.
If strange – as in unnatural/unexpected – things happen in the source code, I would expect a (short) comment explaining what’s going on.
Fourth sign: Security and Contingency
Did the developer think about security? is the code wide open for xss attacks? is input validated? Is “the unexpected” handled gracefully or does the code explode if exposed to simple URL-manipulation? Do you know what a SQL-injection is? If you need data from another source, what happens if it isn’t available? – does the code blow up or does it burn gracefully?
How do you recognize good code?
One of the funny observations as a web developer: It’s amazing how many people consider caching bad by definition. If you know what you’re doing, caching is an amazingly powerful tool, which can provide cheap and efficient scaling to those who know how to use it.
Know when it’s okay to cache
If thousands of people see the same non-personal frontpage of your website – do you then do the 20+ database queries to build a fresh one for each visitor or do you just refresh a cacheable version from time to time?
Cacheing isn’t a binary this
While a page on a website may not be cacheable as a whole, is your navigation, your header and footer – and other static parts of the site cacheable? is new menu-items are rare compared to the number of page views, the pages probably receives, the “semi-static” parts of a site should absolutely be cacheable (server side).
Consider you cacheing options
Do make a caching strategy and see what works best for you. Is it a caching server in-front of your website (such as varnish), is it pre-build HTML-files, is it shared memory or is it blobs in the database serving pre-build pieces? The efficiency and the fit to the task may change from case to case, but knowing there is a range of options and knowing what the different options are good for, should be a required skill for any professional web developer.
Caching isn’t evil, it’s your friend – if you know how to use it efficiently.
Many online sites such as news-sites and other content providers often have a “tip a friend” option. With this you can mail a friend and tell them about an interesting piece of content you’ve found. The Idea seems quite simple, and everyone should have the tip-option, wright? – no, wrong. While it may offer a convenience for some, it has several backsides.
First if you – or your email provider – has implemented anti-spam techniques such as SPF-records, the “tipping mail” will not be sent through the authorized list of mail-servers and thus have a larger likelihood of being labeled as spam. Your mail be sent, but you don’t know if it will arrive in your friends mailbox.
Second having two (assumable) valid email addresses submitted to a site could be a goldmine for evil spammers. Besides mailing the tip, the email addresses may be collected and abused some time in the future.
Third by having a site sending thousands and thousands of “tips” to friends does mimic a spammers’ behavior – the function may cause your servers to be labeled as a spamming server, and you may not be able to send mails – no tips nor important messages your servers may try to mail to you or other users.
If you want to have a “Tip a friend” function – make sure it’s a mailto-link.
The mailto-link may not be as sexy as the options available when you create the mails server side, but the links go out from the users’ own mail client and the likelihood of it being labeled as spam is far less. It also gives the user complete control of what is being sent – no unexpected ads or anything else unwanted material.