|
Linear Zoetrope posted:
Requirements change in the real world guys jesus
|
# ? Mar 6, 2019 13:34 |
|
|
# ? May 26, 2024 03:41 |
|
the last page has demonstrated once again why composition > inheritance
|
# ? Mar 6, 2019 13:59 |
|
Cuntpunch posted:
code:
|
# ? Mar 6, 2019 14:29 |
|
uncurable mlady posted:the last page has demonstrated once again why composition > inheritance I can't tell if this is calling me discomposed or inbred, but, either way, shots fired!
|
# ? Mar 6, 2019 15:25 |
|
There is a particular kind of coder who would write it like:code:
|
# ? Mar 6, 2019 16:23 |
|
Opferwurst posted:Aren't Lists internally implemented as dynamic arrays in .NET? Why do I see people converting them to static arrays? What's the advantage? If performance is critical and you have a data set of a static size, you can avoid the list having to resize the internal array. It's not a huge cost, but it's certainly not free. After I typed that, I remembered that List also has a constructor that sets the initial capacity, so... maybe not so much. Also for interop with PowerShell or other .NET languages where it's easier to use primitive types.
|
# ? Mar 6, 2019 17:03 |
|
New Yorp New Yorp posted:If performance is critical and you have a data set of a static size, you can avoid the list having to resize the internal array. It's not a huge cost, but it's certainly not free. After I typed that, I remembered that List also has a constructor that sets the initial capacity, so... maybe not so much. Yeah, if you know a reasonable upper-limit size for your list, initializing it with that size will allocate once at the start. And if for some reason you've underguessed, then internally the capacity is just going to get doubled when you overrun.
|
# ? Mar 6, 2019 17:25 |
|
qsvui posted:
this is really good code, but I made a small improvement to make it more flexible
|
# ? Mar 6, 2019 18:19 |
|
NihilCredo posted:There is a particular kind of coder who would write it like: You gotta make it null-safe, like this: code:
|
# ? Mar 6, 2019 18:36 |
|
Which languages have null != null?
|
# ? Mar 6, 2019 19:22 |
|
IEEE 754
|
# ? Mar 6, 2019 19:31 |
|
null isn't the same as NaN.Linear Zoetrope posted:
Want to see how they got to 100% coverage on that one.
|
# ? Mar 6, 2019 19:42 |
|
I'm a little worried about the return value, we should make sure it is in range:pre:assert(_returnValue == true || _returnValue == false, "Invalid return bool!!");
|
# ? Mar 6, 2019 19:43 |
|
dick traceroute posted:Which languages have null != null? SQL
|
# ? Mar 6, 2019 20:11 |
pokeyman posted:SQL Woudln't that be null <> null? (I still get a headache when I run into that operator, it's like whoever did it just made it different to be contrarian)
|
|
# ? Mar 6, 2019 20:12 |
|
You're overcomplicating it.code:
|
# ? Mar 6, 2019 21:09 |
|
Joda posted:Woudln't that be null <> null? (I still get a headache when I run into that operator, it's like whoever did it just made it different to be contrarian) Depends on the platform. MSSQL has the IS/IS NOT NULL keyword which gets hinky with empty string depending on the data type
|
# ? Mar 6, 2019 21:10 |
|
pokeyman posted:SQL http://sqlfiddle.com/#!17/9eecb/26296
|
# ? Mar 6, 2019 21:23 |
|
Doom Mathematic posted:null isn't the same as NaN.
|
# ? Mar 6, 2019 22:09 |
what we really need here is a BoolFactoryBeanFactory
|
|
# ? Mar 6, 2019 22:14 |
|
JawnV6 posted:so? 0x00000000 != 0x80000000 So, null isn't part of IEEE 754.
|
# ? Mar 6, 2019 22:45 |
|
dick traceroute posted:Which languages have null != null? Unity overwrites == This means that == and != will ‘work’ but ?. will not for anything that inherits UnityEngine.Object
|
# ? Mar 6, 2019 23:26 |
|
I thought I'd share a few of the horrors from my current job. Standard Java enterprise junk, there's a lot of code from about 5 years ago that's very suspect. I've cleaned up a lot of it but some sticks in my mind. Inside Constants.java: code:
code:
Plus someone dropped a production schema last year! I'm very glad it happened to someone else and I consider it an incredible learning experience that I will take with me for the rest of my life.
|
# ? Mar 6, 2019 23:37 |
|
Jazerus posted:what we really need here is a BoolFactoryBeanFactory You fool, how are we supposed to inject implementations of those factories? And we don't want to maintain more than one instance, so we'll need a convenient superclass for creating singletons of it. AbstractSingltonBoolFactoryBeanAbstractFactory
|
# ? Mar 7, 2019 02:29 |
|
I don't know if it's a Coding Horror or a Coding Awesome, but I was doing something else and came across this simple convert units call:code:
|
# ? Mar 7, 2019 03:13 |
|
Opferwurst posted:Aren't Lists internally implemented as dynamic arrays in .NET? Why do I see people converting them to static arrays? What's the advantage? No advantage. In fact, converting to a static array takes extra memory (the new array object) and extra execution time (copying items from the list to the array). Behind a List/IList you can hide all sorts of optimizations, like preallocating larger arrays to allow for expansion, or using multiple arrays for storage. A .NET array, on the other hand, is extremely inflexible: it has a fixed size and all items are world-accessible (and world-writable!). You can't efficiently build an array item by item: you have to keep the list of elements somewhere else (... like a List), allocate an array of the right size, and then copy the elements to it. As a general rule, never use arrays unless you have a really good reason
|
# ? Mar 7, 2019 03:37 |
|
hackbunny posted:No advantage. In fact, converting to a static array takes extra memory (the new array object) and extra execution time (copying items from the list to the array). Behind a List/IList you can hide all sorts of optimizations, like preallocating larger arrays to allow for expansion, or using multiple arrays for storage. A .NET array, on the other hand, is extremely inflexible: it has a fixed size and all items are world-accessible (and world-writable!). You can't efficiently build an array item by item: you have to keep the list of elements somewhere else (... like a List), allocate an array of the right size, and then copy the elements to it. As a general rule, never use arrays unless you have a really good reason hey neat, now i have a new weekend project, an ArrayPool<> and Span<> backed IList implementation
|
# ? Mar 7, 2019 04:10 |
|
code:
|
# ? Mar 7, 2019 16:23 |
|
Cuntpunch posted:
This is a bit gratuitous, and if you're going to go to the trouble of structuring things this much then it should probably be a class instead of a dictionary, but it's not really a horror. I can see how something would end up like this if the dev found themselves having to frequently debug through whatever this is. Or a piece of code that had more of a reason to use a dictionary could have ended up this way after a few changes without rationalizing things. Also ValidationThing() is not a good name for this method but I assume that's just you anonymizing this code
|
# ? Mar 7, 2019 16:46 |
|
Hammerite posted:This is a bit gratuitous, and if you're going to go to the trouble of structuring things this much then it should probably be a class instead of a dictionary, but it's not really a horror. I can see how something would end up like this if the dev found themselves having to frequently debug through whatever this is. Or a piece of code that had more of a reason to use a dictionary could have ended up this way after a few changes without rationalizing things. The names are anonymized, but the structure is that. There's literally nothing trimmed out (except the 4 or 5 other validation methods). But a Dictionary where you never actually use the Keys? On the second pass it turned into a List<bool>. All just to be able to use LINQ's All() method. The problem there being is that unlike simply doing code:
|
# ? Mar 7, 2019 17:11 |
|
Cuntpunch posted:The names are anonymized, but the structure is that. There's literally nothing trimmed out (except the 4 or 5 other validation methods). But a Dictionary where you never actually use the Keys? That's why I speculated that they had had to use it a lot while debugging. It looks like something you might come up with if you wanted to look at the results of all those methods with the debugger attached.
|
# ? Mar 7, 2019 18:15 |
|
Cuntpunch posted:By pre-calling everything you don't get any valuable short-circuiting logic. That could potentially be a feature, again if you're looking at this in the debugger
|
# ? Mar 7, 2019 19:12 |
|
Microsoft open-sourced their calc.exe source code. https://github.com/Microsoft/calculator It is full of coding horrors. Also, it phones home with statistical usage data. Also people are leaving funny PRs and stuff now. https://github.com/Microsoft/calculator/pull/158/files
|
# ? Mar 7, 2019 19:54 |
|
New Microsoft definitely has some fun moments, gotta say.
|
# ? Mar 7, 2019 21:00 |
|
I do like that we're basically seeing from open sourced Windows components like this what everyone who thinks things through past "TELEMETRY EVIL NSA SPYWARE" expected: they're looking at poo poo like how many people actually use the memory and bitflip features in the calculator.
|
# ? Mar 7, 2019 21:18 |
|
Telyra posted:I do like that we're basically seeing from open sourced Windows components like this what everyone who thinks things through past "TELEMETRY EVIL NSA SPYWARE" expected: they're looking at poo poo like how many people actually use the memory and bitflip features in the calculator. Probably also crash reports, right?
|
# ? Mar 7, 2019 22:34 |
|
Telyra posted:I do like that we're basically seeing from open sourced Windows components like this what everyone who thinks things through past "TELEMETRY EVIL NSA SPYWARE" expected: they're looking at poo poo like how many people actually use the memory and bitflip features in the calculator. Plus the ever valuable Troll Deterrent: https://github.com/Microsoft/calculator/pull/156
|
# ? Mar 7, 2019 22:55 |
|
the only time i saw someone go OMG TERRIBLE CODE was for a 10-line class that wrapped std::vector to remove exceptions from the API. i mean it pulls in Windows.ApplicationModel.Calls.CallPhoneContract for seemingly no reason and takes 150ms to lay out the UI but thats just XAML being terrible not the calc app. in theory you should be able to use /EHsc to disable exceptions, but then you cant use modern C++ with it https://developercommunity.visualstudio.com/content/problem/341669/c-include-has-a-warning-out-of-the-box-c4530-in-pp.html
|
# ? Mar 7, 2019 23:18 |
|
loving hell seeing that screenshot on the calc repo reminded me just how hideous "modern windows apps" are. vast and featureless rectangles of uniform gray, with randomly sized text scattered around in slightly different shades of gray. it's like someone looked at an x11 gui from 1985 and said "hmm, the only problem i can see with this is that there's just too much contrast" bring back aero, or at least the concept of having ui designers who make a basic effort to make things pleasing to look at.
|
# ? Mar 7, 2019 23:44 |
|
|
# ? May 26, 2024 03:41 |
|
yeah, calc.exe is hilariously slow to open. I always laugh a little bit when I have to use it. Good thing its basically the only "modern" app I use, because I'd just be laughing non stop.
|
# ? Mar 8, 2019 00:15 |