There are hundreds of ways to writing out code with hundreds of methods to achieve certain functionality. However, out of these many ways of writing code to get to the final product, there are many habits that are not great to the programmer or to the functionality of what you are trying to achieve. Furthermore, we discuss 10 tips for improving and writing better PHP code.

Development Style

Tabbing, double-spacing, all on one line; we all have our style of writing out code and there really is not a right or wrong way of laying your code out. However, many developers tend to fail at keeping their development style fluent throughout a project. I myself have been caught a few times adapting to new styles within one project.

Furthermore, it is best to keep your code laid out using one development style rather than several to keep your code easily readable and organized. If your development style sometimes evolves to something different, it is best to not use your new development style on a project that uses a different style, but rather implement your new development style on new projects you may start. This keeps all of your projects fluent and organized.

Good Variable and Function Naming

Many developers do not really care about proper variable and or function naming. However, good function and variable naming is key to have more organized code, which categorizes under better-written code as it becomes clearer to understand and comprehend.

Naming variables and functions properly is rather something easy to do and should be based on what the variable value is and what the function achieves. This not only provides easy to understand names, but it also helps you and other developers understand what each function or variable performs and holds by just reading the short name.

Commenting Your Code

Commenting your code is a major step to organized and readable code and actually compliments most of what you can do to organize your code, as it is a key aspect in organization and usability. When writing comments to describe certain actions, functions, or code, it is best to keep the comments strict and to the point without describing what everything is.

For example, if you have a code snippet that is quite obvious in terms of its functionality, it is best to either leave a few words about it or not to comment it at all, as too many comments can be obnoxious.

Do Most of the Work

Copying and pasting code is something we tend to do most of the time, from one project to another, or from code, we may find useful on the net that has been done for us. However, copying and pasting code can sometimes hurt you in the end as you may not be familiar with your project or code as much as you had hoped you were or as much as you need to be. Furthermore, copying and pasting a few snippets is fine, but you should do most of the work to freshen your memory.

Look Around

Sometimes we might be doing something new and do not know what the best route is to take in terms of speed and performance, thus, looking around at other code from people who created something similar to what you are creating is sometimes a great idea to do to obtain a general idea on how to approach it better. This does not necessarily mean copy and paste the code, but rather just get a general idea of how it works.

Understand the Language’s Limitations

We sometimes try to achieve many things the language was not designed for or is not capable of doing by creating workarounds. This is not a great idea, as your created workaround may not work sufficiently or effectively. Therefore, it is best to understand the language’s limitations, and to work within them.

Receive Structural Feedback

We sometimes think that we are the only ones, who know how to properly develop, but we are not and in fact, there is always someone out there better than us. My point is, it is always good to receive a second opinion on your code in terms of structure, as some feedback can be critical to enhance the performance of your script.

Testing Your Code Often

Part of making your scripts closer to bug free is to test your work often and as you go along. The problem with many developers is that they think what they develop should work fine the first time and decide not to test certain aspects of their script as they go along, and in the end, they end up with several bugs and many they may not catch immediately. With that said, it is in your best interest to test many aspects of your code or script for bugs as you go along in development, this is proven to reduce bugs in the long run.

Built-ins over Building Your Own

We sometimes tend to recreate a built-in function just to have it. The problem with unnecessary recreation of built-ins is that the performance is affected. Moreover, using built-ins when applicable is a better idea and not only does it increase performance, it also keeps your scripts clean from unneeded code.

Don’t Split Everything into Files

Splitting your code into several files is actually part of keeping your scripts or projects organized instead of having everything all in one file. However, many projects I have seen tend to split everything into many files, sometimes separating individual functions into individual files.

This overkill and not only affects the way your code is laid out but it also affects performance. For example, instead of splitting individual functions into individual files, create a functions file and store all of them there, or group them into files. This still keeps your project organized and it keeps things reasonable.

Remember, doing something beneficial is great, but overdoing it or not doing it at all causes a negative effect, thus, use your judgment, and use techniques and methods reasonably.

  • Pingback: 10 Tips for Writing Better PHP Code | Lively Design Tuts()

  • http://pancakeapp.com Lee

    In regards to splitting up files, if you use a framework such as CodeIgniter or CakePHP you can take advantage of a more structured MVC style of coding. This nets you same result of having neatly organized code you can reuse within the application with the overhead of loading individual files.

  • Pingback: Top Links al diseño #3 | BaseKit()

  • http://tutorial-city.net/ Tutorial City

    You should be concious when commenting. inline comments are, in general, a bad practice. When using OOP you can often replace an inline comment by a method, which must have a self explanatory name.