Too many programming languages?

[westfw]

If noob likes it or not is irrelevant

I have come to believe that writing code in a way that "noob" can understand it is VERY IMPORTANT.
I mean, I've updated programs for new OSes, where I didn't "know" the language it was written in (because all of the original programmers were gone, and I at least understood the OS.)   And I've worked for companies that pretty much had to abandon promising but weird high-performance VLIW/bitslice architectures at least partially because they couldn't find enough people who could write (or fix) code for them.

[blacksheeplogic]

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]
[/quote]

for(;myFunction(); );

although perhaps more correctly
for(;!myFunction(); );

but I could write
while(myFunction() == OK)

and of course if {} make it more readable there is
{}while(!myFunction() != OK)

Would a comment help?
{/* doing nothing until the cows come home */}while(!myFunction() != OK)

But just remember to change the comment when writing :
while(!myFunction()) {/* when the cows come home I will have something to do */};


{} makes code more readable.... Seems like a personal preference to me.

[blacksheeplogic]

If noob likes it or not is irrelevant

I have come to believe that writing code in a way that "noob" can understand it is VERY IMPORTANT.
I mean, I've updated programs for new OSes, where I didn't "know" the language it was written in (because all of the original programmers were gone, and I at least understood the OS.)   And I've worked for companies that pretty much had to abandon promising but weird high-performance VLIW/bitslice architectures at least partially because they couldn't find enough people who could write (or fix) code for them.

My point however is that you don't always get to work on pristine code, so you need to learn the language. I've worked on code bases with several million lines spanning decades with very large development teams. You might see or do some refactoring here or there but with the inherent risks associated with refactoring and time pressure mostly it is resolve the defect and more to the next.

[Nusa]

Noobish, eh? Sometimes the noobish way is actually very clear and unambiguous, not to mention identical in function:

Code: [Select]

waitloopy: if (condition) goto waitloopy;
The screaming may commence.

[blacksheeplogic]

Noobish, eh? Sometimes the noobish way is actually very clear and unambiguous, not to mention identical in function:

Code: [Select]

waitloopy: if (condition) goto waitloopy;

Firstly your asserting that
while(condition()) ;

is not clear and unambiguous.

I'm having a difficult time understanding why you think that a loop construct defined in the language is not clear and unambiguous. I would tend to side with using the construct rather than working around it purely from expected language coding practices. It would be very uncommon in a C code base to come across your proposed style of loop implementation, particularly when formal code review's are process.


waitloop: if(condition()) goto waitloop;

