I hate Eclipse, Adobe, JBoss, and everything related to Java.

antiquarian

I think if a language feature can be abused to write bad unreadable code, it eventually will be abused to write bad unreadable code, and therefore it should either be redesigned or removed.

I think we've had this discussion before. I'm not in favor of making it easier for incompetent programmers to continue to write code. We have two better solutions. We can encourage them to do something else, or we can use snoofle's cluebat on them.

blakeyrat

@dhromed said:

So that's every single feature of every language ever, right down to the var keyword in javascript.

Maybe but you shouldn't ENCOURAGE it. If only 1 in 20 uses of the feature are non-confusing, you shouldn't have the feature.

Xyro

@lethalronin27 said:

I'd rather read a really long line of code and know exactly which object is calling which method [...]

@blakeyrat said:

I think if a language feature can be abused to write bad unreadable code, it eventually will be abused to write bad unreadable code, and therefore it should either be redesigned or removed.

We've almost come full circle back to Java!

blakeyrat

@PedanticCurmudgeon said:

I think we've had this discussion before.

We have.

@PedanticCurmudgeon said:

I'm not in favor of making it easier for incompetent programmers to continue to write code.

Then you have a responsibility no man has ever faced. You have your fear which might become reality. And you have ~~Godzilla~~ bad programmers, which is are reality.

... ok that quote doesn't fit, point is bad programmers exist. You can mitigate the damage they can do, but you can't stop them from existing, and you can't stop them from touching your code (sooner or later), and you have to cope with that reality as it exists right now.

Denial is never a good thing. Planning for some magical future in which bad programmers don't exist is a waste of time.

lethalronin27

@PedanticCurmudgeon said:

@lethalronin27 said:
Of course there are valid uses for it, but from my (admittedly limited) experience, the ratio of places where it's used in a valid way to places where it just complicates things seems to be around 1:20. So if I had to choose between never being able to use it and letting all developers use it where they see fit, I would choose to never use it.
So the problem is really that your colleagues don't know how to properly use this language feature. Responding to this by not letting them use it at all is reasonable, but leaves two important questions unasked:
Why don't they know how to properly use withs?
What other language features don't they know how to use?

I don't know, they're bad programmers?
Can't even guess at that. They're more familiar with Delphi than I am. The problem is they just don't get the difference between sane, organized code and slapping everything into a 2000 line function (yes, 2000) with triple-nested "with" statements throughout.

@blakeyrat said:
@dhromed said:
So that's every single feature of every language ever, right down to the var keyword in javascript.
Maybe but you shouldn't ENCOURAGE it. If only 1 in 20 uses of the feature are non-confusing, you shouldn't have the feature.

Yeah, saying you shouldn't use ANY feature that can be used improperly is going a bit far. I'd say whether a feature should exist or not really comes down to how many people understand it in practice. Delphi's "with" statement is an example of a feature that it seems like most people don't know how to use effectively, so it should be avoided, but I'm willing to bet that people who don't get javascript's "var" are the minority by far, so that's something that would stay.

@lethalronin27 said:

Delphi's "with" statement is an example of a feature that it seems like most people don't know how to use effectively, so it should be avoided, but I'm willing to bet that people who don't get javascript's "var" are the minority by far, so that's something that would stay.

