>I don't quite agree, but anyway I don't care about the "local"
>comments, but just some document explaining the basic "architecture"
>of a piece of software (usually 1-2 lines saying where to start). I'm
>not free of guilt, though. I just try to describe what I see in real
>life.
What hobbist can
Hello,
2007/6/4, Eric Auer <[EMAIL PROTECTED]>:
>
> Hi Aitor,
>
> > I am afraid I disagree, Eric. We are just having badly or poorly
> > commented code BECAUSE we are creating Open Source. I believe it is
> > not as much the case for SMALL firms, but as for software written for
> > big firms, they
Hi Chris,
(please use plain text, not HTML, mail)
> Documentation should all done as a wiki. that way everyone
> can access/modify it and not be a mercy of the one. :-)
> Not sure if freedos.org has gone done that already...
Actually we have 2 Wiki pages, both linked from www.freedos.org :-)
H
>But of course it is always good to remember that we have to
>remind ourselves to write good code in open source. Because
>we are not paid for FreeDOS, there is no "quality control
>dept" either. On the other hand, there could be one - working
>with volunteers, just like our "software devel dept" :
Hi Aitor,
> I am afraid I disagree, Eric. We are just having badly or poorly
> commented code BECAUSE we are creating Open Source. I believe it is
> not as much the case for SMALL firms, but as for software written for
> big firms, they usually not only count, but also force you to write
> comple
Hello,
2007/5/30, Eric Auer <[EMAIL PROTECTED]>:
>
> Hi!
>
> "Why isn't good documentation the norm? Programmers aren't
> rewarded for it."
>
> I agree on the latter - I usually TAKE time to have reasonable
> comments in my code because it is open source (so others can
> reuse it or help improving
someone wrote:
> It is a discussion about code commenting covering why it should be done,
> how it should be done, and why it isn't done.
>
/* Comments are there to help whomever has to maintain the program. */
> I'm tired of the geek nonsense that all I need to do to understand
> how free defra
Hi!
> It is a discussion about code commenting covering why it should be
> done, how it should be done, and why it isn't done.
...
> It is always better to go from design to code instead of vice versa
> or just plain code.
> www.artima.com/forums/flat.jsp?forum=106&thread=4183&start=0&msRange=15
You havnt truly lived until you have tried to unravel obfuscated C. :-)
One thing I find really helpful is assert/reached macros in assembler that can
test/verify and halt the execution on fail condition (source filename/line
number),
allows for bugs to be keep at minimum.
Sonethimes I think
There is also a very nice IBM article about writing maintainable code here:
http://www.ibm.com/developerworks/linux/library/l-clear-code/?ca=dgr-FClnxw01linuxcodetips
-jh
On 5/30/07, someone <[EMAIL PROTECTED]> wrote:
> It is a discussion about code commenting covering why it should be done,
>
It is a discussion about code commenting covering why it should be done,
how it should be done, and why it isn't done.
I'm tired of the geek nonsense that all I need to do to understand
how free defrag is supposed to work is read the code. The code can
only show me what is implemented, not what's
11 matches
Mail list logo
