|
Posted by Curtis on 01/03/06 05:14
Lόpher Cypher <lupher.cypher@verizon.net> wrote in message
news:Srhuf.4838$tJ1.2178@trndny01...
> Curtis wrote:
> Well, one of the reasons could be the software one uses :)
I use, for
> instance, Zend Studio, and it automatically inserts the
braces in
> C-style :)
Understood. I've not tried any of the 'studio' stuff for PHP
yet.
I think the editor I've been using does that as well, but I
turned that option off. It does have a rather handy feature
in that if you highlight a brace, it highlights the
companion brace. Even using lined-up braces as I do, nested
code can get a bit confusing during the hack/development
cycle.
> It's just quicker :) I got a habit of using phpDoc blocks
> (also completed automatically on "/**" <enter>), and put
them before
> variables and functions, describing them, and regular
comments before
> the line:
>
> /**
> * Does some processing.
> *
> * @param int $var Some parameter.
> * @return bool Whatever
> */
> function foo($var) {
>
> # $var gets squared
> $var *= $var;
> ...
>
> # $var gets doubled
> $var *= 2;
> ...
> }
I suppose I could get used to that, but I find it less lucid
than my own approach. Enough so that I'm writing a
documentor for my own style--doubtless reinventing yet
another wheel.
I do use
#####################...
#
# variable stuff, etc.
#
#####################...
blocks at the head of all my code sections. I like those
brassy # signs because when I'm scrolling through code they
catch my eye better than the more anemic PHPdoc protocol,
which I tried and dropped for that reason.
Of course, an editor which parses all the code and has a
navigation panel for the functions might make that less
useful.
> Using comments on the side could sometimes be less
readable, especially
> when the line is long;
My view is that if the line's that long (over 50 characters)
it's probably getting hard to read, and should be broken up
into functional sections anyway. So far I've almost always
been able to do that. From that perspective, commenting only
in columns 50-80 enforces some discipline on stringy-looking
code.
That's true for nesting too deep as well. Even though I only
use a two space indent, nesting begins to shove the code
right pretty fast. The theory here is that if you're nesting
too deep, some of the noncritical code might be better moved
to functions anyway, so having the space from 50-80 reserved
for comments enforces some discipline here as well.
I was delighted when I discovered it was possible to break
up regex strings into lines--that stuff need piece-by-piece
commenting even more desperately than assembler code!
> also, if you have a comment spanning three lines
> and you need to insert something in-between, you'd have to
copy over the
> comment :)
True. One frequently has to insert lines in code, and moving
column 50-80 comments around can be a pain, even with drag
and drop. So I often save the exactly-50 tidying-up stuff
until the code section is likely in finished form.
I imagine this would drive some crazy, but a few minutes now
makes life much easier when someone looks at that code weeks
or months hence.
--
Curtis
Visit We the Thinking
www.wethethinking.com
An online magazine/forum
devoted to philosophical
thought.
Navigation:
[Reply to this message]
|