On Tue, Feb 22, 2011 at 19:03, Paul M Foster <pa...@quillandmouse.com> 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.


> 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

> 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.


> 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


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to