class A {
public function foo() {
for($i = 0; $i < 10; $i++) {
echo 'repeat '.$i;
}
}
}
Indenting (whether vi as above or open emacs style) is used to make code more readable. Recently though I had to point out another use to a coworker that I thought was obvious - temporary test code that you intend to delete later shouldn’t be indented. That makes it stick out like a sore thumb to be spotted and removed later…
class A {
public function foo() {
for($i = 0; $i < 10; $i++) {
if ($i == 5) { echo 'stop'; exit; }
echo 'repeat '.$i;
}
}
}
I thought the best way was to embed test/debug code IN your code, and test for a debug flag? (The overhead is likely minimal).
//Set debug flag status
$debug=true;
class A {
public function foo() {
for($i = 0; $i < 10; $i++) {
if ($debug) {
if ($i == 5) { echo 'stop'; exit; }
}
echo 'repeat '.$i;
}
}
}
That way you can turn debug on/off as needed.
Of course, the debug code could still be non-indented.
BTW, for this purpose it would be great to be able to insert a new line without indentation - for example, I couldn’t find a way to insert a new line without auto-indenting in Netbeans. So I recorded a simple macro consisting of two key presses: Enter and Home, and assigned it shift+control+Enter shortcut. This should work in most other IDE’s, too.
I’ve always used TODO comments that several IDEs support
// TODO: Remove this, its used for testing
Edit:
Some IDEs also support // HACK: that can be shown in a custom panel too
Then once I’m ready to checkin my changes, I check the project for TODO comments (through the TODO panel – both phpStorm and Visual Studio support this)
I’ve also used the technique @siteguru ; suggested, except I use a constant define(‘DEBUG’, true) and I have the constant disabled by default in Production. That way I can mimic the follow that exists in Visual Studio
There’s a few problems with this approach, firstly if the code is moved to a system where $debug is never set at all (to true or false) it will cause errors. Secondly, developers are lazy. They’ll leave in if ($debug) blocks and turn debug off… when the next developer comes along and adds a new $debug block, turns on debug mode… they may suddenly get behaviour that didn’t exist prior to turning debug on because it had been left in by a previous developer.
The same is true if you accidentally leave your unindented code in… Except you can’t turn it off on Prod as quickly as using a constant/variable to control it. Personally, I’d even go one step further and create an Environment variable so you can use $_ENV and have the ability to turn it off across the entire server. The issue is purely the fact that the test/debug code is being left in. The real question is, which method has less of an impact if that code made it to Production.
Unindenting it won’t necessarily prevent an accidental checkin, neither will TODO or HACK comments (even if you are always checking for them before checkin) as at some point you’ll get distracted and just check it in (happens to everyone). So every method has issues (to assume otherwise, is negligent).
In all reality, the best way to introduce debug/test code is DON’T DO IT. Use xDebug, set a breakpoint, profile it, don’t add random code that provides nothing to the codebase.
This tip is for very short term test code that you probably be deleting within the hour. For example, I was setting some $GLOBALS variables to trace my way through a recursive function to find out what was going wrong. I had no intention of making them a long term addition to the code. Since I had to place them in 9 spots in the file I wanted to be sure to be rid of them.
Indeed. I’ve seen this happen in large systems, which is a PITA.
@siteguru If you’re going to have a debug flag at least use setEnv to place it in the Apache Config file or htaccess file. This way you can’t accidently transfer the variables status between live and dev environments since, presumably, the two servers will use different server config files. For example
Mine was just a very rough-and-ready example to show a principle, not a proper implementation - a bit like the opening post really.
And not all development or production environments are Linux/Apache - some people use a Windows environment (at least for development), so no .htaccess or Apache configs. But I take what you say.
There are ways to set environment variables in IIS. They’re obscure and hard to work with, but they’re there. This is why Microsoft never made any real headway in the world of web servers - they’re product is crap and they can’t advertise their way out of the simple fact that IIS is a POS.
They’re not obscure or hard to deal with…they’re very easy, as a matter of fact. The only thing I thought that IIS sucks about is the URL rewrite doesn’t work OOTB.
This is why Microsoft never made any real headway in the world of web servers - they’re product is crap and they can’t advertise their way out of the simple fact that IIS is a POS.
Clearly you never used IIS6 or 7 and are just talking out of…the simple fact of the matter. IIS is not a POS. I’ve worked with both IIS and Apache regularly. Both are awesome web servers.
+1 from me. I use it a lot! setx is by far the easiest way (in my opinion) to set an environment variable.
Another +1 (though I’m not a huge fan of 6, now that 7 is available). In 7 they may leaps and bounds to let you control IIS from the command line, and I love that! I keep a batch script now with every project so if a server fails, I just ran the batch script on the new server and the virtual directories, app pools, sites, are all setup automatically. Just have to get the code there and its able to run.
Microsoft has made huge steps in the web server market over the past few releases, and I applaud them for their effort (it paid off).
I’ve been using unindented debugging code without actually thinking about it. Since it’s mostly echos and print_rs leaving it in stands out like a sore thumb so there is little danger of it being left behind. With non printing debugging code there is that danger.
IIS 4, released in 1998 for Windows NT 4.0. Over 15 years ago. Yeah…clearly IIS never had any updates during that time.
Now for the topic at hand. If you had a smarter workflow, using xDebug (or equivalent) and a smart editor that allows you to set breakpoints and step though the code, you wouldn’t need to throw debugging code into your code. Thus you never have the issue of leaving stray debugging code behind.
