Submitted by Martin on Thu, 10/13/2011 - 11:59
There are several basic principles and valuable info at drupal.org on Drupal development, everyone who does some programming for Drupal should stick to. However, I would like to mention several more principles, which will definitelly affect the quality of your final product in a positive way.
-
Strive for clean code, by following these rules:
-
The number of lines for a function should not exceed the screen height.
-
A function should manage only one responsibility, which is in fine manner described by the function name.
-
Always write comments for a function that should at least describe return value and input parameters.
-
Try to avoid immersions of ifs or other code blocks. In 99% of cases you can solve the logic with one immersion.
-
Avoid situations where input parameters or return values change types. Let's say that it is okay to return boolean FALSE on failure (that should be handled by throwing an exception, but that is not regular in PHP). However it is inappropriate if a function returns array or string. That will result in error caused by treating the return value as different type (ie. if the return value is expected to be of array type and is passed into foreach cycle). Same implies for input parameters. But in this case it is not so error prone as the different types can be handled within the function and function documentation might make it clear. For example, if we have a getter that accepts criteria parameter of type array and based on these criteria an object is selected from database, we may provide a convenient way in means of allowing to pass in an int value as an unique id of the object we want to get.
-
Ask yourself - is my code understandable also for other programmers? Or, if it was not you who wrote the code, would you understand it without much struggle? The point is that other programmers should invest as little time as possible to be able to contribute, which is one of the principles of opensource.
-
Group functions with similar responsibilities into separate files. I recommend following separation:
-
.module - bootstrap file where you implement all Drupal HOOKs, define constants, call includes, etc.
-
.pages.inc - code that handles page-flow logic and output.
-
.theme.inc - design layer.
-
.util.inc - utility functions, eventually business logic.
-
.inc - API, database interaction, business logic.
-
Distinguish private functions, that is functions which should not be called from outside of the module. By doing so you inform other programmers that by inappropriate calling an inconsistencies or other problems may occur.
-
In the theme layer do not query database, do not implement application logic, do not call API functions. Drupal provides sophisticated template engine which allows all needed values to be passed in to the template file.
-
Use PHP debugger and profiler. Debugger is not just fine tool to find bugs, but also gives you control over the code as a whole thanks to possibility of stepping over each instruction. Profiler is very helpful while tuning the performance of application.
-
If you define own node types in a module, cck fields, Drupal variables, or other enum types, define constants for them. In case of change you will not have to override all occurrences, moreover if you use IDE that understands PHP, it will autocomplete constant names for you.
Add new comment