Zend Studio for Eclipse includes some powerful and customizable features for code analysis. Your first question might be, “What is a code analyzer?” The answer is, “A bunch of things.” More formally, a code analyzer is a suite of tools that provide visual and interactive ways to write, debug, and maintain code. This chapter outlines ways that you can use and configure the code analyzer for your projects.
The code analyzer uses visual cues in the code editor and the Problems view. These cues include highlighting and underlining code and placing icons in the margins of the code editor. Tool tips are also available to provide further information about errors and warnings. Let’s begin by looking at how the code analyzer can be configured.
As with most things in Zend Studio for Eclipse, the default settings for the code analyzer work fine for most users and most tasks. However, when the need to change a configuration setting arises, not knowing how to make the change can be frustrating. To avoid future frustration, let’s look at the configuration window.
Select Window, Preferences; then find PHP in the Preferences tree, and click on the Code Analyzer branch. The window that you should see now is shown in Figure 7.1.
Each heading in this window gives a description of something that the code analyzer is monitoring with a drop-down that tells Zend Studio for Eclipse how to treat that case. You can choose to treat cases as errors, warnings, or ignore them completely. Some cases allow only the selection of warning or ignore.
What this feature allows you to do is change the feedback that is shown to you while developing on a granular scale. For example, by default, the use of a variable before it has been defined will generate a warning. However, you can set the severity of this particular situation so that it causes an error instead, or you may choose to ignore the warnings. For a complete list of configuration options, see Table 7.1. Default settings are in bold.
Table 7.1. Code Analyzer Configuration Options
Type of Error | Severity of Warning |
|---|---|
General | |
Fatal Error | Error | Warning | Ignore |
Warning | Error | Warning | Ignore |
Notice | Error | Warning | Ignore |
Core Error | Error | Warning | Ignore |
Core Warning | Error | Warning | Ignore |
Compile Error | Error | Warning | Ignore |
Compile Warning | Error | Warning | Ignore |
Strict Error | Error | Warning | Ignore |
Coding Style | |
Not enough arguments for define() | Warning | Ignore |
Use of variable before definition | Warning | Ignore |
Bug | |
Possibly problematic one-line comment | Warning | Ignore |
Assignment in condition | Warning | Ignore |
Result of print/echo used as Boolean | Warning | Ignore |
Object used as Boolean | Warning | Ignore |
If-if-else without block parentheses | Warning | Ignore |
First argument for define() is not a string | Warning | Ignore |
Break with variable | Warning | Ignore |
Wrong break depth | Warning | Ignore |
Variable name appears only once | Warning | Ignore |
Unused function parameter | Warning | Ignore |
Unused global declaration | Warning | Ignore |
Using $HTTP globals in functions without defining them as global | Warning | Ignore |
Value never used | Warning | Ignore |
Both empty return and return with value used in function | Warning | Ignore |
Function does not return a value but its return value is used | Warning | Ignore |
Returning by ref but not assigning by ref | Warning | Ignore |
Control reaches end of function but return value is used | Warning | Ignore |
Sprintf is missing arguments | Warning | Ignore |
Sprintf has more arguments than needed | Warning | Ignore |
Unreachable code | Warning | Ignore |
Variable used as object but has different type | Warning | Ignore |
Bad escape sequence: z, did you mean \z? | Warning | Ignore |
Condition without a body | Warning | Ignore |
Expression result never used | Warning | Ignore |
Security | |
Use of global variable before definition | Warning | Ignore |
Include() statement using variable | Warning | Ignore |
Performance | |
Passing var by reference but not modifying it | Warning | Ignore |
Deprecated Functionality | |
Use of deprecated call-time pass-by-reference | Warning | Ignore |
After configuring the code analyzer, click Apply and then OK. You can modify the settings at any time as you get comfortable with them or as the particular needs of your project change. If you ever mess things up so badly that you need to start over, you can use the Restore Defaults button to get back on track. Note that none of the changes take effect, including restoring the default settings, until you commit the changes by clicking Apply or OK, and clicking Yes on the confirmation window (see Figure 7.2).
The code analyzer uses visual cues to deliver useful information to users. Besides displaying errors and warnings in the Problems view, the code analyzer includes icons, in-code underlines, and colors that give information about the state of a file to the user at a glance. Zend Studio for Eclipse uses intuitive colors to represent the severity of warnings and errors—yellow and red, respectively. These colors apply to the underlines, icons, and a quick-glance information square at the top-right corner of the code editor. Hovering over this square gives you a summary of errors or warnings in a particular file. Recall from Chapter 5, “Views in the PHP Perspective,” that errors take precedence over warnings in terms of what is displayed to the user. If you have five warnings and a single error, only the error is displayed until it is fixed.
Along with in-code underlines to highlight errors and warnings, tool tips are available if you hover over an underlined section of code. The initial tool tip gives some general information on the error or warning. If you remain hovering over the error and press F2, a new window appears with a detailed description, explanation, and examples if they are available. These tips tend to contain more useful information for warnings because, while errors are more severe, they are often more straightforward to fix. Figure 7.3 shows a useful message as the result of a double warning: using a variable before it has been defined and using a variable path in an include function.
The information in the pop-up box explains that using a variable before it has been defined is a security risk, and using a variable as the basis for an included file can also be a security risk. It gives examples of ways that includes can be handled poorly, as well as ways that they should be handled safely. Using this feature should help to make your code more secure.
This chapter should give you a solid idea of tools available to you when you are analyzing code. Error checking is important because your code probably will not work if there is an error in it. The warnings in Zend Studio for Eclipse are equally as valuable because the explanations of warnings can help you write better, more secure code. The code analyzer is very configurable, and you can use all the options to customize your development environment so that you see only what you are interested in displayed in your code editor and Problems views.