|
...but the garbage I've had to look into and fix, well, it's just amazing.
- Lack of abstraction (makes testing a total PITA)
- Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing)
- Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Run this was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) - How many times do I need to xpath the config file to get the same value in the same loop???
- Let's instantiate variables and never use them!
- Let's add debugging that inspects the .NET stack. And not disable it in a release build.
- Let's load an XSLT transform from a file every time we need to transform something.
- And maybe XSLT isn't the most efficient?
- And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere.
- Let's use
bool? as a 3 state variable instead of a readable enum. - And the list goes on.
I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows.
Marc
|
|
|
|
|
I agree. I hate that not all programmers are as smart as me. It's the worst.  Why can't they all know exactly what I know? 
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I don't want to know what you know.
I want to know what Marc knows.
|
|
|
|
|
Jörgen Andersson wrote: I don't want to know what you know.
Too late. 
Jörgen Andersson wrote: I want to know what Marc knows.
Not enough time. 
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: Not enough time.
Well, that's certainly correct.
He's ahead of me and accelerating.
|
|
|
|
|
|
Oh, how I wish I could upvote that twice!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
But you know that you know nothing, and that's something...
|
|
|
|
|
I think Marc is just looking for "Best Practices" or some method to the madness.
But since I called it Best Practices, which really just means "hey, dev, use a consistent way of doing things that isn't just typing code but actual contains thought", people will freak out. 
|
|
|
|
|
There is a whole lot between knowing what Marc knows and not knowing a damn thing about programming.
Unfortunately, it seems people who know nothing about programming still end up programming somehow 
How would you react if someone built your house, you pay good money, and your front door could always be opened from the outside (even though it seems to have a lock)?
You'd be furious, sue your contractor and find a new door. You'd probably not trust the rest of the house anymore either (check your walls, foundation, windows, etc.).
I think that's roughly the equivalent of SQL injection.
Yet only one is common practice 
|
|
|
|
|
But parameterized values are soooooooo hard!
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
RyanDev wrote: I hate that not all programmers are as smart as me.
Should be :
I hate that not all programmers are as smart as I think I am.
|
|
|
|
|
RyanDev wrote: I hate that not all programmers are as smart as me.
Actually, I much prefer programmers that are smarter than me, so I can learn something. Well, I guess that's what CP is for.
Marc
|
|
|
|
|
Indeed. 
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Marc Clifton wrote: garbage scows.
Reminds me of the time the Klingons called the Enterprise a 'garbage scow'. Wasn't pretty. 
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
The Trouble with Tribbles!
Laddie, don't you think you better rephrase that?
Oh, sure. I didn't mean to say that the Enterprise should be hauling garbage. I meant to say that it should be hauled away AS GARBAGE!
<Fists start to fly>
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Ron Nicholson wrote: Reminds me of the time the Klingons called the Enterprise a 'garbage scow'.
That was exactly the reference. I think the first time that was said was on The Trouble with Tribbles.
Marc
|
|
|
|
|
I have faith.
All it needs is a couple of years, and you'll have fixed most of it.
i.e. All it needs is someone who actually gives a damn.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Sounds a lot like the poor code at a place that I used to work. And one of the reasons that I don't work there anymore.
Also the reason for my tag line
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
|
DialogResult is null when the dialog box is shown but neither accepted nor canceled.
You just confirmed why I never forayed into WPF. WTF???
Marc
|
|
|
|
|
I usually solve the pitfall by using a viewmodel. Any kind of close event I care about is redirected to a command in the VM, which then fires an event (Either some kind of success event, which has it's specific event args, or whatever I need and care about).
Both the window and caller subscribe to the event - The calling instance gets the data, and the window closes itself.
|
|
|
|
|
But let's agree on the fact that a nullable boolean is a stupid idea. I mean it defeats the sole purpose of a bool, doesn't it?
|
|
|
|
|
Marco Bertschi (SFC) wrote: But let's agree on the fact that a nullable boolean is a stupid idea.
Well, given that a field in a DB record can be null (which in itself is a whole can of worms as to what null means in a field) it makes sense that the language supports nullable value types -- I thought it was a significant improvement in C# when that support was added. So, from that perspective, a nullable bool is just like any other nullable value type, and I don't have a problem with it.
What I do have a problem with is when the null state is used as a valid state. In my opinion, any nullable type that is null when you need to use it for something should result in an exception. By that definition, "nullable" to me (and when I design databases) means "it's OK if we don't know the value of this type right now, but when we use it for something, it darn well better not be null."
The exception to that might be business rules that handle "I don't know."
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
