IDEs still suck at file management

PleegWat

@sloosecannon said in IDEs still suck at file management:

Or are we talking literally switch?
Can you even omit those??

Probably only in C/C++. The body of switch is a statement. Any statement. Remember Duff's Device? In the version from wikipedia:

void send(to, from, count)
register short *to, *from;
register count;
{
    register n = (count + 7) / 8;
    switch (count % 8) {
    case 0: do { *to = *from++;
    case 7:      *to = *from++;
    case 6:      *to = *from++;
    case 5:      *to = *from++;
    case 4:      *to = *from++;
    case 3:      *to = *from++;
    case 2:      *to = *from++;
    case 1:      *to = *from++;
            } while (--n > 0);
    }
}

You can omit the braces around the do/while here, as it's only a single statement.

PleegWat

@PleegWat

void send(short *to, short *from, int count)
{
    int n = (count + 7) / 8;
    switch (count % 8) do {
        case 0: *to = *from++;
        case 7: *to = *from++;
        case 6: *to = *from++;
        case 5: *to = *from++;
        case 4: *to = *from++;
        case 3: *to = *from++;
        case 2: *to = *from++;
        case 1: *to = *from++;
    } while (--n > 0);
}

ben_lubar

@sloosecannon said in IDEs still suck at file management:

And make it easy to forget a break;?

You mean like this?

switch {
case 100 + 200 == 300:
    fmt.Println("math!")
    fallthrough
case 1 - 2 == 3:
    fmt.Println("!htam")
case true:
    fmt.Println("this one doesn't get printed")
}

kt_

@accalia said in IDEs still suck at file management:

@ben_lubar said in IDEs still suck at file management:

I'm never really sure what I should do when the body of the if statement

it's an if statement you fucking put the braces in.

same as you do for for loops, while loops, do while loops, switch statements, and methods!

if(accalia == null) throw new ArgumentNullException("accalia");

I will do this always. Because argument validation is not that important.

if(a == 2) b = 3;

Yup, no problem, why would I waste another 3 precious lines of I've nothing important to place there?

Oh, there's also

if(a == null) a = new A();
a.Do();

But that's been taken care of and now can finally be a one liner without pedants shouting at me.

a?.Do();

dkf

@kt_ said in IDEs still suck at file management:

a?.Do();

I thought that only calls Do if a is non-null, and I'm not sure what it would do to generate a result into an int (or other non-nullable type) if a was null…

Or maybe it just postpones the evil moment by one statement?

kt_

@dkf said in IDEs still suck at file management:

@kt_ said in IDEs still suck at file management:

a?.Do();

I thought that only calls Do if a is non-null, and I'm not sure what it would do to generate a result into an int (or other non-nullable type) if a was null…

Or maybe it just postpones the evil moment by one statement?

'twas a typo. Should be =! :)

loose

Got triggered because somebody mentioned network access. These days it seems no software application cannot function with some form of network access, even if it is just to "phone home". Anyhoo: It also seems that every time I do a manual Windows Update it gets stuck on the "Checking for updates bit". Long story short: stopping and restarting the network was the fix.

Just saying.

Edit: More specifically - Stopping and restarting the relevant network process for the "application"

masonwheeler

@asdf said in IDEs still suck at file management:

@sloosecannon said in IDEs still suck at file management:

And make it easy to forget a break;?

The real problem there is C-style fallthrough-by-default. Languages like Rust or C# don't have that.

C# doesn't, but it tries its best to pretend that it does for the sake of (the illusion of) compatibility with C syntax. Every case block must end with a break or other statement that unambiguously terminates the block and prevents fallthrough.

asdf

@masonwheeler Which is a good idea, IMO. You can still use the familiar syntax, but are prevented from making mistakes. And if you really want fallthrough behavior, you can still use goto case X, which actually gives you more flexibility.

Gąska

@asdf said in IDEs still suck at file management:

@masonwheeler Which is a good idea, IMO.

Would you also prefer if you were required to put void in argument lists of zero-argument methods? Because it makes just as much sense.

Jaloopa

@Gąska it's one of those design decisions made when the language was new to entice people to switch, which now has compatibility reasons for sticking around.

I'd prefer breaking to be the default, with a fallthrough keyword or goto

asdf

@Gąska said in IDEs still suck at file management:

