Tips for writing clean code?

General discussion on Zend Studio
Post Reply
jhsachs
Posts: 40
Joined: Mon Dec 07, 2009 7:38 pm

Tips for writing clean code?

Post by jhsachs » Sat May 01, 2010 9:07 pm

I'm using Zend Studio 5, but I think this question will apply to any version.

I love using the Code Analyzer, but it constantly gives me warnings about things that aren't really problems. I'm looking for advice on how to adjust my coding style to make the code cleaner.

One problem is the warning “Expression result is never used,” for a function call whose return value is not assigned to a variable. This usually happens with a function that doesn't have a return value. Failing to use the result is not a problem -- using it would be!

Another problem is an expression like this:

Code: Select all

$x = $_POST[point];
which gives the run-time (not Code Analyzer) error, "Use of undefined constant point - assumed 'point'."

This can and should be fixed by expressly making the subscript a literal string, but what to do when it's used in a string?

Code: Select all


$x = "The value is $_POST[point] this time.";
If I use a literal string there, I get a syntax error. If I don't, I get a run-time warning. I could assign the array element's value to a scalar variable and use that, but is there a more direct way around the problem?

totalsupport
Posts: 123
Joined: Thu Aug 20, 2009 2:38 pm

Re: Tips for writing clean code?

Post by totalsupport » Mon May 03, 2010 10:02 am

Code: Select all

$x = $_POST[point];
Is not what you're going for. Unfortunately PHP 'translates' your 'error' into

Code: Select all

$x = $_POST['point'];
which is probably what you meant, and gives you a notice.

Code: Select all

$x = "The value is $_POST[point] this time.";
Is bad too. Never ever put request (post/get/cookie) values directly into other variables/code without checking it.
(The syntax tedtiger gave you is correct though)

Hey, you named the topic "Tips for writing clean code?" so here you go ;)

Could you give an example where "Expression result is never used" is shown? Because

Code: Select all

<?php
function doThis() { echo 'hello'; return true; }
doThis();
?>
shouldn't give that warning.

However,

Code: Select all

<?php
function doThis() { echo 'hello'; }
$result = doThis();
?>
should give you that warning since $result is never used. This is regardless of what doThis() actually returns (it's not always possible for the analyzer to detect if/what a function returns, although it generally does a pretty good job).

rhsoftware
Posts: 88
Joined: Thu Jun 04, 2009 11:31 am

Re: Tips for writing clean code?

Post by rhsoftware » Sat May 08, 2010 10:13 am

jhsachs wrote:

Code: Select all

$x = $_POST[point];
which gives the run-time (not Code Analyzer) error, "Use of undefined constant point - assumed 'point'."

This can and should be fixed by expressly making the subscript a literal string, but what to do when it's used in a string?
You should use error_reporting E_ALL on development machines because
php would give you a warning himself since nearly ten years

I am working on all machines including production with the following settings,
production-machines have display_errors = 0 so they log only. If our applications
running in debug-configuration the make ini_set('display_errors', 1)

Code: Select all

error_reporting = E_ALL | E_STRICT
display_errors  = 1
display_startup_errors  = 1
log_errors  = 1
error_prepend_string  = "<div style='background-color:yellow;color:red;padding:3px;font-family:verdana;font-size:10px;'>"
error_append_string  = "</div>"

Code: Select all

$x = "The value is $_POST[point] this time.";
If I use a literal string there, I get a syntax error. If I don't, I get a run-time warning. I could assign the array element's value to a scalar variable and use that, but is there a more direct way around the problem?
This is generally bad style because in many cases and editors variables are not shown in their color

Code: Select all

$x = "The value is "  . $_POST['point'] . " this time.";

jhsachs
Posts: 40
Joined: Mon Dec 07, 2009 7:38 pm

Re: Tips for writing clean code?

Post by jhsachs » Fri Nov 12, 2010 4:05 pm

I'm sorry it's taken me so long to respond. The site never notified me that my question had responses. Later I noticed it wasn't notifying me consistently and I started checking my posts, but by then this message has scrolled off the first page of the forum, and I never thought about it.

tedtiger wrote, "No Problem. Just wrong coding style."

Thank you. That's exactly what I was looking for.


totalsupport asked, "Could you give an example where "Expression result is never used" is shown?"

Not any more, I'm afraid. I fiddled with my code to evade the problem, and I no longer remember where it occurred or what I changed. I'll return to this thread if it comes up again.


rhsoftware wrote, "This is generally bad style because in many cases and editors variables are not shown in their color..."

I disagree. I'm using Zend Studio, which color codes them correctly, but apart from that, I think color coding is a minor consideration. It's outweighed by the fact that the embedded array element is easier to code without syntax errors, and more legible. Legibility completely dominates my choices about formatting strings with embedded expressions, and for my needs, that's as it should be.

mmmshuddup
Posts: 28
Joined: Fri Oct 22, 2010 6:44 am

Re: Tips for writing clean code?

Post by mmmshuddup » Sat Nov 13, 2010 2:17 am

Code: Select all

function doThis($bar = array('foo' => 'bar'))
{
    $foo = (isset($_POST['foo']))
        ? $_POST['foo']
        : $bar;

    if (is_array($foo)) {
        foreach ($foo as $index => $value) {
            // @todo: write code here
        }
        return implode(' => ', $foo);
    }
    
    return "The value of foo is: {$foo}";
}

$foo = doThis();
echo $foo;
That is proper code formatting based on Zend Standards. PEAR Standards are great as well as I personally use a cross between the two. That above example besides the fact that it doesn't make sense, of course, is for defining functions in a procedural environment. When in an OOP env you must always declare access control modifyers (public/private/protected and in some cases final/static) for your functions. You can find both Zend and PEAR standards online with a quick google search.

jhsachs
Posts: 40
Joined: Mon Dec 07, 2009 7:38 pm

Re: Tips for writing clean code?

Post by jhsachs » Thu Nov 18, 2010 6:21 pm

mmmshuddup, that's interesting. I've never paid careful attention to standards for code formatting; in fact, I didn't realize there were any except for the "standards" that prettyprinters impose.

However, my original question was more about content than form: for example, how to insert an array element into a string so that the programmer's intention is most likely to be realized the first time, and is most likely to be clear to a reader.

Post Reply