|
| 1 | +Laravel and PHP Best Practices |
| 2 | +=============== |
| 3 | + |
| 4 | +Source Control |
| 5 | +-------------- |
| 6 | + |
| 7 | +1. Only store custom applicaton code in git. |
| 8 | + |
| 9 | + Now that we are using composer, all dependencies only need to be referenced in the composer.json file. No need to store them locally. |
| 10 | + |
| 11 | + Source: [Composer best practices](https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md) |
| 12 | + |
| 13 | +2. Similarly, don't store operational directories such as `logs/` in git. These can be created during deployment. |
| 14 | + |
| 15 | + Use the .gitignore file to implement the above. |
| 16 | + |
| 17 | +Code Generation |
| 18 | +---------------- |
| 19 | + |
| 20 | +1. Use generators instead of creating code manually. |
| 21 | + |
| 22 | + This enforces a consistent approach and will save you a lot of time! |
| 23 | + |
| 24 | +Database Changes |
| 25 | +----------------- |
| 26 | + |
| 27 | +1. Create a new migration for each database change. This allows you to track database changes against versions of the app. |
| 28 | + |
| 29 | +User Input |
| 30 | +------------ |
| 31 | + |
| 32 | +1. Never trust or directly use user input. For example, inserting the value from a user's form post directly into the database. All values that are either stored, output, or used otherwise must be validated before taking action on the value. |
| 33 | +2. Similarly, never manually generate SQL queries by concatenating hard-coded SQL with user input. This is likely to allow SQL injection attacks. |
| 34 | + |
| 35 | +Code Organisation and Structure |
| 36 | +-------------------------------- |
| 37 | + |
| 38 | +1. Implement the DRY principle: **D**on't **R**epeat **Y**ourself. Any time you see a given piece of logic appear twice, implement it in a base class or helper method. Having the logic in one location makes it much easier to change this logic in future, rather than having to find every place it is implemented. |
| 39 | + |
| 40 | + In Laravel, you can implement generic helper functions in a reusable way by defining them in classes within `app/lib/`. Once you have done this add this path to `app/start/global.php` within the `ClassLoader::addDirectories` array. You can then call them from anywhere in your application. |
| 41 | + |
| 42 | + This type of global function is not the ideal method because it is not clear exactly how to use the functions, or where they are used. |
| 43 | + |
| 44 | + In Laravel it is better to implement common functions and behaviours in: |
| 45 | + * event handlers, which can be triggered before/after a route, controller method, etc |
| 46 | + * base classes, for example implementing all desired custom controller behaviour into an `MyDevShopBaseController` |
| 47 | + * [Facades](http://laravel.com/docs/facades) |
| 48 | + * service providers, which allow you to include components into your application in a modular way. They can be managed separately to your web applications, and can be easily included when needed. |
| 49 | + |
| 50 | +2. Create base classes for all model, controller, view classes. Even if you don't end up putting anything in the base class, this approach has the following benefits: |
| 51 | + * Easier to add future requirements, e.g. we need to convert all out controllers so that they allow soft-deletion only. Adding this to the controller base class is a lot less dev/test work that converting each of our controller classes one by one. |
| 52 | + * Encapsulate common functionality in one place (DRY) |
| 53 | + |
| 54 | +Use of External Libraries |
| 55 | +--------------------------- |
| 56 | + |
| 57 | +1. Always include external libraries via composer. This allow you to easily keep track of which version you are using, and easily update your dependencies when they change. |
| 58 | + |
| 59 | +2. Never change code in an external library. This will break your upgrade path! If you need to vary the behaviour, either: |
| 60 | + + fork the library, fix the issue, and submit a pull request, or |
| 61 | + + derive a sub class from the library's class and override the desired behaviour |
| 62 | + |
| 63 | +Messages |
| 64 | +--------------- |
| 65 | + |
| 66 | +1. Never include messages directly at the point at which they are used. Instead include them in a resources file, named clearly. Benefits: |
| 67 | + - When you need to change them you only have to look in one file |
| 68 | + - The file can be replaced depending on the user's language settings, thereby translating your application's messages. |
| 69 | + |
| 70 | + In Laravel, the best place to put messages in the language files. For example: `app/lang/en/notification.php` |
0 commit comments