Posted by L�pher Cypher on 01/03/06 16:21

Curtis wrote:
> 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.
>

Well, I tend to use the "above" comments where I have to describe what a
few next lines of code do and the "to-the-right" comments to comment
single line :) As for phpDoc, it is useful if you develop a library of
some sort - you can then create documentation very easily :)
True for breaking up statements into several lines and refacturing some,
but if you use descriptive names, they could get very long :) Say,

if (get_class($this->fTemlatePageController) != "TemplatePageController") {
...
}

:)


--

- lüpher
---------------------------------------------
"Man sieht nur das, was man weiß" (Goethe)

[Back to original message]