On Tue, Feb 22, 2011 at 19:03, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > Not a bad idea for HTML, not so great for PHP. Some of what you're > trying to solve/avoid can be handled by a decent editor, one that does > syntax highlighting and/or does brace and parenthesis checking. It > doesn't require an expensive IDE. I use Vim, and it works fine for this. > And honestly, if you're serious about programming, you really shouldn't > be using something like Notepad on Windows. Seriously. We had a coder > working for a company where I was who coded in Word of all things. We > just looked at him like he was crazy. > When I'm writing code in a language I know, I use either Vim, Kate, or Eclipse. But when I'm learning a language I use an environment with no syntax highlighting or code completion. It is in these cases that the close-then-fill coding style helps. Also, I've many times had to SSH into a server and change HTML or PHP code in the half-VIM that ships with CentOS and Debian, which does not support syntax highlighting. So the style has real-world advantages. > Annotating end-braces is also very helpful for long conditionals. Vim > can track start and stop braces, but when they span several screen > pages, it can be a problem. > Yup! > Likewise commenting code as you go is an excellent idea. 2:1 comments > are a bit much; Linus Torvalds would kick your butt. But I often do this > if I'm not exactly sure how I'm going to code something, but I know the > rough logic of it. Lay out the conditionals, comment on what should > happen within each code block, and then go back and fill in the blocks > with actual code. > 2:1 is excessive. I only comment where the code is not explicitly clear, or at the beginning of each code block of a long if / elseif / elseif chain. And I comment the close parenthesis to know what it closed. > It's also worth noting that sometimes code is hard to follow. And even > if you're going to be the only one updating it, you may well forget the > logic six months from now. Commenting allows you to recapture that logic > more easily. > Yup! > And then there's the PHP interpreter. If you make a syntax error, like > failing to add an closing brace, the interpreter will tell you so. If > you spend *enough* time coding, you can usually track down where your > mistakes are relatively easily. If you've ever coded in C, the same is > true for the C compiler. Its behavior is very very similar to that of > the PHP interpreter. It's something you get used to over time as you > code more and more. Also, what could be called "incremental coding" or > "stepwise development" helps: Code a little. Run/compile. Code a little, > run/compile. That way, errors are easier to catch than after you've > written 5000 lines in a file. > Sometimes I have to touch a live site, in fact _most_ of the work I do is for small accounts that don't have a test environment. I can often write a test page with a security-by-obscurity filename, but relying on the interpreter is a habit that I cannot afford. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
