Syntax Error Smell

When you compile your program and there is a syntax error, this is the compiler telling you to take smaller steps.

For instance, if you are removing the global variable 'foo' you might be tempted to delete foo's declaration, and then use the compiler to find the places where it is used.

Instead, do the same steps in reverse order. First fix the places where foo is used. Then delete foo's declaration. This way yields no syntax errors.

Syntax errors are a negative energy and should be avoided. Every time you compile, there should be no syntax errors.

Do Zen Master programmers not program this way?

I think this might be completely wrong. Maybe it's better to just make your change and then press "run unit tests" and fixing any errors until your unit tests pass.

It's not necessarily a good idea, because you might accidentally leave a frob in the code that you should have deleted. A Tao or Zen programmer would probably delete the variable and then fix any problems. Act then react.

I disagree. If you are using a compiled language, the compiler is one of your tools, so use it to your advantage. A textual search of the source code may not be easy within your language/IDE, but the compiler will find every reference to foo and notify you.

Now, there are versions of compilers that will drown you in irrelevant messages when one error throws them off the parsing, but that's an issue for compiler choice.

I agree with this disagreement - the compiler is your friend. Syntax errors don't hurt anybody! When you delete (or rename, or retype, etc.) a global variable (hey, why are you using global variables in the first place?!) (okay, let's say ANY variable, member, function, method, etc.)... Okay, let's start over: When you *modify* any *element* of your code, and the compiler gives you an error, you are engaging in a dialog with your tool: "I decided to change this Foo to Fee." "Yeah, but its still called Foo over here, and here..." or "Wait, that's not consistent with how it is used over here..."

In general, the earlier you get a feedback on an error, the better. Compile time is better than link time, which is better than run time. Even better are some fancy pop-up features on newer IDEs that look up the legal signatures on methods as you type. I sometimes find these rather annoying, but there is something to be said for having my tool warn me even before compilation that I've made a typo, or forgotten the signature of a method...

Now a broader/different version of SyntaxErrorSmell that I've run into sometimes is when I'm trying to code something I've only half thought out, like a cast or friendship or something, and I keep bumping into syntax errors. After a half dozen times, I back up a step and think about whether there isn't some reason why I shouldn't be trying to do what I'm trying to do...

You say you agree but you really don't. Why not use global variables? It's all the same thing.

Search and replace is still necessary unless you want to build every configuration yourself. This is typically impractical.

When coding in C++, I tend to use the compiler as a glorified search and replace tool (at least for the first pass through to pick up all the obvious things effected by a change). I've been known to set up keyboard macros that go the next error and automatically fix the error for me. In emacs (at least) I can fix the errors while it is compiling - each one needs a bit of manual looking at and sometimes I'll know I can do a search/replace on the entire file. One problem with this is that it won't pick up code that doesn't get compiled (it may be commented out or #ifdef'd away) so I'll usually end up doing a grep over all the code afterwards - but by that point most of the simple cases are removed so I'll have less to manually check.

Syntax errors can be a good indicator of the scope of a change. Don't like having that method handling that exception? Throw it, recompile, and see how many "untrapped exception" errors come up. If it's a lot, maybe a more modest refactoring is in order....

(This assumes you can recompile all the code that uses this method, of course. That may be a problem in large projects, or frameworks with external users.)