|
I prefer your version, but VS can get weird with it's hints.
Sometimes it makes a suggestion, you let it implement it, and it immediately suggests something else and offers you the original code you wrote.
For example:
StringBuilder sb = new StringBuilder(120); Suggestion: Use an implicit type:
var sb = new StringBuilder(120);
Now it suggests Use an explicit type instead of 'var':
StringBuilder sb = new StringBuilder(120); Which is what I prefer anyway ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That is a great example and it is really terrible.
But, it gives me hope that when AI does take over it will become confused and get into these circles of logic and I will step in and pull the plug and fix it all. 
|
|
|
|
|
Hello David, shall we play a game?  
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I prefer that too. var was meant for implicit typing of anonymous-type variables; not to undermine expressive code 
|
|
|
|
|
This is mostly useful if you've got multiple nested ifs and the indentation is getting obnoxious.
if (condition1)
{
Something1();
if (condition2)
{
Something2();
if (condition3)
{
Something3();
if (condition4)
{
Something4();
if (condition5)
{
Something(5);
}
else
{
return;
}
}
else
{
return;
}
}
else
{
return;
}
}
else
{
return;
}
}
else
{
return;
}
flattens to:
if (!condition1)
{
return;
}
Something1();
if (!condition2)
{
return;
}
Something2();
if (!condition3)
{
return;
}
Something3();
if (!condition4)
{
return;
}
Something4();
if (!condition5)
{
return;
}
Something5();
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I think that the construct of having multiple 'if (condition) return' at the start of a function is meant to be part of the concept of testing preconditions are met before getting to doing the real 'meat' of the function.
When I started, the general rule was that every block (function / if statement / loop / switch / etc) had exactly 'one point in, one point out' - leading to the rule that there was only one 'return' which was at the bottom of the function.
There are two ways of reducing the nesting from code like
if (test1)
{
dosomething1();
if (test2)
{
dosomething2();
if (test3)
{
dosomething3();
}
else
return;
}
else
return;
}
else
return;
One is saving a running success / fail status. Viz:
bool OK = test1;
if (OK)
{
dosomething1();
OK = test2;
}
if (OK)
{
dosomething2();
OK = test3;
}
if (OK)
{
dosomething3();
}
return;(This does preserve the 'one point in, one point out' rule but is slightly clunky - but I have used it many, many times)
A slightly less clunky alternative to this pattern is ..
bool OK = test1;
if (OK)
dosomething1();
OK &= test2;
if (OK)
dosomething2();
OK &= test3;
if (OK)
dosomething3();
return; but I find this less obvious in its intent.
The other alternative is to use short circuiting by making all of the dosomethingn() routines always return true. Viz:
bool _ =
test1 && dosomething1()
&& test2 && dosomething2()
&& test3 && dosomething3()
&& etc;
return;
As long as you comment it at the top to explain how it works in case the next developer isn't used to this idiom, then this last one is succinct, efficient and retains the 'one point in, one point out' design.
modified 11-Aug-20 5:27am.
|
|
|
|
|
I have refactored code to eliminate this lamentable idiom. If the function is long, it usually needs to be broken up anyway. If it isn't, the idiom just introduces noise.
|
|
|
|
|
Egyptology and computer science have nothing to do with each other. So I was extremely surprised back in December 2018 when I was trying get error correction working in 24 dimensional space based off the recent discovery of Maryna Viazovska[^]. I took a break from coding and watched one of those crackpot Egyptology ancient alien youtube videos for entertainment and noticed something I've never noticed before. Apparently the Egyptian royal cubit was 523.5mm in length. This ratio happens to be the inverse of the solution to the Kepler conjecture[^]. It's an extremely big coincidence that this number would just pop out. Right?
I spent the next few weeks trying to figure out how the ancient Egyptians would have known about this sphere packing ratio. Mathematicians will say very abstract things such as PI/6 = 0.5235. But in the natural world these packing ratios known as atomic packing factors[^] are how atoms are arranged. Atoms arrange themselves in the HCP, BCC, FCC and SC physical structures[^]. A ratio of 0.5235 is a simple cubic unit cell. The only natural element on the Earth that uses the simple cubic structure is polonium[^].
But what does it all mean?
I've got to admit that this initially through me for a loop and down the rabbit hole. Then it hit me... I was being just like all of the crackpots that came before me. There is probably an easy to understand explanation:
There is obviously nothing unusual going on here... the length of a rope on a seconds pendulum[^] is always approximately 1 meter long.
The Egyptians were probably using pendulums to discover measurement units. They were dividing the day into hours, minutes and seconds. The length of their rope was approximately 1 meter and the arc in which the pendulum traveled was approximately 0.5235 of a meter. They used the distance of the arc travel as their 'cubit' but ignored the length of the rope.
The most amazing thing here... is that a couple of people ~6000 BCE tied a rock to a rope and sat around counting the seconds. And now 8,000 years later I wasted a few weeks of my life trying to figure it all out.
Best Wishes,
-David Delaune
|
|
|
|
|
Interesting post.
Is this a close summary to what you are saying?
1. Similar mathematical values often arise while calculating values in two completely different realms of study
2. Human brains tend to try to find the significance of why similar values seem to arise in two completely different realms of study.
3. There is no likely significance, but most probably just coincidence.
From this, it is possible you are making yet another conjecture. ??
There is no GUT (Global Unification Theory).
|
|
|
|
|
raddevus wrote: Is this a close summary to what you are saying?
Correct, there is no significance to the Egyptian measurements. It's just crackpot stuff. Our modern meter is tangentially related to the Egyptian royal cubit and that's why crackpots are attracted to those mysteries.
I am apparently not immune and it took me a while to figure out why those numbers were popping up in ancient Egypt.
Best Wishes,
-David Delaune
|
|
|
|
|
I had something similar happen with abrahamic scripture, particularly the torah (and the OT in the bible).
I'm not religious, but I'm fascinated with it.
There are some amazing things in there about how we're "programmed" if you know where to look. And it floored me when I figured out that it was ancient sociology at least as much as religion.
It threw me for months, how some bronze age folks would be able to do broad predictions like Ezekiel 16 or the redeemer archetype in Isaiah 53. things based on past pattern, until I realized how they did it.
Without getting into all of it, because it would be long, basically they exploited (whether they knew it or not) evolutionary-like adaption of folk tales of human behavior over generations using oral history, wherein useful/apropos stories would get repeated and adapted to the situation and the others die out. Over enough generations, patterns emerge, and those patterns help predict or describe us.
Weird, but not supernatural. Just clever. 
Real programmers use butterflies
modified 4-Aug-20 12:03pm.
|
|
|
|
|
Hmmm,
Sounds like you are describing something like the seven basic plots[^].
My previous post at the top of this thread fits a variant of Voyage and Return: The protagonist discovers something strange and, after overcoming the problem, returns with experience.
|
|
|
|
|
I mean, that's an element of it, as they are essentially folk tales. But what they convey is the fascinating. The actual story arcs themselves are useful, as they predict/describe behavior - but the real meat is in its use of allegory to enable humans to engage in higher level pattern matching. It's a manual in part, to show you how to do that, and it's also full of existing patterns, that sometimes become a sort composition. It takes study and reflection to do it. It's very very deep and layered. The talmudic commentary on verse can be very helpful to unravel some of what these stories tell the reader.
Real programmers use butterflies
|
|
|
|
|
Yes, that number arising is pure coincidence and I find it rather nonsensical to make anything of it. The thing is you are mixing a ratio and an absolute measure and when the units of meters are used the number is interesting. For a civilization that uses feet and inches there would be no significance what so ever. They will find the cubit to be 20.6 inches and think, "oh, what ever. That seems rather random." The Egyptians didn't have the metric system so how would that number of meters been of any significance?
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: Yes, that number arising is pure coincidence
Well, actually it's not really coincidence that the ratio of the Egyptian cubit is 0.52 of a meter. However there is nothing mysterious or special about it. I am not sure I conveyed what I am talking about in a clear way.
Here is an absolute fact:
If I gave you only a rope and a rock and asked you to divide the day using only those materials into 24 hours, 1440 minutes and 86400 seconds. When you completed the task your rope would be approximately 1 meter long. The arc of your pendulum would cover ~0.52 of the meter when swinging.
That's all, nothing mysterious.
|
|
|
|
|
private readonly bool _mUseQuoteValue
Original post[^]
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Maybe this should be the proper naming:
const bool _alwaysWrong= true
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
99 Bottles of Beer | Language Malbolge[^]
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
I've heard of it. I think the syntax is too verbose. 
Real programmers use butterflies
|
|
|
|
|
So, when will we see a malbolge code generator article?
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
That would be evil
Real programmers use butterflies
|
|
|
|
|
Yes?
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
Found this gem in our codebase...
public static class DateTimeExtensions
{
public static DateTime EndOfMonth(this DateTime dt)
{
return dt.Date.AddMonths(1).AddDays(-1);
}
}
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Ah.
I can see a problem developing there. I assume he tested it on the first of the month, and it worked fine?
Here is my stab at it:
public static DateTime LastOfMonth(this DateTime dt)
{
int daysInMonth = DateTime.DaysInMonth(dt.Year, dt.Month);
return dt.FirstOfMonth().AddDays(daysInMonth - 1).AtMidnight();
}As seen before: DateTime Extensions to Make Some Simple Tasks a Little More Readable[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
