Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #149833
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Coding style for small if statements |
| Date | 2020-02-07 23:36 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <87k14ym0lg.fsf@bsb.me.uk> (permalink) |
| References | (1 earlier) <65de5d07-838a-4a5f-bd70-b8a263fc61d6@googlegroups.com> <87imkkobdm.fsf@bsb.me.uk> <726b2209-ca7e-40fe-b429-fbc062f5b6bd@googlegroups.com> <874kw3nq6s.fsf@bsb.me.uk> <r1je7h$5fl$1@dont-email.me> |
David Brown <david.brown@hesbynett.no> writes:
> On 07/02/2020 02:26, Ben Bacarisse wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>>
>>> On Wednesday, February 5, 2020 at 5:36:14 PM UTC-6, Ben Bacarisse wrote:
>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>
>
>>
>> Mine are old-aged and I need strong reading glasses, but I can see the
>> else quite clearly. It's not easy to code for other people's eyes. I
>> don't think I've come across anyone saying the they need the else on a
>> line by itself in order to see it clearly.
>
> I put the braces on the same line as the "else":
>
> if (condition) {
> do_this();
> } else if (another_condition) {
> do_that();
> } else {
> do_something_different();
> }
>
> I don't see the need to put "else" on its own line entirely, but I would
> never have it later in a line. (Well, /almost/ never - rules shouldn't
> be /too/ rigid. But I would need an extremely good reason for breaking
> this one.)
We have these threads every now and then an though it's fun to see what
everyone else likes and dislikes, John Bode said that it was not clear
which if the else belonged to. I found that very surprising. Do you
think it's not clear which if the else belongs to?
The fact that he could not see then else came up (oddly) later. Did you
not see it?
>
>>
>>>> How could it not be clear which "if" the "else" is part of? Now I can
>>>> imagine some people who might not know (which is not quite the same
>>>> thing), but I really don't want such a person maintaining /any/ code.
>>>>
>>>> You hear a lot about the crisis in software (or you used to -- maybe
>>>> it's fixed now!). There's no hope, though, if software is being altered
>>>> by people who don't understand the original code as posted.
>>>>
>>>
>>> On an average day I'm helping support troubleshoot multiple issues,
>>> clearing at least one bug, writing up deployment tickets, going to
>>> meetings, and writing a new interface. On top of all that, my eyes
>>> are almost 55 years old and don't work so well anymore. If I have to
>>> spend more than a few seconds trying to parse out what you *meant*
>>> based on some dodgy formatting, I am going to kick it back to you and
>>> tell you to make it explicit.
>>
>> The boss is always right!
>>
>>>>> You won't introduce a bug if you decide to add a logging
>>>>> statement to either branch.
>>>>
>>>> That's not really what you mean. You mean it's easier to do so, or at
>>>> least less error prone in the face of people who just type code without
>>>> knowing what the language. (You can only add a statement to either
>>>> branch if you add {}s.)
>>>
>>> You can add statements to either branch without adding the {}s,
>>
>> We are just disagreeing about words. I don't think that's going to be
>> productive other than maybe highlighting how our words can be
>> misunderstood.
>>
>>> your code just won't
>>> work properly. Nothing's physically stopping you from writing
>>>
>>> if ( a )
>>> do_something();
>>> do_another_thing();
>>
>> This change (as I am sure you know) has not "added statements to either
>> branch". I just think you could be be clearer in your wording. We both
>> know what's happening in the code.
>
> And I am sure we all know that people /do/ make this kind of mistake.
>
>>
>>> It's just that if you're expecting do_another_thing() only to execute
>>> when a is true, then you're going to be bitterly disappointed.
>>>
>>> It happens. It's happened a *lot* over the last 30 years.
>>
>> This may be why there is such a crisis in software development. I can't
>> imagine anyone I've worked with doing this (i.e. just adding a line
>> thining it's goinf to be part of the "if"), but maybe I've just been
>> lucky. Maybe companies have no choice but to hire people to work on C
>> code who might just type that line above, thinking it's adding code to a
>> branch of the if.
>
> I am not sure that this is just about the type of people that are hired
> to write code. All programmers are human, and make mistakes on
> occasion. (As the saying goes, "To err is human - to really screw
> things up takes a computer.") It is common sense to code in a way that
> reduces the risk of mistakes or the consequences of mistakes - balanced
> with all other aspects of code readability, of course.
>
>>
>> What's more, you are suggesting that code errors of this sort frequently
>> survive long enough for someone like you to see them. Whilst C programs
>> can have subtle errors that go uncaught for some time, your people
>> should have a testing regime in place so that basic errors of logic get
>> caught immediately.
>
> Of course it is important to have good test regimes in place - noting
> again that everyone involved is human and tests are never perfect. In
> particular, testing can never prove the absence of bugs, but only prove
> their presence.
But in the case in point there is a bug! People do write silly things
like putting code next to branch of an if whilst forgetting to add the
{}s. But the result is code with a bug that will be found in the very
first test run. This is either a non-issue (as I hope it would be in
most production environments), or it signals that something else is
seriously wrong.
I get the feeling people like to come over all "you'd be fired if you
wrote code like that for me" sometimes. It's often overstating the
case.
> However, it is always cheaper to write the code without bugs than to
> find the bugs in testing. It is always cheaper to have bugs found
> during editing, compiling or static analysis than in testing, code
> reviews, or any other stage of the process.
Of course. And my editor would show up that bug immediately. So would
the compiler I use. So we must be talking about an environment where
the editor does not help, the compiler won't help and the tests are no
good. It's all getting a bit niche...
> Put the braces in, and the bug here cannot happen. That is a win in any
> development process.
There is a cost in making your staff follow the ladybird book of C style.
>>
>>> So I'm going to tell you to use
>>> braces everywhere all the time. There's one case where I *won't* kick back code
>>> that doesn't use braces for an "if" branch, but otherwise they need to be there.
>>>
>>>>
>>>>> It sacrifices some vertical space (and a little visual clutter), but
>>>>> nobody's going to come tracking you down later to ask what the hell
>>>>> you meant.
>>>>
>>>> It would be simpler to track down someone who knows C's syntax first.
>>>>
>>>
>>> Yeah, suppose the code was formatted as
>>>
>>> if ( a )
>>> if ( b )
>>> do_something();
>>> else
>>> do_something_else();
>>>
>>> What did I mean to do? Not "what does this syntax mean", but what was
>>> my *intent*? How would you tell?
>>
>> Why would I care? (I am being serious.) If the code is failing some
>> tests, I will look at what the code actually does whilst trying as hard
>> as possible to ignore what you might have meant. Nothing else matters.
>
> Nonsense.
>
> Good code is not "whatever crap happens to work in testing". Depending
> as always on budgets, time schedules, and "what the boss says", code is
> not good unless it is /clearly/ correct. It has to be correct according
> to appropriate standards - it should still be correct when there is a
> change in the compiler, or settings, or target, if it needs to be
> portable. It should fit the coding standards of the company or project.
> It should be maintainable, re-useable, and have appropriate
> documentation.
I don't think I said what you think I am saying -- possibly because you
cut what I said in two and answered each part separately, instead of
considering the combined point I was making.
> What you need beyond "it worked when I tried it" varies enormously from
> application to application. You hold the software in an aircraft to
> different standards from a "snake" game on a PC.
>
> But some things are so simple and low cost, but make such a difference
> to code quality, that they should not be in question. It is one thing
> to take short-cuts, or be lax about documentation (who isn't?) - sloppy
> coding like that example never has a home.
>>
>> If the code is passing all the tests, I'd probably leave it alone. If,
>> in the case of apparently correct code, I were to speculate on what you
>> meant, it would be both wise (and polite!) to assume you meant exactly
>> what the syntax says.
>>
>>> This isn't a syntax issue. This is a clarity issue. Using braces
>>> everywhere all the time makes your intent clear. Consistent
>>> formatting with clearly indicated scope boundaries makes your intent
>>> clear.
>>
>> Why do you care about the intent? What matters is what the code
>> actually does. (There is another kind of clarity that relates to
>> readability but that does not seem to be what you are stressing here.)
>>
>
> Again, I disagree.
>
> Code is correct when it does what the author intended. (It is, of
> course, important that the author intends the right thing - but that's a
> higher level issue in specifying the task.) If the author's intentions
> are not clear in the code, or apparently disagree with the working of
> the code, the code is wrong. The code is wrong even if it passes all
> the tests you try. (IMHO, of course.)
>
> In another discussion in another group, we have been looking at a
> function that has a very small chance of a race condition error that
> could only occur if a thread gets pre-empted within a sequence of three
> or four instructions that are run once every 49 days. The original code
> will pass all its tests - you'll never hit that bug in testing. But
> with enough systems delivered it might occur in practice. The code
> would test fine, but is still wrong.
This seems to have gone off on a tangent, and I can't see how it
addresses what I wrote.
--
Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-01-31 23:46 +0300
Re: Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-01-31 23:54 +0300
Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-01-31 19:13 -0600
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 07:52 -0800
Re: Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-02-01 00:06 +0300
Re: Coding style for small if statements mathog <dmathog@gmail.com> - 2020-02-28 10:20 -0800
Re: Coding style for small if statements Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-31 16:28 -0500
Re: Coding style for small if statements donalhambra@gmail.com - 2020-02-01 04:55 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-01 17:16 +0000
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-02 11:03 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-03 02:20 +0000
Re: Coding style for small if statements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-03 05:17 +0100
Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-03 04:07 -0800
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-03 12:59 -0800
Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-03 20:54 -0800
Re: Coding style for small if statements nobody@example.org (Scott) - 2020-02-01 16:44 +0000
Re: Coding style for small if statements already5chosen@yahoo.com - 2020-02-02 04:40 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-02 15:47 +0100
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 23:56 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:34 -0800
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 16:17 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:28 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 21:52 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:07 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:22 -0800
Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:25 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 02:35 +0000
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 20:20 -0800
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-05 01:04 -0500
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-05 01:05 -0500
Re: Coding style for small if statements John Bode <jfbode1029@gmail.com> - 2020-02-05 12:50 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:36 +0000
Re: Coding style for small if statements John Bode <jfbode1029@gmail.com> - 2020-02-06 15:01 -0800
Re: Coding style for small if statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-06 15:43 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-07 11:02 +0100
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 15:24 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 23:03 +0000
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 23:59 +0000
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-08 00:16 +0000
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-08 02:26 +0000
Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-02-08 17:07 -0600
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-08 23:17 +0000
Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-02-08 18:32 -0600
Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-09 09:32 -0800
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 07:10 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 01:26 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-07 11:30 +0100
Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-07 05:36 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 23:36 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-08 17:20 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 02:07 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 13:01 +0100
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 13:26 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 15:53 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 17:03 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 15:35 +0000
Re: Coding style for small if statements Manfred <noname@add.invalid> - 2020-02-09 18:07 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:17 +0000
Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-11 07:19 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Öö Tiib <ootiib@hot.ee> - 2020-02-10 23:40 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-12 12:24 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Bart <bc@freeuk.com> - 2020-02-11 11:30 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-02-11 09:41 -0700
Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-12 08:12 -0500
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-14 21:18 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 00:01 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-22 05:22 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:57 -0700
Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:28 -0700
Re: Pre- and post- conditions (was Re: Coding style for small if statements) jadill33@gmail.com - 2020-02-12 07:56 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) chad <cdalten@gmail.com> - 2020-02-12 08:57 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-14 21:31 +0000
Re: Pre- and post- conditions (was Re: Coding style for small if statements) jadill33@gmail.com - 2020-02-14 14:10 -0800
Re: Pre- and post- conditions (was Re: Coding style for small if statements) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-15 03:06 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 19:45 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:50 +0000
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 22:51 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 01:39 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 09:55 +0100
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-10 11:07 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 12:48 +0100
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-10 13:13 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 15:15 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 15:46 +0000
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-09 18:18 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 09:12 +0100
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 14:51 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 16:19 +0000
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 21:00 +0000
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:29 +0000
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-09 17:14 -0800
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:15 +0000
Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-09 18:43 -0500
Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 01:25 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 01:19 -0800
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:43 -0800
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-16 14:01 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:34 -0800
Re: Coding style for small if statements Guillaume <message@bottle.org> - 2020-02-07 15:25 +0100
Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-07 07:22 -0800
Re: Coding style for small if statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-02-14 15:21 +0300
Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-14 13:35 +0000
Re: Coding style for small if statements Guillaume <message@bottle.org> - 2020-02-14 14:43 +0100
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-15 12:08 +0100
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-20 10:10 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-20 19:58 +0100
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:55 -0800
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 15:26 +0000
Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-07 17:47 -0800
Re: Coding style for small if statements jadill33@gmail.com - 2020-02-10 07:09 -0800
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 06:30 -0800
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-16 16:14 +0100
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 16:40 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-16 17:48 +0100
Re: Coding style for small if statements Robert Wessel <robertwessel2@yahoo.com> - 2020-02-16 17:14 -0600
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-30 00:27 -0700
Re: Coding style for small if statements Ike Naar <ike@sdf.lonestar.org> - 2020-02-16 18:39 +0000
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 20:37 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-17 09:09 +0100
Re: Coding style for small if statements Öö Tiib <ootiib@hot.ee> - 2020-02-17 05:32 -0800
Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-17 18:07 +0000
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-17 23:48 +0000
Re: Coding style for small if statements Richard Damon <Richard@Damon-Family.org> - 2020-02-17 20:40 -0500
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-23 10:14 -0800
Re: Coding style for small if statements Ike Naar <ike@iceland.freeshell.org> - 2020-02-23 20:16 +0000
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-29 18:56 -0700
Re: Coding style for small if statements Ike Naar <ike@sdf.lonestar.org> - 2020-03-30 06:07 +0000
Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-30 06:45 +0000
Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-03-30 10:50 +0200
Re: Coding style for small if statements gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-30 13:04 +0000
Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-30 06:17 -0700
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 14:09 -0700
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-18 02:09 -0800
Re: Coding style for small if statements Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2020-02-10 01:47 +0000
Re: Coding style for small if statements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-12 17:54 +0100
Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-20 07:18 -0800
Re: Coding style for small if statements fir <profesor.fir@gmail.com> - 2020-02-29 03:30 -0800
csiph-web