Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Malcolm McLean Newsgroups: comp.lang.c Subject: Re: Which newsgroup for json parsing? Date: Wed, 29 May 2024 23:32:01 +0100 Organization: A noiseless patient Spider Lines: 65 Message-ID: References: <20240528144509.00002562@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 30 May 2024 00:32:02 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ac674fe904994916965e4fa9f12b3f15"; logging-data="1410825"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZlQr2aIa8a5SAozA7JOnYcQeTABQqs68=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:S8aHs1RCCkTfcFhRlhQNrajFaI0= Content-Language: en-GB In-Reply-To: Bytes: 4188 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 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