I prefer:

    y = (w == 5) ? true : false;

Vince.


On 05/07/2018 12:14 AM, Jack Purdum via Groups.Io wrote:

The brace thing is really a matter of choice. I learned C back in the
late 1970's when K&R was the only C book and I had a 64x16 modified TV
for a CRT, so I put things on the same line, simply so I could see more
lines without scrolling:

   if (w == 5) {
      y = true;
   } else {
      y = false;
   }

Even though the braces are not required with a single statement, I
almost always use them. When I don't, invariably I need to add another
statement or a debug print statement, so I have to add the brace anyway.
However, with function signatures, I always place the opening brace for
the function body on a new line. I think people pick what works for
them. No one style is "correct", so, to me at least, there's no reason
to even debate what's correct when it comes to braces. However, we
should all try to make our code as readable as possible.

When I was in high school, the football coach knew I was a ham radio
operator and wanted me to build two Heathkit walkie talkies. I built
them, and they didn't work. I was mortified. I barely slept that night.
The next morning, my Mom told me I got up in the middle of the night and
wrote something on the pad next to the phone. I read what I wrote, went
downstairs and checked it and, sure enough, that was the problem. Ever
since then, I keep a pad and pencil next to the bed. I can't tell you
how many teaching examples I've used that came from that pad or
programming problems that were solved by reading the pad the next
morning. My experiences have convinced me that your brain continues to
problem solve even when you're asleep.

Jack, W8TEE


On Sunday, May 6, 2018, 11:51:40 PM EDT, Jerry Gaffke via Groups.Io
<jgaffke@...> wrote:


You guys take this so seriously.
Maybe you should find a hobby.   ;-)

Though I understand, I'm afflicted by the same malady.
Just a slightly different strain.
Here's a fix, no need to ever again deal with my coding style (one of
many possible tools):
    http://uncrustify.sourceforge.net/

If you object to K&R style, there's a lot of it out there for you to sic
crustify on.
Here's a few million lines to get you started:
    https://github.com/torvalds/linux

You can also use Ctrl-T to format your code to a common C coding style.

I assume that's for the Arduino IDE, whose editor I mostly avoid.
Here's various tricks for vi/vim users:

  https://stackoverflow.com/questions/2355834/how-can-i-autoformat-indent-c-code-in-vim

Here's a discussion of the various indentation styles:

  https://softwareengineering.stackexchange.com/questions/99543/what-is-the-difference-between-kr-and-one-true-brace-style-1tbs-styles
They can't agree either.
But somebody in there did a study of error rates in code using the
various styles.
Note that K&R style won, at least by a little bit.
Though perhaps that's because folks using the K&R style
are more likely to have read K&R (highly recommended).

I was quite serious about that back pocket thing.
If I have a difficult algorithm to work on, I code it tight so I can see
as much of the work at one time as possible.  Preferably so it all fits
on one side of a sheet of typing paper.  Better yet, half of one side.
Then pull it out at odd times during the day, jot notes when new
insights come.
Works for me.

Didn't anybody have any comments about on how better to compute SWR?

Jerry, KE7ER


On Sun, May 6, 2018 at 05:31 pm, Jack Purdum wrote:

    Braces or brackets? Braces mark statement/function blocks while
    brackets are most often used with array sizes. The old K&R style was
    to leave the opening brace on the same line as the expression block,
    and then align the closing brace with the expression block start. I
    think that was done to get more lines on the screen when a 25 line
    display was common. Today, most seem to place the opening brace on
    its own line. If the block spans more than a page, the latest IDE
    shows the opening expression.

    You can also use Ctrl-T to format your code to a common C coding style.