Firstly I add define('WP_DEBUG', false);
to the wp-config.php file (as most people have said) to my local install which is a recent copy of a relevant production site (both files and data). This makes stuff quick, safe, separate but reflects well at least one place the plugin will actually be used.
I also add the Debug Bar plugin together with some of the some of the Debug Bar add-ons (Transients for example) - as appropriate to your plugins.
I also use the Firebug add-on for Firefox which is excellent for helping track down html, css and JavaScript issues also well for looking into layout weirdness.
I code using UltraEdit which I have used for 15+ years for a whole bunch of coding (php through to SQL) both at work and home and so this works well for me but maybe doesn't have enough I to rate as an IDE for many folks. It has syntax highlighting, automatic completion and code layout features and a bunch of html and css shortcut tools which can help avoid typos and alike. Mostly this bring familiarity to me which is an important aspect often overlooked in the rush to the new. Muscle memory aids repeatability even in coding.
And of course I usually have some appropriate page from the codex open in another tab on a suitable exemplar.
These all help in different ways to highlight coding, parsing, functional and layout errors and do not interfere much in how I code or if nothing is amiss. Most can be ignored or deactivated for a bit if you're experimenting or working around something you'll revisit later.
Oh, and there's nothing wrong with a well positioned echo or print_r to check something at a key (so long as you remove them when you are done).
WP_DEBUG
to false, as John recommends, then you get a pretty good idea of what's going wrong, if anything, within your scripts. Then you can edit in Dreamweaver, hit Ctrl+S and then F5 in the browser to immediately view the changes.