Aside from the above, although not more or less readable (it's used in assembly) this style can be more difficult from a maintenance perspective and it's leads to less structured code. For example when there is more than one, or additional waitloops are inserted. In addition 'I can just go back' to that other waitloop infects the code.

If the language supports a loop construct, generally it's going to have preferred use. Again my point was not about personal preference (or how many different ways code can implement a requirement) but ability and competency in the language. A noob implementing blinky on their own time is quite different to working on an existing code base where your personal style preference may not be the same as those that went before you or those that will come after you.

[brucehoult]

Firstly your asserting that
while(condition()) ;

is not clear and unambiguous.

I'm having a difficult time understanding why you think that a loop construct defined in the language is not clear and unambiguous.

It is of course clear and unambiguous if you examine it carefully. However ";" is small and easily missed when scanning code quickly, while a "{}" stands out like a boar's bollocks.

[westfw]

but with the inherent risks associated with refactoring and time pressure mostly it is resolve the defect and more to the next.

Sure.  I agree that FIXING code just to make it more readable is not nearly as worthwhile as writing it to be readable in the first place.
Alas, "old code" tends to get modified for perfectly good reasons, in ways that are detrimental to readability.  (A good argument for making things as readable as possible to start with.)

I've yet to look at a C++ STL source file that I consider "readable" - all those "advanced" C++ features piled in to make them work under various obscure circumstances (I guess?)  And I have some ~1985 code that someone sensibly decided should get function prototypes.  That's a fine idea, but it now looks like:

Code: [Select]

static int
#if HAVE_STDC
prsnum(char *text, int textlen, flag_t flags, int radix, int *sign, char **digits, int *ndig, char **term)
#else /* K&R style */
prsnum(text,textlen,flags,radix,sign,digits,ndig,term)
char *text, **digits, **term;
int textlen;
flag_t flags;
int radix, *sign, *ndig;
#endif /* HAVE_STDC */
{

[blacksheeplogic]

I've yet to look at a C++ STL source file that I consider "readable" - all those "advanced" C++ features piled in to make them work under various obscure circumstances (I guess?)  And I have some ~1985 code that someone sensibly decided should get function prototypes.  That's a fine idea, but it now looks like:

Please do not bring C++ template suffering into this discussion. I've had some very traumatic experiences working with abstracting C++ template zelots (aka customers). Ever tried to figure out what Fck'in C++ source line  actually caused the optimizer to write out that sequence of instructions because some a-hole loved templates (made the code more readable my ass) and sent you the 10K line test case? OK, now I'm triggered, I should have given that job to the intern.

[tggzzz]

no, actually because i want every line to be the same (uniform), since the rest are terminated with ";" this must be too.

You need to understand the difference between a "terminator" and a "separator" - and switch to a language that uses terminators.

Learningabitofpunctuationamdcapitalisationwouldalsobehelpful to readers. But maybe you aren't worried about people reading your posts?

[GeorgeOfTheJungle]

Noobish, eh? Sometimes the noobish way is actually very clear and unambiguous, not to mention identical in function:

Code: [Select]

waitloopy: if (condition) goto waitloopy;

 

If the moar verbose the betterer... how about this:

Code: [Select]

while (1) if (condition) continue; else break;

[GeorgeOfTheJungle]

Code: [Select]

while (1) if (condition) continue; else break;

Oh, sorry! With the compulsory braces and newlines:

Code: [Select]

while (1) {
  if (condition) {
    continue;
  }
  else {
    break;
  }
}
The more the LoCs the better the bill.

[Nusa]

Noobish, eh? Sometimes the noobish way is actually very clear and unambiguous, not to mention identical in function:

Code: [Select]

waitloopy: if (condition) goto waitloopy;

 

If the moar verbose the betterer... how about this:

Code: [Select]

while (1) if (condition) continue; else break;

Interesting. I went and played with several popular compilers on godbolt.org, enabling one line at a time.

Code: [Select]

bool condition;
int test()
{
  //waitloopy: if (condition) goto waitloopy;
  //while (condition);
  //while (1) if (condition) continue; else break;
  //while (1) if (!condition) break;
}The first and second lines always compile to the same output.
The third and fourth lines always produced larger output than first and second lines. Continue/break branches inside loops clearly aren't fully optimized for this case.
The third and fourth lines did not always produce the same output. It depended on the compiler I chose.

[hamster_nz]

Code: [Select]

while (1) if (condition) continue; else break;

Oh, sorry! With the compulsory braces and newlines:

Code: [Select]

while (1) {
  if (condition) {
    continue;
  }
  else {
    break;
  }
};
The more the LOCs the better the bill.

I don't that that abhorrent, except the redundant 'else', and the trailing semicolon. Heck, we have 4k screens now, so LOC isn't the issue it was...

Code: [Select]

// Need to retry SQL for some conditions
while (1) {
  try_to_run_sql("SELECT_FOO_FROM_BAR");

  if (database_was_locked) {
    log("Retrying due to a locked database");
    continue;
  }

  if (database_was_busy) {
    log("Retrying due to a busy database");
    continue;
  }

  if (database_commit_failed) {
    log("Retrying due to commit failed");
    continue;
  }

  // No more retry conditions - has either succeeded or failed.
  break;
}

if(database_had_error) {
  log("SQL failed with error blar");
  return -1;
}
log("SQL successfully completed");
return 0;

Then you come back a few days later and change:

Code: [Select]

while (1) {
to

Code: [Select]

for(retries_left =  MAX_SQL_ATTEMPTS; retries_left > 0; retries_left--) {

Hey, but each to their own... you could write:

Code: [Select]

do try_to_run_sql("SELECT_FOO_FROM_BAR");
while(database_was_locked || database_was_busy || database_commit_failed)
return database_had_error ? -1 : 0;

And then the next guy will have to refactor the code if you wanted to add any sort of logging, or wanted to limit the number of retries... or any sort of actual improvement.

PS. Excuse any typos / errors in code, just ranting, not compiling. 

[GeorgeOfTheJungle]

Code: [Select]

while (1) if (condition) continue; else break;

[..] the redundant 'else' [..]

It isn't redundant!

[brucehoult]

Noobish, eh? Sometimes the noobish way is actually very clear and unambiguous, not to mention identical in function:

Code: [Select]

waitloopy: if (condition) goto waitloopy;

 

If the moar verbose the betterer... how about this:

Code: [Select]

while (1) if (condition) continue; else break;

Interesting. I went and played with several popular compilers on godbolt.org, enabling one line at a time.

Code: [Select]

bool condition;
int test()
{
  //waitloopy: if (condition) goto waitloopy;
  //while (condition);
  //while (1) if (condition) continue; else break;
  //while (1) if (!condition) break;
}The first and second lines always compile to the same output.
The third and fourth lines always produced larger output than first and second lines. Continue/break branches inside loops clearly aren't fully optimized for this case.
The third and fourth lines did not always produce the same output. It depended on the compiler I chose.

This would be surprising from gcc or llvm on any CPU at any optimization level except -O0, although behaviour is undefined as you wrote it. You might get more consistent results with "condition" volatile. That might help consistency at -O3, otherwise I could see -O3 doing something like unrolling and then optimizing and getting something like:

Code: [Select]

while (condition){
  int i=32;
  while(--i){}
}


[brucehoult]

Code: [Select]

while (1) if (condition) continue; else break;

Oh, sorry! With the compulsory braces and newlines:

Code: [Select]

while (1) {
  if (condition) {
    continue;
  }
  else {
    break;
  }
};
The more the LOCs the better the bill.

I don't that that abhorrent, except the redundant 'else', and the trailing semicolon.

Oh, Michael :-(

Without the "else" it's an infinite loop, even if "condition" is volatile.

(If "condition" isn't volatile then the compiler is entitled to do all kinds of things: delete all code following this loop as unreachable, mark the function itself "noreturn", delete all code following any *call* of this function as unreachable etc etc)

[Nusa]

Ok, you were correct; rookie mistake. Once optimization was turned on, all cases compiled the same. The volatile keyword was also required or the test got optimized out and it became a simple infinite loop.

[hamster_nz]

Code: [Select]

while (1) if (condition) continue; else break;

Oh, sorry! With the compulsory braces and newlines:

Code: [Select]

while (1) {
  if (condition) {
    continue;
  }
  else {
    break;
  }
};
The more the LOCs the better the bill.

I don't that that abhorrent, except the redundant 'else', and the trailing semicolon.

Oh, Michael :-(

Without the "else" it's an infinite loop, even if "condition" is volatile.

(If "condition" isn't volatile then the compiler is entitled to do all kinds of things: delete all code following this loop as unreachable, mark the function itself "noreturn", delete all code following any *call* of this function as unreachable etc etc)

Um, explain more... because I'm missing something...

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
  //code copy and pasted, with condition replaced
  while (1) {
    if (rand() < 100) {
      continue;
    }
    // else // this keyword makes no difference
    {
      break;
    }
  };
  printf("Done\n!");
  return 0;
}

Seems to work fine...

[blacksheeplogic]

(If "condition" isn't volatile then the compiler is entitled to do all kinds of things: delete all code following this loop as unreachable, mark the function itself "noreturn", delete all code following any *call* of this function as unreachable etc etc)

Um, explain more... because I'm missing something...
Seems to work fine...

The condition was invariant in the first example, in the second example the condition is not invariant.

[GeorgeOfTheJungle]

(If "condition" isn't volatile then the compiler is entitled to do all kinds of things: delete all code following this loop as unreachable, mark the function itself "noreturn", delete all code following any *call* of this function as unreachable etc etc)

Um, explain more... because I'm missing something...
Seems to work fine...

The condition was invariant in the first example, in the second example the condition is not invariant.

I think he means that you can remove the else and leave the break.

[blacksheeplogic]

I think he means that you can remove the else and leave the break.

Sorry, yes that as well  - the else along with two sets of  {} are redundant.

The behavior of the optimizer should be dependent on condition being variant/invariant.

Refactored it could also be written:
while(1)
{
   if (!condition()) break;
}

but it's sugar, as we come back to:
while(!condition()) ;

Or if you like you {} :
{}while(!condition());
while(!condition()) { ; }

[brucehoult]

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
  //code copy and pasted, with condition replaced
  while (1) {
    if (rand() < 100) {
      continue;
    }
    // else // this keyword makes no difference
    {
      break;
    }
  };
  printf("Done\n!");
  return 0;
}

Seems to work fine...

"I don't [find] that abhorrent, except the redundant 'else', and the trailing semicolon."

Ugh. Removing only the word "else" and leaving the brackets makes it even more abhorrent! But certainly that will work ok.

In my experience, when someone says they will "remove the else" they mean removing also the code controlled by it -- the "else clause".

[blacksheeplogic]

I think he means that you can remove the else and leave the break.

OK, I should have looked at your example before the {} altered it:
while (1) if (condition) continue; else break;

As written, the else is needed when condition is variant.

[Cerebus]

The condition was invariant in the first example, in the second example the condition is not invariant.

I think he means that you can remove the else and leave the break.

Erm, no.

invariant | ɪnˈvɛːrɪənt |
adjective
never changing: the pattern of cell divisions was found to be invariant.
noun Mathematics
a function, quantity, or property which remains unchanged when a specified transformation is applied.

[legacy]

when someone says they will "remove the else" they mean removing also the code controlled by it -- the "else clause".

avionic rule #13: "{ }" must always be preceded by if() | else | do | while() | switch() | for() | function()