Too many programming languages?

[Cerebus]

We use Chisel for pretty much everything.

Pah! Only using 1/3 of your toolkit? Don't forget there's "screwdriver" and "4lb club hammer". 

[SiliconWizard]

Code: [Select]

i = 10;
while(i); {
   printf("%d",i);
    i--;
}

SafeC checkers have the rule ")" must be followed by a block {}.
Hence the above line ");" is detected as mistake.

GCC (9.2.0 here) has no problem flagging this as suspect (at least with -Wall):

warning: this 'while' clause does not guard... [-Wmisleading-indentation]
   47 |  while(i); {
      |  ^~~~~
Case_Var.c:47:12: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'while'
   47 |  while(i); {

Although GCC doesn't issue a warning for the following, some other static analysis tools will: as it is, 'while (i);' is additionally an infinite loop, as the condition will always be true.
(For instance, CppCheck gives: "style: Condition 'i' is always true".)

[legacy]

some other static analysis tools will

Which ones? Stood? Understand? Lint? yes, they do.
But, technically I see it as a defect of the standard C grammar.

"while | if () statement" is always a potential mistake
hence it should always be "while | if { block }"

[GeorgeOfTheJungle]

"while | if () statement" is always a potential mistake
hence it should always be "while | if { block }"

No Sir, there's nothing wrong in

Code: [Select]

while (condition) ; it has always been and still is widely used everywhere.

How or why is

Code: [Select]

while (condition) { ; } any better?

[SiliconWizard]

How or why is

Code: [Select]

while (condition) { ; } any better?

You don't need the ';' in there.

As to whether it's better, it can be a topic for infinite debate. I don't know about "better" per se, but it would make the language more consistent. As an example, the two constructs: individual statements and code blocks where also both allowed, AFAIR, in Pascal with the 'IF' construct. Wirth's later refined languages got rid of this out of consistency (and a simpler grammar!).

I personally don't have a problem with this in C, but I can understand the point about it not being completely consistent, or just that it could be simplified.
But I also don't buy into the associated potential issues due to mistyping. Any kind of mistyping can lead to catastrophic bugs. You added a ';' where it didn't belong? Yeah? You could also have typed 'i+2' where 'i+1' was meant.

Additionally, some basic coding styles considerably lower the possibilty of the above happening. I make it a rule NEVER to put an 'if' ('while', ...) body on the same line. Thus:

Code: [Select]

if (i == 0) i++; NOPE. This:

Code: [Select]

if (i == 0)
    i++; is OK.

If anything, the above example with 'while (i); {' is WAY easier to spot (both by humans and automated tools) than the infinite possibilities of mistyping, so "fixing" this would be as easy as it would be a bit pointless all in all.

Now if you want a more consistent language with a simpler grammar, use something else. But choose wisely, because mistakes are easy to make in just any of them.

[Cerebus]

some other static analysis tools will

Which ones? Stood? Understand? Lint? yes, they do.
But, technically I see it as a defect of the standard C grammar.

"while | if () statement" is always a potential mistake
hence it should always be "while | if { block }"

C by and large follows Algol-60 syntax, with a sprinkling of influence from FORTRAN, with the occasional nod to some Algol-68 features (for instance the C "-=" operator borrows from the Algol-68 "-:=" operator). We'd be a lot better off if they had followed (and hence popularised) the Algol-68 way of doing things, which would have been

Code: [Select]

WHILE <serial clause delivering BOOL> DO <serial clause> OD
IF <serial clause delivering BOOL> THEN <serial clause> [ ELSE <serial clause> ] FI

And the offending example would have looked like this:

Code: [Select]

i := 10;
WHILE i != 0
DO
    printf ("%d", i);
    i -:= 1
OD
and a semicolon after the conditional phrase would have been flagged as a syntax error. Notice that the semicolon is a statement separator in Algol-68, not a statement terminator as in C.

FWIW, the idiomatic Algol-68 would not use the separate variable and auto-decrement and would have looked like this:

Code: [Select]

FOR i FROM 10 DOWNTO 1
DO
    printf ("%d", i)
OD

Edited to add: I forgot to say that the legitimate 'no op' statement (which is what gets us into trouble with the C 'while (x) ;" above) which has to be awkwardly leveraged into an empty statement in C was an explicit 'SKIP' operator in Algol-68. Heck, even python has 'pass'.

[legacy]

Code: [Select]

while (condition) { ; } any better?

Yes, it's better. There is also a rule to avoid empty statements.

[Cerebus]

Code: [Select]

while (condition) { ; } any better?

Yes, it's better. There is also a rule to avoid empty statements.

It's better, but better still would be the rather more explicit:

Code: [Select]

while (condition) {  /* deliberate no op */; }


[GeorgeOfTheJungle]

Code: [Select]

while (condition) { ; } any better?

Yes, it's better. There is also a rule to avoid empty statements.

It's better, but better still would be the rather more explicit:

Code: [Select]

while (condition) {  /* deliberate no op */; }


It's better because... what?

[Cerebus]

Code: [Select]

while (condition) { ; } any better?

Yes, it's better. There is also a rule to avoid empty statements.

It's better, but better still would be the rather more explicit:

Code: [Select]

while (condition) {  /* deliberate no op */; }


It's better because... what?

  It's better because it draws attention to the fact that an obscure 'feature', spot-able only by a semicolon being in an odd place, has been used - so that the poor sod who comes after you has a chance to spot what you're doing, that you're deliberately doing it, and that it's not a mistake.

[Nusa]

And just for more fun with loops:

Code: [Select]

  do;
  while (condition);


[tggzzz]

How about this (rather trivial) makefile not working as expected because of the error in the second line

Code: [Select]

clean:
rm -f blah.o blah.c blah
What's the error?



...








A Makefile consists of a set of rules. A rule generally looks like this:
targets : prerequisities
   command
   command
   command

    The targets are file names, seperated by spaces. Typically, there is only one per rule.
    The commands are a series of steps typically used to make the target(s). These need to start with a tab character, not spaces.
    The prerequisites are also file names, seperated by spaces. These files need to exist before the commands for the target are run.

[GeorgeOfTheJungle]

It's better because it draws attention to the fact that an obscure 'feature', spot-able only by a semicolon being in an odd place, has been used - so that the poor sod who comes after you has a chance to spot what you're doing, that you're deliberately doing it, and that it's not a mistake.

There's nothing obscure in while (condition) ; IMO any poor sod that can't understand that, shouldn't be programming. And, what makes you believe that she would understand while (condition) { } but not while (condition) ; ? Is she going to believe every line she sees and doesn't understand is a mistake or what?

What about

Code: [Select]

while (condition) this(), that();
while (condition) this() && that();
Look ma, no braces! 

Linus says that lesser programmers can't understand the C he writes... I am not saying that obfuscated C is better, but I'm against the minimum common denominator just because there's dumb people out there. That while() we're talking about isn't rocket science!

[Cerebus]

Look ma, no braces! 

It's not about the braces, it's about drawing attention to the empty statement before the semicolon. Relying on an invisible empty statement is dangerous, drawing attention to your intent in using it seems only wise. If one wants to feel artificially smarter than other people, then by all means use 'clever' code, especially code that leverages the weak features of a language, but if one's intent is to produce maintainable code that other people can quickly and clearly understand then something else is called for.

Personally I'd rather be know for producing code that works and is easy for other people to maintain rather than for 'clever' code that falls to pieces as soon as someone less experienced, or less attentive, than me gets their hands on it.

[Cerebus]

How about this (rather trivial) makefile not working as expected because of the error in the second line

Code: [Select]

clean:
rm -f blah.o blah.c blah
What's the error?

Obvious to anyone that has used make for more than, ooh 15 minutes? And that's even without scrolling down. I always have "Show Invisible Characters" turned on in my editor(s) when editing makefiles (or, for that matter, when working in python).

[hamster_nz]

while (condition) this(), that();
while (condition) this() && that();[/code]

Look ma, no braces! 

All good and well, until this() returns -1 on error and 0 on success, breaking my "do this() and if that succeeds then do that()" internal dialogue on reading this code.

Looking at pretty much any stdlib function which returns a pure status code:

Code: [Select]

RETURN VALUE
       On success, zero is returned.  On error, -1 is returned, and errno is
       set appropriately.

And if you can't use the pattern against the stdlib then it isn't a good pattern.

I still think that the goal isn't to write the most concise code, but the most descriptive and least ambiguous code (to humans). That is why some people think I am silly for putting "if(somepointer != NULL) ..." rather than "if(!somepointer) ..." - those people aren't the people I am leaving the hints for.

"{ }" is much better than ";" in my book, as I try to not lay landmines for the future readers.

[tggzzz]

How about this (rather trivial) makefile not working as expected because of the error in the second line

Code: [Select]

clean:
rm -f blah.o blah.c blah
What's the error?

Obvious to anyone that has used make for more than, ooh 15 minutes? And that's even without scrolling down. I always have "Show Invisible Characters" turned on in my editor(s) when editing makefiles (or, for that matter, when working in python).

Remind me what you were writing in your post before that response. Something like  "...Relying on an invisible empty statement is dangerous...", perhaps?

[Cerebus]

How about this (rather trivial) makefile not working as expected because of the error in the second line

Code: [Select]

clean:
rm -f blah.o blah.c blah
What's the error?

Obvious to anyone that has used make for more than, ooh 15 minutes? And that's even without scrolling down. I always have "Show Invisible Characters" turned on in my editor(s) when editing makefiles (or, for that matter, when working in python).

Remind me what you were writing in your post before that response. Something like  "...Relying on an invisible empty statement is dangerous...", perhaps?

Well, I can't actually check your makefile for actual characters present as the SMF editor doesn't actually take tabs, at least the WYSIWYG editor won't take them from me; so I'm quite happy to stipulate that I'm making an assumption about invisible characters. And 'rm -f <any old rubbish>' ought to work (or silently fail if a named file is not there). 'clean', as presented, is the first dependent in the file, so should be the default target, and make doesn't need a dependency to make either the default target or a target named on the command line. The only thing I can think of that remains a bit suspicious is the rm of blah.c as well as blah and blah.o but not that suspicious as I've written a  lot of makefiles with generated code where that was appropriate. So: I have bupkas otherwise.

[Berni]

Yeah makefiles used pretty much universally to drive compilation of C code are indeed very picky about whitespace types.

But using indentation for grouping in makefiles doesn't really make much sense since you don't really nest things in one another unless you make overly complex makefiles with a bunch of control statements and all that. Usually they are just a list of things to do along with defining a bunch of paths, so you never get past indentation level 1.

But again as long as you make sure you have your whitespace in order it all works fine, its not the only invisible character that can mess things up. Newlines being LF or CR+LF (Even CR alone was used in some systems) is also invisible in editors but can cause a lot of weird errors when they get mixed into source code. We still don't agree what the "correct" way to do a newline is

[SiliconWizard]

Yeah makefiles used pretty much universally to drive compilation of C code are indeed very picky about whitespace types.

But using indentation for grouping in makefiles doesn't really make much sense since you don't really nest things in one another unless you make overly complex makefiles with a bunch of control statements and all that. Usually they are just a list of things to do along with defining a bunch of paths, so you never get past indentation level 1.

But again as long as you make sure you have your whitespace in order it all works fine, its not the only invisible character that can mess things up. Newlines being LF or CR+LF (Even CR alone was used in some systems) is also invisible in editors but can cause a lot of weird errors when they get mixed into source code. We still don't agree what the "correct" way to do a newline is

Never had a single problem writing Makefiles. The indentation thing is peculiar, but pretty simple. Admittedly not the wisest choice they made, but 'make' is not a programming language, and can't be compared to what we talked about above.

As to end-of-line characters, only very ill-written or old tools have a problem with that. And yes, that includes 'make' (at least up to recently).

If you're using C and an std lib that is reasonable (this has been the default behavior on at least both Windows and Linux for at least 20 years), opening the file in text mode ("t") and using fgets() to read text files will transform any kind of EOL combination into a single '\n' character. Nothing special to do. Of course if you're reading the file character by character, which was very common in the old days, then you'll have to deal with it by hand.

[Nominal Animal]

I still think that the goal isn't to write the most concise code, but the most descriptive and least ambiguous code (to humans). That is why some people think I am silly for putting "if(somepointer != NULL) ..." rather than "if(!somepointer) ..." - those people aren't the people I am leaving the hints for.

I fully agree, and don't think it silly, even though I do use if (!somepointer) { error_case(); } myself.
Thing is, I tell learners to read that pattern as "if no somepointer, then error case".
Our objective is the same, just different approaches.

Whenever I write a spinning while loop with an empty body, I have a comment block explaining its purpose preceding it.

What's the error?

Like I said, highlighting all tabs in Gedit/Pluma (by searching for \t with backslash escapes enabled in the search dialog) makes the tabs visible.

Because of the sheer number of existing Makefiles, we cannot really change the syntax anymore; we're stuck with it.  Much like the oddities in English itself, with lead, lead, and lead all pronounced differently.

However, what I do myself, and recommend others do as well, is make sure they only have one indentation level, with a single tab.  Then, running
  sed -e 's|^[\t ][\t ]*|\t|' -i Makefile
is safe, and will fix any indentation issues.

(Before anyone points it out, I do know that GNU sed supports \+ in the "one or more of" sense.  However, that's not strictly BRE syntax.  Only EREs support + in the "one or more of" sense.  Trick for new players; one that I prefer to avoid.)

[SiliconWizard]

Whenever I write a spinning while loop with an empty body, I have a comment block explaining its purpose preceding it.

This is wise. Additionally, my coding style includes adding a blank line AFTER the loop, so it's even more readable: makes it even clearer at first sight that the loop is not meant to include anything below it.

[Nominal Animal]

Definitely; I tend to sprinkle empty lines to separate groups of logical operations as well, with a comment before each group.

I mostly use Gedit/Pluma with a dark theme, and syntax highlighting, so I've found that "style" makes it easiest/fastest for me to revisit old code.  I'd like to claim its almost like two different parts of my brain working in tandem, one looking at the code, and another at the comment, but that's just how it feels.  Gets me into the flow state.

It's not like I invented the style, though.  I have a habit of examining projects sources before using or recommending them, and have just stolen the approaches I like best for my own.

[blacksheeplogic]

I still think that the goal isn't to write the most concise code, but the most descriptive and least ambiguous code (to humans). That is why some people think I am silly for putting "if(somepointer != NULL) ..." rather than "if(!somepointer) ..." - those people aren't the people I am leaving the hints for.

"{ }" is much better than ";" in my book, as I try to not lay landmines for the future readers.

I would expect a competent programmer to understand the syntax of the language:
kbuf = getFreeBuffer();
if(kbuf != NULL)

kbuf = getFreeBuffer();
if(kbuf)

if(kbuf = getFreeBuffer())

if((kbuf = getFreeBuffer()) != NULL)

If noob likes it or not is irrelevant, if the code is out there (and there is a lot of it out there) you need to be able to work on it. Dumb down development to cater for the incompetent noob is not helping to build more competency.

I don't need non-observant programmers maintaining code and again there is a lot of code out there that may not be written to a personal preference:
if(!getFreeBuffer()) requestNewBuffer(); verses if(!getFreeBuffer()) {requestNewBuffer();}

If your working on poorly indented code that use use a code formatter.

Finally, I would prefer a programmer ask why this was done:
writeAddress = (void *) ((long) (ioAddress + offset) & (~(0x03)));
.....

Hide it and the incompetent programmer will someday use a iowrite8(), but again my preference is that the incompetent does not work on this type of code anyway.

[Mechatrommer]

Code: [Select]

while (condition) { ; } any better?

Yes, it's better. There is also a rule to avoid empty statements.

It's better, but better still would be the rather more explicit:

Code: [Select]

while (condition) {  /* deliberate no op */; }


It's better because... what?

It's better because it draws attention to the fact that an obscure 'feature'...

Code: [Select]

while (condition) {
// do nothing or whatever
};
this is better, why? because i say so... why extra ";"? because i can. no, actually because i want every line to be the same (uniform), since the rest are terminated with ";" this must be too. and how the hell i set the damn tab to be double space distance? in this SMF IDE? not 4 spaces apart? maybe i just replace a tab with "double space" instead..
[absolutionist's hat off]