|
honey the codewitch wrote: you haven't lived died inside until you've used a dictionary keyed by collections of collections. FTFY
|
|
|
|
|
Oh what's so bad about it? The nested collection equality comparison? or the nested gethashcode function?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: collection equality comparison Actually, I wrote one of those as well just recently
Anyway, it's a great key, in the same way a key on your cars paintwork is a great key
|
|
|
|
|
but did you nest it within another one? *raises eyebrow*
the fact that i had to makes me want to puke
You should see my _LRItemSetComparer class. It's awful.
I had to put progress reporting on this algorithm. It's CPU intensive.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
So you should also report the [CPU] cost of the progress reporting!
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
It's dependent more on the reportee than the reporter since it implements System.IProgress<T>
All it does is fire the Report() method periodically with a status and a count. It takes very little CPU, not even enough to measure.
The implementer of the Report() method takes that info and does something with it - updating the console output, or a progress bar, or whatever. That's where the CPU is.
It's the invoker that does the actual progress display when I call Report()
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: it implements System.IProgress<T> Wow, never seen that before, but I checked and it's right there in my intellisense!
One of the downsides of knowing exactly what code to type is that I'm never browsing through my intellisense anymore, maybe I should do so more often
|
|
|
|
|
I only found out about it a few days ago. I was looking for the async await patterns having to do with progress reporting and there it was.
However, it doesn't depend on async anything. But the async stuff typically consumes IProgress<t>
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: You should see my _LRItemSetComparer class. It's awful. I've seen the leading underscore in the class name and I'm already feeling nauseous
|
|
|
|
|
i always name my private members with leading underscores to avoid collisions in derived classes for reasons having to do with a limitation of .NET's metadata**
Even when those members are themselves classes, if they are not to be accessed outside the class they are declared in they are effectively private, and so they get their leading underscore.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Do you realize I regularly wake up screaming from bad nightmares about your lack of braces and leading underscores?
If I come across as grumpy it's because I'm tired and it's all your fault.
I'm too tired to even get up and get my torch and pitchfork...
|
|
|
|
|
I have a reason for everything i do.
The leading underscores are to prevent potential name collisions in derived classes.
The lack of braces is to drive you to drink.
Everything has a purpose.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: to drive you to drink. I don't drink and drive, but if you're driving I'm drinking all night long!
|
|
|
|
|
Sander Rossel wrote: lack of braces and leading underscores
At least they still use braces on loops.
for(int ic=Count,i=0;i<ic;++i)
{
foreach(var kvp in this[i])
{
if (!nts.Contains(kvp.Value.Left))
nts.Add(kvp.Value.Left);
}
}
Personally I do this:
for(int ic=Count,i=0;i<ic;++i)
foreach(var kvp in this[i])
if (!nts.Contains(kvp.Value.Left))
nts.Add(kvp.Value.Left);
Now tremble before me
Really though, I only do it to force a mindfulness of what you're doing if you modify it. Adding braces effectively changes what the statement is saying. Braces: for(x) do zero or more statements; no braces: for(x) do exactly one statement.
|
|
|
|
|
That's exactly what I do and what i am being disciplined for.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honestly i think the only reason the braces are around that is because i removed some code
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
Yea, that's the main downside to it but on the flip-side you can accidentally add code inside a brace that isn't meant to be looped (albeit probably less common). For instance if braces weren't indented properly due to either a mistake or auto-formatting.
Sander Rossel wrote: I want to think about what my code is doing and should be doing
Debatable topic for sure but I would argue braces vs no braces is exactly a specification of what the code should or should not be doing on a static basis. Similar to the .NET Contracts API.
|
|
|
|
|
Jon McKee wrote: on the flip-side you can accidentally add code inside a brace that isn't meant to be looped (albeit probably less common) Much less common, so much more preferred in my opinion
People do make mistakes with braces, but usually only when it's deeply nested with many many braces, which isn't something you should have anyway.
Jon McKee wrote: braces vs no braces is exactly a specification of what the code should or should not be doing on a static basis Only as you said, should do one thing vs. should do x things, but that's something that changes with specs, and both can be easily changed.
The difference is that when the specs are changed to "if x do y and now also z" the code with braces is almost certain to be changed correctly, but without braces that change is more likely to cause a bug.
It's not even entirely true, because if that one statement is a function call it could still be doing a gazillion things in that function
Another example of how it could cause a bug is the following:
if (x)
AlwaysDoThis(); And what about this?
if (x)
if (y)
DoSomething();
else
DoSomethingElse(); Is that an else for x or y?
|
|
|
|
|
Sander Rossel wrote: Only as you said, should do one thing vs. should do x things, but that's something that changes with specs, and both can be easily changed.
The difference is that when the specs are changed to "if x do y and now also z" the code with braces is almost certain to be changed correctly, but without braces that change is more likely to cause a bug.
If going from a single statement to a block of statements, extracting those statements into a function or expressing it as a block with {} should be done. But I do see where this argument has traction. I don't personally think it's compelling though.
Solution: comment out the if statement too.
AlwaysDoThis();
Braces have an issue here as well:
if (x)
{
}
AlwaysDoThis();
Now you've got an empty check just wasting time. And it does nothing so you'll only ever fix it if you manually stumble across it in the code-base. Both of these examples are mistakes of not commenting out the code only coupled to DoSomething().
if (x)
{
if (y)
DoSomething();
else
DoSomethingElse();
}
I agree with you here. With nested elses it's much clearer to add braces. Also without the braces, as you alluded to, one has to know the else binds to its closest if - something a dev might reasonably not know.
|
|
|
|
|
I'd rather have an empty check wasting time (and we're talking nanoseconds here, hardly ever a big deal) than suddenly have AlwaysDoThis only execute if the if statement is true, which is an actual bug that users are going to see and feel.
Of course, also commenting out the if statement is a simple solution, but maybe only after that bug has gone to production.
Now, if you have automated tests with sufficient coverage and testing processes to find these bugs before they're released, the damage is nothing more than wasted time and effort.
Experience learns that tests aren't always sufficient and that code like that does find its way into production.
In fact, according to this blog[^] a single line if statement caused a bug in Apple's TLS code!
So, I'd rather always use braces and minimize the risk of bugs in production, which is far more serious than one or two extra lines of code
|
|
|
|
|
here's why I don like braces everywhere
}
}
}
}
}
}
++i;
}
}
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Your code shouldn't be so nested in the first place.
I get it, it happens.
How I solve such code is as follows:
void ProcessThing(Thing thingy)
{
try
{
ProcessFoos(thingy.Foos);
}
catch (Exception ex)
{
}
}
void ProcessFoos(List<Foo> foos)
{
foreach (var foo in foos)
{
ProcessBars(foo.Bars);
}
}
void ProcessBars(List<Bar> bars)
{
foreach (var bar in bars)
{
ProcessStuff(bar.Stuff);
}
}
You get the idea, same for if statements and switches.
It's not even that bad, it's quite readable, it's maintainable (you'll always know where the bars are processed) and it saves you from nesting so many levels in one code block.
|
|
|
|
|
That doesn't work when you're "lalring" - there is simply too much state to pass between the methods, and a bunch of methods with lots of ref parameters doesn't do anyone any favors.
Factoring is great when it works, but it's not the solution to everything.
Here's what I'm up against. This is the problem, broken down for mortals:
LALR(1) Parsing[^]
I based all of my code off of this. Scary, I know. But I verified that it works using Gold Parser's tools.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I can't read and understand all of that, show me some code instead!
Oh... But it'll be C++, right?
|
|
|
|