Re: Which newsgroup for json parsing?

On 29/05/2024 18:23, David Brown wrote:

On 29/05/2024 18:14, Malcolm McLean wrote:

On 28/05/2024 12:45, Michael S wrote:

On Tue, 28 May 2024 12:33:02 +0200
Josef Möllers <josef@invalid.invalid> wrote:
>

On 27.05.24 22:18, Vir Campestris wrote:

On 27/05/2024 12:51, Josef Möllers wrote:

>
In my 40+ years of experience in IT/programming (I graduated 1981
from a Dutch polytechnic "HIO" in Computer Science and have
retired in 2022) I have learnt that "works fine" is only part of
the work. Maintainability should be added as well. Even if it is
code written for one's personal use only, it may need some work
later and then it's crucial to have it maintainable.
>
But maybe you think so too,

>
I agree completely.
>
I learned my lesson a a student with a personal project which I
left for 6 months. When I came back to it I had to comment it
before I could carry on.

>
You will never have enough comments, even when you consider this rule
;-)
>

>
Probably true.
And despite that you can very easily have too much (or too many?)
comments.
>

People have done some research and found that comments tend to make code harder to understand and maintain. Unfortunately as always I can only vaguely remeember reading this somewhere and can't provide any sort of reference.

 Too many comments make code hard to read - too much of a good thing is always bad.  (That's what "too much" means.)
 The key, IMHO, is not to use comments when the same thing can be expressed in code.  And don't use comments to repeat things that are obvious in the code.  If a variable needs a comment to say what it is, it's a sign that the variable should have a better name.  It's better to use an assert (static if possible) than to write a comment about the state of variables.  It's better to write clearer code than write comments about what the code is doing.
 Bad comments like those are a pain for maintenance - you often have to double up the effort when fixing things, because you need to change the code /and/ the comment.  In practice, comments often get out of sync and then they are worse than useless.
 Of course you want comments to talk about /why/ code is doing what it is doing, since that is usually not possible to express in the code itself.
 

Currently I'm writing a lot of little test programs to show off my XML parser. They are of course also intended to be used as templates for anybody who wants to use it. But I haven't decided on a commenting policy. The comments are inconsistent and a bit of a mess.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm