![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 19 Apr 2011 22:18:49 +0100, Orchid XP v8 wrote:
> On 19/04/2011 10:11 PM, Jim Henderson wrote:
>> On Tue, 19 Apr 2011 21:31:20 +0100, Orchid XP v8 wrote:
>>
>>> I remember reading about a memory of library stuff who saw somebody
>>> using Telnet. She screamed "OH MY GOD, YOU'RE HACKING OUR
>>> COMPUTERS!!!" and turned the computer off at the wall. The guy tried
>>> to explain what he was actually doing, but she wouldn't have it.
>>>
>>> Apparently there are a lot of stupid people...
>>
>> There are a lot of uneducated people, certainly.
>
> Being uneducated is one thing. Assuming that you know what you're
> talking about when you don't is another.
That's a fair point - and something everyone should keep in mind when
making unsupportable declarations. ;)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 19 Apr 2011 22:19:16 +0100, Orchid XP v8 wrote:
>>> Man, I hope the ratings are *awesome*! :-D
>>
>> You bet, but you need to do better with the product placement. :)
>
> OMG, you guys know where I place my products?! o_O
LOL
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 19 Apr 2011 14:31:42 -0700, Darren New wrote:
> On 4/19/2011 14:07, Jim Henderson wrote:
>> I don't see that that matters - they document that it's informational
>> and nothing to worry about.
>
>
> *And* they tell you what it means, so it's trivial to confirm that it's
> nothing to worry about.
Yep.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le 2011/04/19 11:46, Darren New a écrit :
> On 4/19/2011 2:45, Invisible wrote:
>> I don't personally know of anybody who actually sent a cheque
>
> AFAIK, I'm the only person in the entire world that ever paid for WinZip.
>
I did pay for PK Zip, then found free alternatives that both zipped
beter (faster and beter compression), and supported many formats beside ZIP.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 4/19/2011 15:21, Jim Henderson wrote:
> Sure, but that's different than poor end-user documentation, that's what
> I'm saying.
Sure. It's two different problems, and they're both problems.
> Most OSS projects rely on code as the internal documentation.
Code is not documentation. Anyone who thinks that code *is* documentation on
any project you feel the need to split into multiple files is fooling
themselves.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 19 Apr 2011 16:48:35 -0700, Darren New wrote:
>> Most OSS projects rely on code as the internal documentation.
>
> Code is not documentation. Anyone who thinks that code *is*
> documentation on any project you feel the need to split into multiple
> files is fooling themselves.
Of course, that was pretty much what I said in the next sentence after
what you quoted.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 4/19/2011 17:06, Jim Henderson wrote:
> On Tue, 19 Apr 2011 16:48:35 -0700, Darren New wrote:
>
>>> Most OSS projects rely on code as the internal documentation.
>>
>> Code is not documentation. Anyone who thinks that code *is*
>> documentation on any project you feel the need to split into multiple
>> files is fooling themselves.
>
> Of course, that was pretty much what I said in the next sentence after
> what you quoted.
Even if everyone uses the same style, code isn't documentation. Even if only
one person works on the code ever, code isn't documentation. Code is no more
documentation than the steering wheel is your turn signals.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 19 Apr 2011 17:10:44 -0700, Darren New wrote:
> On 4/19/2011 17:06, Jim Henderson wrote:
>> On Tue, 19 Apr 2011 16:48:35 -0700, Darren New wrote:
>>
>>>> Most OSS projects rely on code as the internal documentation.
>>>
>>> Code is not documentation. Anyone who thinks that code *is*
>>> documentation on any project you feel the need to split into multiple
>>> files is fooling themselves.
>>
>> Of course, that was pretty much what I said in the next sentence after
>> what you quoted.
>
> Even if everyone uses the same style, code isn't documentation. Even if
> only one person works on the code ever, code isn't documentation. Code
> is no more documentation than the steering wheel is your turn signals.
Code in and of itself doesn't include why, but one could argue (though
I'd have to admit that it would be pointless to argue it with you or any
other professional coder <g>) that that's what comments are for. ;)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 4/19/2011 19:01, Jim Henderson wrote:
> that that's what comments are for. ;)
Comments help with localized pieces of code. If I hand you something like
Apache or Outlook or the Linux kernel, in-line comments are not going to
tell you what order to read code in to learn how it works. Especially if
fixing some specific bug is your first task. Sure, someone can show you
*this* piece of code parses configuration files and *that* piece of code
handles authentication, but that's a person showing you that, or hours
wandering around looking for an anchor. And that's even assuming the code is
well structured to start with.
And once it grows, you're just screwed. I mean, really, something like the
Linux kernel is really a fairly small system compared to some of the big
systems out there. (There it is. Linux is 14 million lines of code. AT&T
TURKS is 100 million lines of *SQL*, let alone all the systems that use it.)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 19 Apr 2011 20:45:29 -0700, Darren New wrote:
> On 4/19/2011 19:01, Jim Henderson wrote:
>> that that's what comments are for. ;)
>
> Comments help with localized pieces of code. If I hand you something
> like Apache or Outlook or the Linux kernel, in-line comments are not
> going to tell you what order to read code in to learn how it works.
> Especially if fixing some specific bug is your first task. Sure, someone
> can show you *this* piece of code parses configuration files and *that*
> piece of code handles authentication, but that's a person showing you
> that, or hours wandering around looking for an anchor. And that's even
> assuming the code is well structured to start with.
Well, yes, I do know what you mean. Even with proper code analysis
tools, it can be difficult to read code.
It's far easier if, for instance, you're using a tool like Source
Navigator (which I really like for this type of thing) you are looking to
analyze a bug. Having an error code and a call stack makes it far easier
to use a tool like that than to say "I wonder how it does 'x'" and then
work through the logic. It's possible, but it can take quite a while.
Proper documentation includes design documents and the like - and that
certainly goes a lot further than code alone.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |