Quick preview – Develop PHP with standards. Fallow this rules to ensure your code is legit and well formed. Keep up with those principle and you will become a better programer.

KISS – “Keep ISimple, Stupid”

The simpler your code is, the simpler it will be to maintain it in the future. This will be greatly appreciated by anyone that needs to examine your code or even to yourself coming back to this code in future.

Most systems work best if they are kept simple rather than making them complex, therefore, simplicity should be a key goal in design and unnecessary complexity should be avoided.
by Kelly Johnson.

Avoid using complex features if you can write it in more clear and understandable way. Allow for complexity only if it is necessary to solve the problem. Even then try to make look easy for others. This can be achieve by varies methods for example: using the right naming, descriptive commentary on the code, picking the right solution perhaps well known and documented design pattern. You name it. Do everything you can to make it understandable for others.

  • Be Humble, don’t think of yourself as a super genius, this is your first mistake
    By being humble, you will eventually achieve super genius status =), and even if you don’t, who cares! your code is stupid simple, so you don’t have to be a genius to work with it.
  • Break down your tasks into sub tasks that you think should take no longer than 4-12 hours to code
  • Break down your problems into many small problems. Each problem should be able to be solved within one or a very few classes
  • Keep your methods small, each method should never be more than 30-40 lines. Each method should only solve one little problem, not many uses cases
    If you have a lot of conditions in your method, break these out into smaller methods.
    Not only will this be easier to read and maintain, but you will find bugs a lot faster.
    You will learn to love Right Click+Refactor in your editor.
  • Keep your classes small, same methodology applies here as we described for methods.
  • Solve the problem, then code it. Not the other way around
    Many developers solve their problem while they are coding, and there is nothing wrong doing that. As a matter of fact, you can do that and still adhere to the above statement.
    If you have the ability to mentally break down things into very small pieces, then by all means, do that while you are coding. But don’t be afraid of refactor your code over and over and over and over again. Its the end result that counts, and number of lines is not a measurement, unless you measure that fewer is better of course.
  • Don’t be afraid to throw away code. Refactoring and recoding are two very important areas. As you come across requirements that didn’t exist, or you weren’t aware of when you wrote the code to begin with you might be able to solve the old and the new problems with an even better solution.
    If you had followed the advice above, the amount of code to rewrite would have been minimal, and if you hadn’t followed the advice above, then the code should probably be rewritten anyway.
  • And for all other scenarios, try to keep it as simple as possible, this is the hardest behavior pattern to apply to, but once you have it, you’ll look back and will say, I can’t imagine how I was doing work before.

YANGI – “You Aren’t Gonna Need It”

You might also find KISS going on a date with YAGNI which stands for “You Aren’t Gonna Need It” which in short states that you should not develop more then you might need to solve the problem, just because you might use some of this functionality in future but it is not certain. Ending up not needing it at all and removing it from your code at later point in time. Not saying don’t think of important design solutions for the job. Just don’t build a nuck to kill a fly.

DRY – “Don’t Repeat Yourself”

(This content is under development … – come back later)


(This content is under development … – come back later)



Would love your thoughts, please comment.x