for(i = 0; i < 10; i++){
case 1:{
All these years I didn't know such a monstrous thing was legal in C code. Is it possible to make amendments to the Geneva Convention, and if so, who should I call?
for(i = 0; i < 10; i++){
case 1:{
All these years I didn't know such a monstrous thing was legal in C code. Is it possible to make amendments to the Geneva Convention, and if so, who should I call?
if(i == 1) {}
else if(b == true){}
else if(s == "string") {}
else if(response.status() == Status.OK){}
else if(hereIsARecursiveMethodAlwaysReturningFalse()){}
... 3 more
Edit: it’s also just kind of a code smell that suggests the overall structure is not well thought out, with that particular collection of tests. Could be fine in that respect in context tho
When contributors to two different modules keep running into contract violations, you set up a CI build that triggers when either of the modules is built. If it fails it means that something got broken. It doesn't stop the build pipeline, but it warns you that garbage is about to come out the other end.
There's a general dynamic between people where peer pressure does not work when the delay between action and consequence grows too long. Nobody truly internalizes how upset other people are when they are found out for something bad they did a year ago, a month ago, or in some cases days ago (hence why roommates fight so often about chores). But getting called out for something you did two hours ago has sorted out an awful lot of bad behavior.
And the nice thing about the Canary Build is that in many CI tools you can set it up and not give him any permissions.
Why doesn't it? Prevent it from merge and build; require the dev to either fix it, or convince the rest of the team that the change should be allowed.
The API change is communicated and approved by both parties.
You build the first thing.
Canary fails, because API has changed.
You change the other to match the new API.
Canary fails again, because it uses the most recent non-failed build.
???
Owner of the canary build is now shunned.
So what if they're different types? It's not like your passing those variables to functions right there. And are we really so robotic that we can't understand different types in a conditional?
Except the recursive function bit. Why bother if its always false...
Yes it did. Case blocks had several lines.
>So what if they're different types?
It makes it hard to read and destroys expectation of what possible cases there are. It makes it hard to test as a lot of test preparation/mocking is necessary.
>Except the recursive function bit. Why bother if its always false...
Yea, that the point! Because there was no test for it
Assuming he has to do the check that way, of course.
It is. When you read it in isolation here, it's fine. If you have to read pages and pages of it and you have to concentrate/have half your brain working on the logic of the code, you don't want to annoy your brain with details like these.
It can eliminate code repetition, without the bother of making a whole new function:
for(i = 0; i < 10; i++){
switch (i) {
case 1:
// this is special for 1
break;
case 3:
// this is special for 3
// fallthrough
case 5:
// case 5 needs 3 processing, plus its own
break;
case ...:
// ...
}
// a slightly long block here
// common to all cases.
}
switch (i) {
case 0: // so we can enter the for at all
for (i = 0; i < 10; i++) {
case 1: ;
}
}
See, this is what happens when, in a forum, I pretend that I comment. Don't worry, I don't, IRL.
switch(override){
default:
if(foo==42){
case THING1:
code_here();
}else if(bar&0x42){
case THING2:
other_code();
}else{
case THING3:
more_code();
}
}
if (override ? override == THING1 : foo == 42) {
code_here();
} else if (override ? override == THING2 : bar & 0x42) {
other_code();
} else if (override ? override == THING3 : true) {
more_code();
}> "This code forms some sort of argument in that debate, but I'm not sure whether it's for or against."
Computed goto's are even more useful for the above, but they're an extension. I'd love to see computed goto's added to the C standard, but it's far too late to change the semantics of switch. Rather, just accept that their code flow semantics make them slightly more type safe syntactic sugar for goto--not just in how they're implemented, but in how they can be used.
I mostly wanted to provide the quote from Duff, it seemed relevant to the OP.