Would you also prefer if you were required to put void in argument lists of zero-argument methods?

No, because everyone immediately understands an empty argument list as what it is. A C-style switch statement without break;s might be confusing, though. People could and would assume that the statements of the next case will be executed. Yes, they could have chosen a completely different syntax which makes the fact that breaking is the default more obvious, but since they wanted to mimick C++ syntax, requiring an explicit break; was the sane thing to do.

Gąska

@asdf said in IDEs still suck at file management:

No, because everyone immediately understands an empty argument list as what it is.

Likewise, everyone immediately understands switch-case without explicit breaks as what it is (a syntactic sugar for if-else chain).

@asdf said in IDEs still suck at file management:

People could and would assume that the statements of the next case will be executed.

Could, yes. Would, no, not really - except for ancient C hackers from before internet era who also like to declare their local variables before function body, AND only the first time they encounter switch statement in C#. The second time, they'd learn.

Unless you're speaking of utter morons. But IMO utter morons shouldn't be considered in the design of programming language.

Gąska

@Jaloopa said in IDEs still suck at file management:

@Gąska it's one of those design decisions made when the language was new to entice people to switch, which now has compatibility reasons for sticking around.

Nope - not requiring break would be backwards-compatible change - as long as explicit break would still be allowed. If I had anything to say in it, the next version of C# would not require explicit break, and the compiler would issue a warning if one did it anyway that could be either disabled or trivially fixed.

ben_lubar

@Gąska said in IDEs still suck at file management:

Nope - not requiring break would be backwards-compatible change

No it wouldn't, because:

switch (foo)
{
case 1:
case 2:
    bar();
    break;
case 3:
    baz();
    break;
}

would become

case 1:
    break;

LB_

@ben_lubar But I thought it was established that the first example wouldn't compile because it is missing an explicit break;? Or is C# even stranger than I thought when it comes to switch statements?

Jaloopa

@LB_ C# allows fallthrough if there is nothing in the first body. Ben's sample is saying "if 1 or 2, bar(), if 3 baz()"

Gąska

@ben_lubar either you're an idiot for not coming up with a solution or you're an idiot for thinking I'll take the bait.

Gąska

@LB_ said in IDEs still suck at file management:

Or is C# even stranger than I thought when it comes to switch statements?

It makes very much sense to allow empty case to fall through. It's better to think of it as "logical disjunction of case conditions" rather than "C# allows fall-through, but only for empty cases".

Onyx

@Gąska said in IDEs still suck at file management:

except for ancient C hackers from before internet era who also like to declare their local variables before function body

They made me do it in college! Claimed it won't work otherwise!

Then again, the official compiler they used was MSVC...

Gąska

@Onyx I'm pretty sure that if the compiler accepted this at all, it really wouldn't work otherwise.

boomzilla

@kt_ said in IDEs still suck at file management:

Yup, no problem, why would I waste another 3 precious lines of I've nothing important to place there?

Why waste lines? Put it all on One line, just don't omit the braces.

A foolish consistency is a hobgoblin Of small minds. Omitting braces for the sake of lines and keeping a consistent brace style is retarded.

asdf

@boomzilla Another thing I like about Rust: It doesn't even allow if/else without braces. You can omit the parentheses around the condition, though.

boomzilla

@asdf I'm not a huge fan of those parentheses.

asdf

@boomzilla said in IDEs still suck at file management:

I'm not a huge fan of those parentheses.

Me neither, and if you require the braces, they're unnecessary. Actually, I think omitting those parentheses improves readability.

kt_

@boomzilla said in IDEs still suck at file management:

@kt_ said in IDEs still suck at file management:

Yup, no problem, why would I waste another 3 precious lines of I've nothing important to place there?

Why waste lines?

'Cause I'm funny this way.

Seriously though, I have no problems with one liners, I think they actually improve readability. I use them.

Also:

SPACES ARE BETTER THAN TABS!!!!!!!!!1111111oneoneoneeleventeen

Onyx

@kt_ said in IDEs still suck at file management:

SPACES ARE BETTER THAN TABS!!!!!!!!!1111111oneoneoneeleventeen

0_1464693182659_upload-927509df-ea8e-4838-80ad-2d2cd2aa1ac6

boomzilla

@kt_ said in IDEs still suck at file management:

Seriously though, I have no problems with one liners, I think they actually improve readability. I use them.

Yes, of course. Just use the braces, too.

@Onyx said in IDEs still suck at file management:

@kt_ said in IDEs still suck at file management:

SPACES ARE BETTER THAN TABS!!!!!!!!!1111111oneoneoneeleventeen

QFT

Dreikin

@Onyx said in IDEs still suck at file management:

@kt_ said in IDEs still suck at file management:

SPACES ARE BETTER THAN TABS!!!!!!!!!1111111oneoneoneeleventeen

Look at their faces. These people have been sent out on so many Holy War Torches & Pitchforks runs they can't even be bothered to get out of their informal evening-wear.

Also, Tabs for indent, spaces for alignment

Onyx

@Dreikin Exactly. WTDWTF regulars. Your point?

kt_

@boomzilla said in IDEs still suck at file management:

@kt_ said in IDEs still suck at file management:

Seriously though, I have no problems with one liners, I think they actually improve readability. I use them.

Yes, of course. Just use the braces, too.

I'll think about it, but only because I've this feeling I got on your lawn somehow.

boomzilla

@kt_ Proper braces get you a guest pass.

kt_

@boomzilla said in IDEs still suck at file management:

@kt_ Proper braces get you a guest pass.

http://www.hiddenmickeyguy.com/sites/default/files/imagecache/Hidden_Mickey_Gallery_Preview/mickey-images/willy_wonka_braces_7188_7188.jpg

Can I come in, sir?

masonwheeler

@Gąska said in IDEs still suck at file management:

@asdf said in IDEs still suck at file management:

No, because everyone immediately understands an empty argument list as what it is.

Likewise, everyone immediately understands switch-case without explicit breaks as what it is (a syntactic sugar for if-else chain).

@asdf said in IDEs still suck at file management:

People could and would assume that the statements of the next case will be executed.

Could, yes. Would, no, not really - except for ancient C hackers from before internet era who also like to declare their local variables before function body, AND only the first time they encounter switch statement in C#. The second time, they'd learn.

Unless you're speaking of utter morons. But IMO utter morons shouldn't be considered in the design of programming language.

...because otherwise you get JavaScript?

@asdf said in IDEs still suck at file management:

@boomzilla Another thing I like about Rust: It doesn't even allow if/else without braces. You can omit the parentheses around the condition, though.

Yeah, that's a parsing thing. There needs to be some unambiguous way to tell where the condition ends and the if-true action begins. You can wrap the condition in parens (C-style) or use a token to denote the end of the condition (Pascal and Python-style) or use tokens to denote beginning of the the block (Rust-style) but you have to do something.

Dreikin

@masonwheeler said in IDEs still suck at file management:

There needs to be some unambiguous way to tell where the condition ends and the if-true action begins. You can wrap the condition in parens (C-style) or use a token to denote the end of the condition (Pascal and Python-style) or use tokens to denote beginning of the the block (Rust-style) but you have to do something.

You could keep going till it no longer evaluates to a Boolean, and the part that follows is the body. Or instead of being greedy it could go the other way and use the next value as the condition (encapsulating anything more complex than a Boolean variable or literal in parentheses to be evaluated first). Those could be fun.

dkf

@Dreikin said in IDEs still suck at file management:

You could keep going till it no longer evaluates to a Boolean, and the part that follows is the body.

Theoretically, you can just parse whatever meets the rule for an expression and use that, with whatever meets the definition for a statement or statements following. Only problem is that this makes debugging syntax errors potentially “rather more interesting”…

blakeyrat

@Dreikin That's a terrible image, those are Hawaiian tiki torches, and there's not a single pitchfork.

masonwheeler

@dkf said in IDEs still suck at file management:

@Dreikin said in IDEs still suck at file management:

You could keep going till it no longer evaluates to a Boolean, and the part that follows is the body.

Theoretically, you can just parse whatever meets the rule for an expression and use that, with whatever meets the definition for a statement or statements following. Only problem is that this makes debugging syntax errors potentially “rather more interesting”…

if x < y - x.SomeMethod()

There has to be a disambiguator, or things can end up very ambiguous.

Gąska

@Dreikin said in IDEs still suck at file management:

You could keep going till it no longer evaluates to a Boolean, and the part that follows is the body.

Have fun building AST before type-checking.

accalia

@masonwheeler said in IDEs still suck at file management:

There has to be a disambiguator, or things can end up very ambiguous.

there is one. any compiler i write, upon encountering an ambiguous AST will cause your computer to open a hellportal and summon imps and demons to plague the developer who wrote the ambiguity until such time as they correct the ambiguity.

Jaloopa

@Gąska said in IDEs still suck at file management:

AST

assured shorthold tenancy?

dkf

@accalia said in IDEs still suck at file management:

any compiler i write, upon encountering an ambiguous AST will cause your computer to open a hellportal and summon imps and demons to plague the developer who wrote the ambiguity until such time as they correct the ambiguity.

for Doing It Right!

accalia

@Jaloopa said in IDEs still suck at file management:

@Gąska said in IDEs still suck at file management:

AST

assured shorthold tenancy?

Abstract Syntax Tree

@dkf said in IDEs still suck at file management:

for Doing It Right!

it also does that if someone writes a function, or class with a cyclomatic complexity score above 40 (for functions) or 80 (for classes).

my personal limits for taste in cyclomatic complexity is a quarter that limit so that should be plenty of headroom.

oh, and DO NOT ask what it does when it encounters mixed tabs and spaces for indentation.... you do not want to know.

dkf

@accalia said in IDEs still suck at file management:

oh, and DO NOT ask what it does when it encounters mixed tabs and spaces for indentation.... you do not want to know.

I might sometimes mix, but if I do, tabs will be 8 characters wide. No negotiation.

boomzilla

@masonwheeler said in IDEs still suck at file management:

There has to be a disambiguator, or things can end up very ambiguous.

Easy!

if x < y {- x.SomeMethod()}

Perfect time to make the braces required. Where we still have that awful and dangerous ambiguity.

Not sure why you need to make that negative, though.

dkf

@boomzilla said in IDEs still suck at file management:

Perfect time to make the braces required.

I prefer to require both parens and braces. So what if it takes extra characters? Is there a world parenthesis shortage?

boomzilla

@dkf I don't care about the extra characters as extra characters. Just that they're extra noise for no benefit, from my perspective, where I always use braces.

asdf

@masonwheeler said in IDEs still suck at file management:

Another thing I like about Rust: It doesn't even allow if/else without braces. You can omit the parentheses around the condition, though.

Yeah, that's a parsing thing.

I'm aware. In this particular case, it's pretty obvious. It's also the correct thing to do: Allowing developers to omit the braces instead of the parens can result in accidental bugs, the other way around it can't.

@dkf said in IDEs still suck at file management:

Theoretically, you can just parse whatever meets the rule for an expression and use that, with whatever meets the definition for a statement or statements following.

I don't think that'd work, since e.g. if/else is an expression in Rust, not a statement. Therefore, at least nested ifs wouldn't work.

@Gąska said in IDEs still suck at file management:

You could keep going till it no longer evaluates to a Boolean, and the part that follows is the body.

Have fun building AST before type-checking.

I think you mean the other way around, right?

@accalia said in IDEs still suck at file management:

there is one. any compiler i write, upon encountering an ambiguous AST will cause your computer to open a hellportal and summon imps and demons to plague the developer who wrote the ambiguity until such time as they correct the ambiguity.

*ducks*

I won't write any C++ anymore, I swear!

PleegWat

@accalia said in IDEs still suck at file management:

@masonwheeler said in IDEs still suck at file management:

There has to be a disambiguator, or things can end up very ambiguous.

there is one. any compiler i write, upon encountering an ambiguous AST will cause your computer to open a hellportal and summon imps and demons to plague the developer who wrote the ambiguity until such time as they correct the ambiguity.

I see we have a doom player in our midst?

accalia

@PleegWat said in IDEs still suck at file management:

@accalia said in IDEs still suck at file management:

@masonwheeler said in IDEs still suck at file management:

There has to be a disambiguator, or things can end up very ambiguous.

there is one. any compiler i write, upon encountering an ambiguous AST will cause your computer to open a hellportal and summon imps and demons to plague the developer who wrote the ambiguity until such time as they correct the ambiguity.

I see we have a doom player in our midst?

not the comment i expected when i made the post, but 'll take it.

also, yes. classic doom. waiting a bit for new doom because or reasons of i have no money left in the budget thanks to the HTC VIVE