Fixing C

#1

Post by rayascott » Tue, Apr 12, 2016, 8:31 AM UTC

Fixing C
embedded.com

Re: Fixing C

#2

Post by not-much-io » Tue, Apr 12, 2016, 9:26 AM UTC

Regarding the curly brackets thing vs. end statements and indentation:

How is this a problem with editors/IDEs doing it all for you? If your editor/IDE does not do this, then.. why don't you have this in your setup?

Re: Fixing C

#3

Post by mschuster91 » Tue, Apr 12, 2016, 9:33 AM UTC

not-much-io wrote: post #2

Regarding the curly brackets thing vs. end statements and indentation: How is this a problem with editors/IDEs doing it all for you? If your editor/IDE does not do this, then.. why don't you have this in your setup?

You can do auto-indent in Java, PHP, Perl... but not in C/C++, where you're free to embed curly braces etc. in macros, and it's really common to do so.

To make matters worse, you actually need to compile the program in order to determine which macro gets expanded into what amount of braces...

Re: Fixing C

#4

Post by recentdarkness » Tue, Apr 12, 2016, 9:40 AM UTC

I might be missing something, but what is that 'begin' for? That looks useless to me

Re: Fixing C

#5

Post by 0x0dea » Tue, Apr 12, 2016, 9:41 AM UTC

mschuster91 wrote: post #3

not-much-io wrote: post #2

Regarding the curly brackets thing vs. end statements and indentation: How is this a problem with editors/IDEs doing it all for you? If your editor/IDE does not do this, then.. why don't you have this in your setup?

You can do auto-indent in Java, PHP, Perl... but not in C/C++, where you're free to embed curly braces etc. in macros, and it's really common to do so. To make matters worse, you actually need to compile the program in order to determine which macro gets expanded into what amount of braces...

Vim auto-indents macro blocks just fine, and preprocessing isn't compilation. For your edification, clang-format is amazing: https://youtu.be/JSjoCisIHcM?t=1764

Re: Fixing C

#6

Post by opk » Tue, Apr 12, 2016, 9:43 AM UTC

I'd make const the default, requiring a var keyword for variables. This makes it easier to get const correctness right because a missing var would break compilation while currently, a missing const doesn't. Next on my list would be := for assignment which is less easy to confuse with equality followed by variable declarations being name: type which is better once type names get long - admittedly they never are in plain C.

Re: Fixing C

#7

Post by rootlocus » Tue, Apr 12, 2016, 9:49 AM UTC

Removing curly braces? I have to paraphrase Torvalds on this:

  > The answer to that is that if you need
  > more than 3 levels of indentation, you're screwed anyway, 
  > and should fix your program.

Breaking the code into manageable chunks is a huge part in writing clear, maintainable software. A high amount of curly braces implies deep nested loops and/or branches, which also implies a high complexity (measured by cyclomatic complexity).

Also, IDEs can auto insert braces and indent the code. Unless you're using notepad, I don't see the problem.

Re: Fixing C

#8

Post by tronje » Tue, Apr 12, 2016, 9:49 AM UTC

C, to me, requires a lot of discipline about good coding style and conventions. I personally like that a lot, even though, of course, it sometimes causes one to shoot oneself in the foot. But, and I can't point to exactly why, I don't think I want to change anything.

Maybe Rust or something new will come along sometime soon to fix all the issues that exist with C.

Oh, and for those who haven't seen it, there was a cool guide to writing neat, modern C on here a few months ago. https://matt.sh/howto-c

Worth a read in my opinion.

Re: Fixing C

#9

Post by Starsgen » Tue, Apr 12, 2016, 10:00 AM UTC

I dealt with this by adding a comment to the closing curly like so: } // end of functionName

Re: Fixing C

#10

Post by lake99 » Tue, Apr 12, 2016, 10:00 AM UTC

Oh god! This brings back memories of the nightmarish legacy code that I had to work on, a long time ago. The previous developer apparently liked Pascal and hated C. His principal header file had something like

    #define begin {
    #define end   }

and many other Pascalisms. As a result, his code did not look like C at all. IIRC, the code had gone unmaintained since the late 80's, which is not surprising in embedded systems. The code I had to fix was truly cringe-worthy.

I vehemently disagree with Ganssle's article. Curly braces are the way to go. I am quite comfortable with pythonic indentation now, but remove one 'if' in complex code, and we have to change all the code below it manually. Cut-paste some code, and we have to manually take care of indentations. It's a pain.

Instead of his proposal, I'd want cleaner syntax for bit-wise addressing, which is currently handled via cumbersome unions or mask macros.