I don't think most people fully understand JavaScript's "var" (ie, the whole thing about variable hoisting), while Delphi's "with" keyword doesn't have much to understand (I think? I'm no Delphi expert, or even noob for that matter).

It's just easier to abuse the latter than the former, that's all. You can't nest var declarations, unlike with statements and ternary operators.

lethalronin27

@Zecc said:

@lethalronin27 said:
Delphi's "with" statement is an example of a feature that it seems like most people don't know how to use effectively, so it should be avoided, but I'm willing to bet that people who don't get javascript's "var" are the minority by far, so that's something that would stay.
I don't think most people fully understand JavaScript's "var" (ie, the whole thing about variable hoisting), while Delphi's "with" keyword doesn't have much to understand (I think? I'm no Delphi expert, or even noob for that matter).
It's just easier to abuse the latter than the former, that's all. You can't nest var declarations, unlike with statements and ternary operators.

True. My point stays basically the same though, just replace "people who don't get X" with "people who abuse X". My thinking was that if people don't get some feature, they'll abuse it. As you pointed out, thats not always the case.

antiquarian

@blakeyrat said:

Planning for some magical future in which bad programmers don't exist is a waste of time.

Planning for another magical future in which all programmers use only blakeyrat-approved languages is an even bigger waste of time (people are still writing bad, unreadable COBOL and c). And it's true that you can't stop bad programmers from touching your code, but if you write it in Haskell, they most likely won't be able to get their changes to compile.

Cassidy

@lethalronin27 said:

My thinking was that if people don't get some feature, they'll abuse it.

.. which is the fault of the person (programmer), not of the language.

Removing features that could potentially be abused by idiot/novice programmers won't stop bad coding: the idiots will just search for some other feature they misunderstand and abuse that instead.

@dhromed said:

@blakeyrat said:
I think if a language feature can be abused to write bad unreadable code, it eventually will be abused to write bad unreadable code,

So that's every single feature of every language ever, right down to the var keyword in javascript.
@blakeyrat said:
it should either be redesigned or removed.

That's the problem. There may be features in every language that are buggy or poorly implemented, but, there is no perfect programming language and it isn't possible to create one. Saying "this feature should be removed because it can be abused to write bad unreadable code" misses the point. Just about every feature of every language can be abused/misused by stupid/incompetent programmers. You can't fix stupid.

boomzilla

@Cassidy said:

Removing features that could potentially be abused by idiot/novice programmers won't stop bad coding: the idiots will just search for some other feature they misunderstand and abuse that instead.

Yeah, like no one's ever abused something that they understood. C'mon, you know you've done it.

blakeyrat

@El_Heffe said:

That's the problem. There may be features in every language that are buggy or poorly implemented, but, there is no perfect programming language and it isn't possible to create one.

Duh? Who claimed otherwise? When you people reply to my post, it would be helpful if you typed all the crazy things the aliens from Pluto beamed into your brain while reading it. Because I sure as fuck didn't type the thing you're replying to.

But for what it's worth, the point is that you iterate. Version 2 becomes better than version 1. Version 3 becomes better than version 2. Obviously there's no "super perfect forever version", but that's no reason to give up trying to improve anything. Tell your Pluto aliens that.

antiquarian

@lethalronin27 said:

2. Can't even guess at that. They're more familiar with Delphi than I am. The problem is they just don't get the difference between sane, organized code and slapping everything into a 2000 line function (yes, 2000) with triple-nested "with" statements throughout.

In that case, making them not use nested withs is like putting a band-aid on a gunshot wound.

Cassidy

@boomzilla said:

Yeah, like no one's ever abused something that they understood. C'mon, you know you've done it.

I was young and inexperienced. I needed the money.

mott555

@Cassidy said:

@boomzilla said:
Yeah, like no one's ever abused something that they understood. C'mon, you know you've done it.
I was young and inexperienced. I needed the money.

It was a long and hard summer, and I did many things I regret. That was four of them.

dhromed

@mott555 said:

It was a long and hard ~~summer~~, and I did many ~~things I regret. That was four~~ of them.

Cassidy

Just when you thought you were safe from the Purple Dildo...

flabdablet

@blakeyrat said:

Incidentally, the ternary conditional is pretty much the same way: one of them is ok, but if you use them recursively please re-write the code until it's clear what's going on.

Nested ternary conditionals can actually express intent extremely clearly, if all you're using them for is to make if-then-elseif chains and the conditions are short and simple:

result = isItThis? this: isItThat? that: isItTheOther? theOther: somethingElse;

I don't think I've ever seen clear, readable code involving a subcondition nested inside the True branch of a ternary conditional.

dhromed

@flabdablet said:

Nested ternary conditionals can actually express intent extremely clearly,

A weird claim, since your example demonstrates the opposite.

@flabdablet said:

result = isItThis? this: isItThat? that: isItTheOther? theOther: somethingElse;

What in the fuck is this? Stop writing bullshit code like this. Stop it.

antiquarian

@flabdablet said:

@blakeyrat said:
Incidentally, the ternary conditional is pretty much the same way: one of them is ok, but if you use them recursively please re-write the code until it's clear what's going on.

Nested ternary conditionals can actually express intent extremely clearly, if all you're using them for is to make if-then-elseif chains and the conditions are short and simple:

result = isItThis? this: isItThat? that: isItTheOther? theOther: somethingElse;

I don't think I've ever seen clear, readable code involving a subcondition nested inside the True branch of a ternary conditional.

And this is why it's bad to make things easier for incompetent programmers. An incompetent programmer who knows he's incompetent will generally either find another way of making a living or go off in search of a clue. That leaves the majority of the clueless who think they know what they're doing; after all, they get stuff working, right? And since they get stuff working, they never bother getting a clue and continue writing WTF code for the rest of their days.

dhromed

@PedanticCurmudgeon said:

And this is why it's bad to make things easier for incompetent programmers

As long as you don't define what "easy for the incompetent" means, your arguments is null and your problem non-existant.

– something must be done about unsafe things!

– about what? What unsafe things?

– I don't know! But we have to do it!

@blakeyrat said:

When you people reply to my post, it would be helpful if you typed all the crazy things the aliens from Pluto beamed into your brain while reading it. Because I sure as fuck didn't type the thing you're replying to.

For someone who constantly complains about the reading comprehension of others, you sure do a lousy job yourself. Or maybe you just need to increase your Alzheimers medication since your short term memory doesn't seem so good. You said: @blakeyrat said:

I think if a language feature can be abused to write bad unreadable code, it eventually will be abused to write bad unreadable code, and therefore it should either be redesigned or removed.

And then I said @El_Heffe said:

Saying "this feature should be removed because it can be abused to write bad unreadable code" misses the point. Just about every feature of every language can be abused/misused by stupid/incompetent programmers.

@blakeyrat said:

the point is that you iterate. Version 2 becomes better than version 1. Version 3 becomes better than version 2. Obviously there's no "super perfect forever version", but that's no reason to give up trying to improve anything. Tell your Pluto aliens that.

Yes, you should always improve. Each version should be better that the previous one. Nobody said otherwise. But that's not the point here. Just because a particular feature or function can be abused/misued by morons doesn't automatically make it bad and in need of change or removal or "improvement". For example, you also said:@blakeyrat said:

Incidentally, the ternary conditional is pretty much the same way: one of them is ok, but if you use them recursively pleasee re-write the code until it's clear what's going on.

I agree 100%. People shouldn't do that. But they do. The reality is that people write shitty code. So you deal with that reality. You tell them to fix their shitty code. There's always room for improvement, but when you go around saying "Hey, let's get rid of [whatever] because somebody might use it wrong" you're trying to solve the wrong problem.

@flabdablet said:

result = isItThis ? this :
         isItThat ? that :
         isItTheOther ? theOther :
         somethingElse;

CS ate your indentation. I fixed it.

boomzilla

@El_Heffe said:

@blakeyrat said:
When you people reply to my post, it would be helpful if you typed all the crazy things the aliens from Pluto beamed into your brain while reading it. Because I sure as fuck didn't type the thing you're replying to.

For someone who constantly complains about the reading comprehension of others, you sure do a lousy job yourself. Or maybe you just need to increase your Alzheimers medication since your short term memory doesn't seem so good.

I think the Plutonian aliens have gotten to him again. You should know by now that he has no clue what he wrote in earlier posts. Rantula Rasa, as it were, for each new post.

antiquarian

@dhromed said:

@PedanticCurmudgeon said:
And this is why it's bad to make things easier for incompetent programmers

As long as you don't define what "easy for the incompetent" means, your arguments is null and your problem non-existant.
– something must be done about unsafe things!
– about what? What unsafe things?
– I don't know! But we have to do it!

Dude, context!

dhromed

@PedanticCurmudgeon said:

Dude, context!

The context is the same sentence of yours, slightly rewritten.

antiquarian

pick up cluebat

dhromed

@PedanticCurmudgeon said:

pick up cluebat

hit DM

antiquarian

But I wanted to hit the guy who thinks nested ternary conditionals are a good idea!

blakeyrat

@El_Heffe said:

There's always room for improvement, but when you go around saying "Hey, let's get rid of [whatever] because somebody might use it wrong" you're trying to solve the wrong problem.

Well, first of all solving the two problems isn't mutually-exclusive. So right there your argument kind of falls flat.

But mostly, solving code problems is significantly easier than solving human being problems. So you can solve the problem quicker by changing the language than you can by changing the programmers.

The computer doesn't give a shit whether you type "if()" or whether you type a question mark. They're exactly equivalent to the computer. But some humans are thrown-off by the question mark syntax while most humans are not thrown-off by the "if()" syntax. Therefore, logically, you should always use "if()". It's really that simple.

If you have two things that are exactly equivalent, and one is more confusing than the other, then the more confusing one should be deprecated. It's really that simple.

antiquarian

@blakeyrat said:

@El_Heffe said:
There's always room for improvement, but when you go around saying "Hey, let's get rid of [whatever] because somebody might use it wrong" you're trying to solve the wrong problem.

Well, first of all solving the two problems isn't mutually-exclusive.

Actually, in this case they are, at least the way you want to solve the code problems. But I'll give you the benefit of the doubt. We already have hundreds of programming languages with all types of variations in syntax. If it is possible to reduce WTF's by removing confusing features from programming languages, you should be able to point to programming languages that have less WTF code in the wild.

lethalronin27

@El_Heffe said:

I agree 100%. People shouldn't do that. But they do. The reality is that people write shitty code. So you deal with that reality. You tell them to fix their shitty code. There's always room for improvement, but when you go around saying "Hey, let's get rid of [whatever] because somebody might use it wrong" you're trying to solve the wrong problem.

It's easy to tell them to fix their code, but if they don't understand what's wrong with it in the first place, do you really think that will have any effect? Going back to "with" (I'm not going anywhere near the ternary operator discussion), you basically have 2 options if you want them to fix their code: talk to each developer who misuses it and explain how to use it effectively, or set a company coding standard saying exactly which situations cal for a "with". If you're in a relatively large company, sitting down with each developer misusing it isn't very realistic, considering that most people DO (not MIGHT) misuse it. In order to go with the alternative, setting a company standard, you would have to give concrete details explaining when you should and shouldn't use "with" (e.g. how many lines are allowed in the block, whats the minimum number of references to the object required, etc.). This is by no means an easy thing to do, because there are exceptions to everything, and the programmers who were misusing it would probably just find a "clever" way around those rules anyway. So why not just set a coding policy that "with" just shouldn't be used? It's already done anyway with other constructs, like requiring every "if" block to be enclosed in brackets even if it's only 1 line. Yes, those policies suck if you actually know what you're doing, but you'll be glad they're there when you have to maintain something written by a shitty dev and you can actually understand what they were trying to do.

dhromed

@PedanticCurmudgeon said:

But I wanted to hit the guy who thinks nested ternary conditionals are a good idea!

Oh ok.

He cries.

JvdL

@Zecc said:

I don't think most people fully understand JavaScript's "var" (ie, the whole thing about variable hoisting), while Delphi's "with" keyword doesn't have much to understand (I think? I'm no Delphi expert, or even noob for that matter).
It's just easier to abuse the latter than the former, that's all. You can't nest var declarations, unlike with statements and ternary operators.

Yes you can and this creates the same kind of scope soup as nested withs.

var x = function() { var x = function() { return x; }; return x; };

antiquarian

It looks like I'll need to make my analogy more explicit. Here's the gunshot wound:@lethalronin27 said:

It's easy to tell them to fix their code, but if they don't understand what's wrong with it in the first place,

and here's the band-aid:

So why not just set a coding policy that "with" just shouldn't be used?

Or do you really think that clueless developers will write good code once you give them enough rules to follow?

@JvdL said:

Yes you can and this creates the same kind of scope soup as nested withs.
var x = function() { var x = function() { return x; }; return x; };

That's... worse than with and ternary operatory misuse. That's just evil.

While I don't disagree with the point you're making, I think the problem here is more the fact that you're creating a function that creates functions that return themselves. The reuse of a variable name is the lesser problem.

Look, this isn't better:

function x() {
 	function y() {
 		return y;
 	};
 	return y;
}

A "better" bad example would be this:

// Nest same-named functions too for good measure
function updateX(){
	var x = 5;
	function updateX(){
		var x;
		x = 7;
	}
	updateX();
	return x;
}

Update: changed font size inside <pre>s

lethalronin27

@PedanticCurmudgeon said:

It looks like I'll need to make my analogy more explicit. Here's the gunshot wound:@lethalronin27 said:
It's easy to tell them to fix their code, but if they don't understand what's wrong with it in the first place,
and here's the band-aid:
So why not just set a coding policy that "with" just shouldn't be used?
Or do you really think that clueless developers will write good code once you give them enough rules to follow?

Of course they won't get better, but you can at least prevent devs with SOME idea what they're doing (this isn't a dichotomy here) from misusing commonly misused language features. The few devs that truly haven't the slightest idea what they're doing will still somehow manage to fuck up their code, but the ones that aren't so clueless will produce decent code and wont be using the language feature anymore.

It's not about preventing the worst of the worst from writing shitty code (in your analogy, the gunshot wound), it's about reducing the damage caused by the average dev that keeps misusing the more confusing language features. Any hey, if you get the average devs to stop making mistakes like these, the truly clueless ones will become more apparent, and (hopefully) get fired.

antiquarian

Actually, it was the average developers I was referring to. If they understand why nested withs are a bad idea, there's no need for the rule. If they don't understand, that's the real problem and that's what you should be addressing because there are most likely other important things they don't understand either. Just adding a rule covers that up.

The developers who have no idea what they're doing are most likely beyond help, so they don't need the rule either.

lethalronin27

@PedanticCurmudgeon said:

Actually, it was the average developers I was referring to. If they understand why nested withs are a bad idea, there's no need for the rule. If they don't understand, that's the real problem and that's what you should be addressing because there are most likely other important things they don't understand either. Just adding a rule covers that up.

The developers who have no idea what they're doing are most likely beyond help, so they don't need the rule either.

Looks like a good 80-90% of the developers where I work need to be dropped then, because that's how many are misusing with.

antiquarian

@lethalronin27 said:

Looks like a good 80-90% of the developers where I work need to be dropped then, because that's how many are misusing with.

That's true in most places. That's also why the fizzbuzz test was created; it was an attempt to weed out those who couldn't program their way out of a paper bag.

Cassidy

@lethalronin27 said:

Looks like a good 80-90% of the developers where I work need to be dropped then, because that's how many are misusing with.

Have you actually reflected and questioned:

why are so many developers at your workplace misusing this feature?
how did they come to misuse this feature?
do they actually know they're misusing it?
if misuse of this feature is an indication of bad coders, how come your hiring policy never weeded them out in the first place?
why the hell are you still working there?

flabdablet

@Zecc said:

@flabdablet said:
result = isItThis ? this :

isItThat ? that :

isItTheOther ? theOther :

somethingElse;
CS ate your indentation. I fixed it.

Actually it didn't. My feeling is that any nested ternary conditional long enough to need indenting to make its purpose obvious is a candidate for replacement with an if-else block.

Cassidy

@flabdablet said:

My feeling is that any nested ternary conditional long enough to need indenting to make its purpose obvious is a candidate for replacement with an if-else block.

Erm... isn't that - in this case - what you're actually using the ternary for?

FWIW, Zecc's reformatting makes a confusing line more understandable (and thus more maintainable) for me.

Then again, code maintenance isn't part of my daily responsibilities so it's not like I'm intimately familiar with the way in which you wrote your construct. YMMV...

lethalronin27

@Cassidy said:

@lethalronin27 said:
Looks like a good 80-90% of the developers where I work need to be dropped then, because that's how many are misusing with.

Have you actually reflected and questioned:
why are so many developers at your workplace misusing this feature?
how did they come to misuse this feature?
do they actually know they're misusing it?
if misuse of this feature is an indication of bad coders, how come your hiring policy never weeded them out in the first place?
why the hell are you still working there?

The first two points I can only guess at since they've been here much longer than I have. I think they see it as just shorthand with no long term consequences to maintainability since they only ever maintain their own code (so they already understand how it works). I've tried explaining it to them, but they just think I'm exaggerating how difficult it makes things, and I doubt they'll ever understand without trying to maintain someone else's code themselves. This is still a fairly small company that went from 15 total employees to just over 100 in the past 2 years, so that might have something to do with it.

The hiring process didn't weed them out because they're the ones hiring people. The more recently hired devs are pretty good, but I think that's just by chance since they seem to go based on how they "feel" about a candidate rather than how they respond to technical questions. And trust me, I'm looking for a better job, but since I just graduated college, my options are pretty limited. I started here as an intern 3 years ago and just took a salaried position as a way to pay down debt while I look for something better.

error

@Cassidy said:

FWIW, Zecc's reformatting makes a confusing line more understandable (and thus more maintainable) for me.

Isn't code formatting a solved problem? As in, ctrl+K, ctrl+D, move on with your life?

Oh, right, this is an Eclipse thread. Carry on.

boomzilla

@joe.edwards said:

Isn't code formatting a solved problem?

Only if you don't plan on sharing your code with anyone else.

error

@boomzilla said:

Only if you don't plan on sharing your code with anyone else.

Oh, then they might have to press ctrl+K ctrl+D too.

Actually my team uses a shared code formatting profile using a third party tool; but, it's worth the headaches it saves.

boomzilla

@joe.edwards said:

@boomzilla said:
Only if you don't plan on sharing your code with anyone else.

Oh, then they might have to press ctrl+K ctrl+D too.

STOP POLLUTING THE SOURCE CONTROL HISTORY YOU ASSHOLES

@flabdablet said:

@Zecc said:
CS ate your indentation. I fixed it.

Actually it didn't.

I was being sarcastic (I hope some people caught that). Your code wasn't that readable.

I may have a lower threshold for declaring a line long enough to be unreadable. It's subjective and there's no clear line.

@flabdablet said:

My feeling is that any nested ternary conditional long enough to need indenting to make its purpose obvious is a candidate for replacement with an if-else block.

I agree in part, but if-else blocks are not without their own added line noise:

// Looks pretty decent                    
result = isItThis ? this :
         isItThat ? that :
         isItTheOther ? theOther :
         somethingElse;

// Not so good
if (isItThis) {
    result = this;
} else if (isItThat) {
    result = that;
} else if (isItTheOther) {
    result = theOther;
} else {
    result = somethingElse;
}

// Removing the braces doesn't help much
if (isItThis)
    result = this;
else if (isItThat)
    result = that;
else if (isItTheOther)
    result = theOther;
else
    result = somethingElse;

// Ok, this one's kind of better, but still..
if (isItThis)
	result = this;
else if (isItThat)

result = that;
else if (isItTheOther)

result = theOther;
else

result = somethingElse;

Addendum:@boomzilla said:

STOP POLLUTING THE SOURCE CONTROL HISTORY YOU ASSHOLES

STOP COMMITTING BADLY FORMATTED CODE

boomzilla

@Zecc said:

Addendum:@boomzilla said:
STOP POLLUTING THE SOURCE CONTROL HISTORY YOU ASSHOLES
STOP COMMITTING BADLY FORMATTED CODE

My source code is perfectly formatted, you heretic.